Choosing a model in Cursor is not a line in the settings but a decision about the balance of quality, speed and money. Both first-party models and models from third-party providers are available, and the catalog, prices, context sizes and parameters change along with the market. Hence the first rule of operation: the source of truth for your account is the live list in the interface and the pricing page, not a screenshot from an article and not a display name remembered six months ago.
The naive habit is to hard-code a particular model into the team's instructions or into an automation script because it performed well. That breaks quietly: the model is retired or renamed, the automation starts failing or silently moves to another one, and the cause is not obvious. A display name is not fit for automation at all - automation needs an identifier from the catalog, obtained by a request rather than by eye.
The choice is conveniently reduced to a few strategies, each with its price. A fixed model gives comparable measurements and a repeatable baseline but requires updating when it is retired. Auto is convenient in ordinary interactive work, but what stands behind it may change. Max Mode pushes the model's context window beyond its default limit at the cost of noticeably higher spend, and is available only on legacy request-based plans. And Cursor Router optimizes an individual request for a goal - minimal cost, balance, or maximum reasoning quality.
It helps to lay those options out in a table with their limitations once. Below is that map. You come back to it when work has become more expensive or slower than expected: most often the cause is not the model itself but a strategy chosen for the wrong task - Max Mode left on for a mechanical edit, or a fixed model left over from last year's experiment.
| Choice | Suits | Limitation |
|---|---|---|
| A fixed model | Comparable measurements, a repeatable baseline | Needs updating when the model is retired |
| Automatic selection | Ordinary interactive work | The model behind it may change |
| The extended mode | Context beyond the model's default limit |
| Legacy request-based plans only; higher usage |
| Router: cost | Minimizing spend | Team and enterprise plans; single automatic rate |
|---|
| Router: balance | A trade-off between quality and price | The model may differ between requests |
|---|
| Router: intelligence | Hard tasks | Billed at the price of the chosen model |
|---|
Two things are worth understanding about the router. It is available on team and enterprise plans and optimizes a specific request rather than the whole session. And it is a router for agent runs, not a universal entry point to chat models: it has its own identifier in the SDK and a parameter for the optimization goal ranging from minimal cost to maximum quality. In the minimal-cost goal the single automatic-selection rate applies, while in the balance and quality goals billing follows the price of the chosen model - the saving here is probabilistic rather than guaranteed.
Comparing models honestly is harder than it looks, and that is the main trap of the subject. If you change the model and at the same time change the wording, the starting commit, the set of allowed tools or the context, you are comparing experiments rather than models. Fix everything except one variable: the same request, the same starting commit, the same tools, the same context and criteria named in advance. Only then does the difference mean anything other than noise.
When spend grows, changing the model is usually premature. The cost of agent work is the size of the context multiplied by the number of loop steps, and both factors more often grow through your doing than the model's: too much is attached, the task is worded broadly, the loop circles without boundaries. Narrowing the scope of the task and the set of attachments reduces the bill more noticeably than moving to a cheaper model and, unlike that move, does not degrade the result.
Auto has an area where it does not fit at all - any comparable measurement. If a different model may stand behind the automatic choice, two runs of the same task differ for a reason you do not control, and the difference in the result stops meaning anything. The sign is recognizable: the same wording on the same code yields a neat edit one time and a sprawling one the next. For regressions, measurements and any comparison the model is fixed explicitly, and Auto is left to ordinary interactive work.
The engineering conclusion about cost is simple: the expensive is turned on deliberately. Max Mode is justified where a task really runs into the size of the context, not where you simply want it better. A mechanical rename, a text edit and a small cleanup do not get better from a more expensive configuration - they only get more expensive.
The typical failures with models are predictable. Hard-coding a model's display name into automation instead of the catalog identifier. Keeping Max Mode on by default and being surprised by the bill. Comparing models while changing three other variables along with them. And expecting guaranteed savings from Cursor Router without noticing that billing follows the model it chose.