Cursor Router
Cursor just handed
model selection from humans to AI.
Choosing which AI model to use used to be a decision engineers made on every request. Cursor's new Cursor Router automatically picks the best model per request. In broad testing, it cut costs by up to 60% without a measured drop in quality.
"Which model should I use"
had become its own tax
This year, coding tools shipped a wave of similarly priced frontier models. Choosing between them became a new chore in itself.
Claude Opus-class models, GPT-class models, Gemini-based models — the set of models Cursor supports has exploded over the past year. Performance is close between them, and pricing has converged too. The result: engineers had to decide, on every single request, which model actually fit the task. Send a trivial rename to a frontier model and you burn through your plan's usage cap fast; send a hard architecture question to a lightweight model and you get rework instead.
Auto mode used to make only a rough choice here. In its official blog post "Introducing Cursor Router", Cursor answered that gap by launching a new feature called Cursor Router. Instead of a human choosing each time, an AI classifier reads the request itself and routes it to the right model automatically — turning model selection from a judgment call into a processing step.
| Before (Auto mode) | After Cursor Router |
|---|---|
| Only a rough per-request choice | Classifies the request and auto-routes to the best model |
| Simple edits often burned pricier models | Routine work goes cheap, hard problems go frontier |
| Model choice was left to the engineer | Tunable via Cost / Balance / Intelligence modes |
| Usage-cap burn rate was hard to predict | Less wasted spend stretches the plan's cap further |
Trained on 600,000 requests,
tuned by broader testing
Numbers Cursor published in its "Router" changelog entry show the savings actually grew as testing widened, not shrank.
Cursor says Router was trained on more than 600,000 live requests and tested across millions more. When a few dozen enterprise customers first got early access, they saw roughly 30–50% lower cost at frontier quality. Once testing widened to online A/B tests across millions of requests, cost fell by up to 60% compared to routing everything to Opus 4.8 — with a lower cost per commit and no measured drop-off in quality.
The numbers are striking, but read them carefully. The 30–50% early-access figure and the later 60% figure come from different test populations under different conditions, so there's no guarantee either number reproduces on any given team's own workload until you actually try it.
Classify, route, then
tune with three modes
Router works in three stages: it classifies the request, decides the route, and lets you tune the policy with a mode.
Classify the request
Router judges the task type and complexity of an incoming request before executing it — telling a trivial rename apart from a multi-file architecture change.
Route to a model
Based on that judgment, only requests that genuinely need a frontier model get routed to one; routine requests go to a price-efficient model. Engineers no longer pick a model per request by hand.
Tune with three modes
Three modes are available: Cost, Balance, and Intelligence. Teams or individual users can set whichever policy — cost-first, quality-first, or a middle ground — fits them.
Picking a model is no longer a human's job.
Cursor made that judgment call itself the target of automation.
Who it helps, and how
The benefit reaches both individual engineers and the people managing a team.
Individual engineers
Less time flipping the model dropdown on every request. Since routine edits no longer burn frontier-model tokens, the monthly usage cap stretches further for the hard tasks that actually need it.
Team leads / PMs
Model choices that used to vary developer by developer can now be governed centrally with an org-wide default mode and model allow/block lists — making it easier to keep a team's AI spend within budget.
What to do next
Cursor Router isn't a hidden experiment — it has rolled out across all Cursor surfaces on Teams and Enterprise plans. The first move is to turn it on in Cost or Balance mode and watch your usage-cap burn rate for a week. Both the 30–50% figure and the up-to-60% figure are measurements from other companies' workloads; there's no guarantee the same range shows up on your own codebase or request mix.
Teams rolling this out should have an admin set the allow/block model lists and a default mode up front. If every developer keeps pinning their own model manually, there's no room left for Router's classification to actually do anything.
The cost of a black box
Router's classification logic isn't published, and there's no way to check in advance how a given request was judged. If Router misclassifies a task that genuinely needs frontier-level reasoning as "routine," the user silently gets a weaker model's answer without realizing it. Manually pinning a model is still an option, but doing so means giving up on the premise of letting Router decide in the first place.
It's also worth discounting the two savings figures above for context: the 30–50% number and the 60% number come from different time periods and different test populations — a limited set of early-access enterprise customers versus a broad post-rollout A/B test. Reading them as interchangeable, or assuming "our team will see 60% too," is premature. The claim of no quality drop-off is also, notably, Cursor's own internal measure.