What happened

Cursor launched Cursor Router, a system that automatically picks which AI model handles each coding request instead of leaving that choice to the developer. Cursor calls it a classifier: it looks at your query, the surrounding code context, how complex the task seems, and the domain, then routes the request to a model suited for that job.

Cursor trained the classifier on more than 600,000 live requests and tested it in an A/B test across millions more, optimizing for what it calls user satisfaction rather than just benchmark scores. In that test, Cursor reports frontier-quality output at 60% lower cost than always using a top-tier model. During an earlier access period with enterprise customers, the reported savings were 30 to 50%.

Router ships with three modes: Intelligence, for the highest-quality output regardless of cost; Balance, tuned to match what Cursor says users commonly prefer; and Cost, which optimizes for token efficiency. You turn it on by selecting “Auto” in Cursor’s model picker.

Cursor Router is available today only on Teams and Enterprise plans, across desktop, web, iOS, CLI, and Cursor’s SDK. It is not available to individual Pro or free-tier users. Admins on Team and Enterprise accounts control the rollout: they can set which modes are available, choose a default, and allow or block specific models.

Why it matters

Cursor’s own numbers explain why it built this. The company says roughly 60% of Cursor users pick one model and stick with it for every task, which means routine work like a small refactor or a variable rename gets billed at the same rate as a genuinely hard, long-running problem. Router is Cursor’s attempt to close that gap automatically instead of asking developers to manually switch models mid-session.

For a team lead watching AI spend, that’s a real decision point. If most of your team’s daily requests are simple, an automatic router that shifts cheap work to cheap models could meaningfully cut your bill without asking anyone to change how they work.

But automatic routing also means less certainty about which model actually generated a piece of code, especially on a task where you’d normally pick a specific model on purpose. Cursor’s classifier is making a judgment call about task complexity on your behalf, and judgment calls can be wrong, particularly on tasks that look simple but touch a sensitive part of a codebase.

Who should care

This is aimed at engineering managers and Cursor admins on Team or Enterprise plans who are already tracking AI spend across a group of developers. If you’re a solo developer on a Pro or free plan, Router isn’t available to you yet, so this is a “watch for now” story rather than something you can act on today.

It matters less if your team already standardizes on a single model for consistency or compliance reasons. Router’s value is in variable, high-volume usage, not in a workflow that intentionally locks in one model choice.

What builders should do next

If you’re a Cursor Team or Enterprise admin, turn on Router in a lower-stakes group first, not your whole org at once. Set the default mode to Balance rather than Cost, since Cost mode is explicitly optimizing for token savings over output quality, and you want to see how the classifier behaves on your team’s actual codebase before trusting it with everything.

Then run a bounded comparison for two weeks: pick a set of 10 to 15 representative tasks your team handles regularly, and have half your group work in Auto mode while the other half keeps manually selecting a model. Compare correctness (does the output need rework), the number of follow-up corrections each approach requires, and total cost per task. That gives you an actual answer for your codebase, rather than relying on Cursor’s own aggregate numbers, which come from its full user base, not your specific work.

If you’re on an individual plan, there’s nothing to configure yet. Keep manually switching models for now, and watch Cursor’s changelog for when, or if, Router extends beyond Team and Enterprise.


End of article