For two years, the model selector was the developer’s lever. You’d pick Sonnet for the hard stuff, something cheaper for the boilerplate, and the tradeoff was yours, request by request. Since July 22, Cursor took that lever without making a sound and handed a different one to whoever administers your team’s dashboard.
Auto mode now runs on Cursor Router. It classifies each request by task type and complexity, and sends it to the model that fits: frontier models for work that demands them, price-efficient models for everything else. That part is easy to accept. The part worth stopping to look at is what “fits” means now, and who has the authority to define it.
You pick Auto, and then you pick how the router optimizes. Three modes. Intelligence equals the most expensive frontier models, the ones you’d hesitate to use all day. Balance equals the frontier models most people use as their daily driver. Cost delivers good quality while reaching maximum intelligence without blowing your token budget. Each mode slides you along the same Pareto frontier of cost-intelligence; all you’re choosing is where you stop.
Here’s the billing detail that matters and that the headline skips: Balance and Intelligence charge at the rate of the routed model. So in those two modes, “let the router decide” doesn’t put a ceiling on your spending: it can route you to a frontier model and you pay frontier prices. Cost is the only mode explicitly designed to squeeze your token spending. If the reason you’re turning this on is the bill, Cost is the setting, and it’s worth being precise about that internally before someone assumes that Auto means cheap.
But the real story isn’t the modes. It’s the admin panel. An administrator can enable the router by team or group, restrict which optimization modes members can even select, set the default mode, and maintain allow/block lists for the underlying models. There are soft and hard enforcement options to standardize everyone on Auto. And by default, the routed model stays hidden: the developer doesn’t see which model actually responded, unless the admin decides to show it.
Hold onto that last part. The knob that used to sit next to the chat — which model am I talking to? — is now an organization-level policy decision, and the default is opacity. For a platform team standardizing spending across fifty engineers, that’s exactly the control you wanted: predictable costs, nobody burning budget on the most expensive model to rename a variable. For the individual developer who built intuition about what model handles what task, it’s a real loss of legibility. Both things are true, and which one you feel depends entirely on which side of the dashboard you sit.
Some data to plan with. It’s enabled by default on Teams plans: if you’re on a team plan, you might already be routing without touching anything, so check your mode before assuming your last week of usage means what you think it does. It runs on desktop, web, iOS, CLI and the SDK, so this isn’t just an editor change; your CLI traffic and automation also routes. And Grok 4.5 is required as one of the price-efficient routing options, which says something about the economics Cursor is optimizing against.
My read, from the CIO chair: this is something good, shipped with a default I’d change on day one. Cost mode plus mode restrictions are a genuinely useful governance primitive: the first time Cursor spending becomes something you can standardize instead of just hoping works out. But hiding the routed model by default changes your engineers’ mental model for a neatness nobody asked for. If I’m deploying this, I’m setting Cost or Balance as default, and turning on “show routed model.” Let people see what answered them. Governance and legibility aren’t opposites, and the default shouldn’t force you to choose.
Do you have it on without knowing? If you’re on a Teams plan, check what mode your Auto is in — and tell me if you’re keeping the routed model hidden or visible for your team.