Cursor opened its July 22 announcement of Cursor Router with a revealing number: roughly 60% of developers using Cursor choose one model as their daily driver.
That means typo fixes, field renames, unit tests, UI work, and long-horizon architecture problems may all go through the same model. Routine work gets billed at frontier prices even when frontier capability adds little to the result.
I do not think this is primarily a user-selection problem. It is a supply-side mismatch. The model pool keeps expanding, but developers are still expected to schedule it manually, one request at a time. Cursor Router moves that decision into the IDE, before any model runs.
How Cursor Router works
At its core, Cursor Router is a classifier. It evaluates the query, available context, task complexity, and domain, then combines those signals with what Cursor has learned about each model.
Simple work goes to the most price-efficient option. UI updates go to the model with the best taste. Complex, long-horizon problems go to frontier reasoning models.
Cursor trained the router on more than 600,000 live requests and evaluated it through online A/B tests covering millions of live requests. Its reward is user satisfaction, expressed through AFC, or accepted-for-continued-use: whether developers accept the output and keep working with it.
Cache awareness is a less visible but critical part of the design. Switching models can invalidate cached prefixes, so Cursor deliberately trained on routing decisions that produce cache misses. Its reported production savings also include the cost of those misses.
That distinction matters. A router that assumes every prompt stays warm can look efficient in a spreadsheet while becoming much more expensive inside a real conversation.
Three modes and the cost-per-commit table
Cursor Router exposes three modes so teams can choose a point on the cost-versus-intelligence frontier:
- Intelligence prioritizes quality and harder tasks.
- Balance aims for a middle point between satisfaction and spend.
- Cost pushes further toward lower inference cost.
The strongest evidence is not cost per request. It is cost per commit:
| Model or mode | Cost per commit |
|---|---|
| Cursor Router Intelligence | $6.76 |
| Cursor Router Balance | $4.63 |
| Fable 5 | $12.69 |
| Opus 4.8 | $7.34 |
Intelligence lands near Fable 5 in user satisfaction while cutting cost per commit by about 47%. Balance costs about 37% less per commit than Opus 4.8 while producing slightly higher satisfaction. Opus 4.8 carries roughly a 9% cost premium over Router Intelligence.
GPT-5.6 Sol matched Intelligence on cost but delivered lower user satisfaction. In a separate comparison, Balance reached satisfaction comparable to GPT-5.6 Sol at a lower spend rate.
The point is not that the cheapest model wins. The router is optimizing the relationship between task type, perceived quality, spend, and shipped work.
Why online A/B tests beat offline evals here
Cursor explicitly chose large online A/B tests over offline evaluations as its primary methodology. The reasoning is practical.
First, offline evals usually omit the cache-miss cost created by model switching. Second, real routing unfolds across conversations and sessions: the system must decide both which model to use and when switching is worth it. Third, “task completion” in coding agents is difficult to reduce to a stable rubric.
An offline benchmark can score a generated patch. It is much worse at capturing whether a developer accepted the result, continued from it, revised it repeatedly, or abandoned the path later.
During early access, three high-volume enterprise accounts representing thousands of users saved 30% to 50% on auto-routed requests compared with pricing the same traffic entirely at Opus 4.8 API rates. Cursor reported no decrease in quality.
That production result is more useful to an engineering leader than a small benchmark win. It connects routing decisions to the bill teams actually pay.
More than a router: dynamic tool calling and the model pool
Cursor describes Router as one piece of a broader token-efficiency strategy. Another piece is dynamic tool calling.
Instead of loading every native tool description into every prompt, the agent looks up a tool description the first time it needs that tool. Cursor says this follows the same pattern it already uses for MCP tools. Common operations such as read and edit stay readily available, while less common tools enter the prompt only when called.
Model routing reduces the cost of choosing the wrong model. Dynamic tool calling reduces the cost of carrying the wrong prompt payload.
Cursor is also expanding the pool available to the router. Grok 4.5 gives it another option for difficult, higher-cost work, while Composer continues improving along the everyday path. A larger model menu creates more value only when the routing layer understands the differences well enough to remove selection burden from the user.
What this means for builders
In a multi-model world, routing will move into the IDE and the agent harness. It cannot remain a dropdown that developers manually revisit before every request.
The real optimization target is the full execution path: how much context reaches the model, which tools are loaded, whether a cached prefix survives, when a model switch pays for itself, and whether the result becomes an accepted commit.
This connects with the shift I discussed in Codex on mobile and remote coding agents. A coding agent is becoming a persistent engineering system rather than a single model entry point. Once it operates across devices, sessions, tools, and models, an internal scheduling layer becomes inevitable.