Cursor Router: How Auto Picks a Model for Every Request

Cursor Router is the routing system that sits behind the Auto entry in the model picker. Cursor's framing is that not every request needs the most capable model available, so the router sends simple requests to fast, efficient models and complex work to the most capable ones. It shipped on 2026-07-22 and is currently only available on Teams and Enterprise plans.

The problem it targets is a specific spending pattern rather than a quality one. Cursor reports that roughly 60% of developers pick a single model as their daily driver, which means routine work gets completed at the price of the hardest work. The numbers below are the shape of the feature before any of the mode detail.

When you select Auto and choose Balance or Intelligence, the router classifies the request before any model runs, then picks the most cost-effective model that still produces comparable quality for that request. Cursor says the classifier looks at query, context, task complexity and domain, combined with what Cursor knows about each model's behaviour — so simple work goes to the most price-efficient models, UI updates go to the model with the best taste, and long-horizon problems go to the strongest reasoning models.

Two properties of the system matter more than the classifier itself. It is managed by Cursor, so you cannot hand-pick which model handles a request and the model pool changes as new models ship. And it is cache-aware: Cursor states the router is trained on a dataset where routing causes cache misses, and that its reported savings include the cost of those misses. That second point is why the published numbers are not the usual best-case routing arithmetic.

The three modes live under Optimize For in the model picker once Auto is selected. They are not quality presets in the usual sense — Cost is the old Auto behaviour kept intact, while Balance and Intelligence are the new routed paths. The table pairs each mode with what Cursor says it optimizes and what it does to your usage limits.

Read Intelligence carefully: Cursor's claim is that it costs less than pinning every request to one expensive model, not that it costs less than Cost mode. Those are two different comparisons, and the next section is where teams most often conflate them.

Billing differs by mode, and the difference is structural rather than a discount. Cost mode uses its own bundled Auto pricing, billed per million tokens no matter which model ends up handling the request. Balance and Intelligence bill per request at the routed model's rate, under the terms of your plan or contract.

Cursor published two kinds of evidence: cost per request during a two-week early-access period, and cost per commit, which is the one engineering leaders tend to ask for. In early access, three high-volume accounts with thousands of users each saved 30-50% on Auto-routed requests against the same traffic priced entirely at Opus 4.8 rates, with no reported decrease in quality. The commit figures are below.

Two caveats worth carrying into any internal business case. These are first-party numbers from the vendor, measured on Cursor's own satisfaction metric (which classifies agent success from how users respond) and keep rate (how much generated code survives in the codebase). And they come from enterprise accounts with thousands of users, so a ten-person team should treat the direction as informative and the magnitude as unproven for its own traffic.

Router configuration lives in the team dashboard, and on Enterprise plans it can also be set per organization group. There are four controls, and the defaults are conservative enough that a team can enable the router without changing anyone's habits on day one.

The recommendation on Underlying model is the one worth understanding before you override it. Cursor's stated reason for hiding the routed model is that results get judged on their own merit rather than by model name. If you turn it on to build trust during a rollout, expect the side effect: developers will start grading outputs by the label at the top rather than by whether the code was right.