The per-chat model picker and Auto

The per-chat model picker

Every chat has a model picker. You set it per conversation - not once globally - which is the whole point: the model is a per-task decision, the same way the chat mode is (the posture switch from the modes chapter).

The roster behind that picker spans multiple vendors, and this page deliberately names almost none of them. Rosters turn over fast enough that any model slug or vendor list printed here would be stale within a release or two. The one exception is Composer, Cursor’s own model family - the entry that isn’t a third-party vendor’s, covered in the next lesson. What doesn’t go stale is the shape of the decision: cheap-and-routed for the everyday, a strong frontier model for the genuinely hard reasoning, and an eye on what each choice bills your plan. Learn the shape; check the live picker for the names (models doc, as of October 2026).

The judgment, restated on the course’s illustrative scenario - budgetcli, a small self-hosted personal-finance API: a boilerplate accounts endpoint (list, create, read, delete, following patterns already in the codebase) has little to reason about, so don’t reach for the strongest engine to type it out. The categorization rules engine, where the design of how rules match, how they order, and how conflicts resolve is a genuine fork with several reasonable answers, is the opposite: a turn where a stronger model’s reasoning may change the result. Spend there, and choose from the live picker rather than memorizing a name; the roster and its labels change quickly.

Auto: let Cursor route the everyday

Most of the time you shouldn’t be picking a model at all. Auto lets Cursor choose for you, and since July 2026 Auto has been able to sit on the Cursor Router - the service Cursor uses to choose which model handles each request. “Cursor Router has three modes: Intelligence, Balance, and Cost which let you adjust where you are on the cost-intelligence Pareto frontier,” as the Router post puts it - but the modes are documented for Teams and Enterprise plans: the Router launched there, and the models doc scopes the picking mechanism the same way (as of October 2026). On other plans - including the free tier this course assumes - your picker may simply not show the modes, and Auto remains the plain automatic choice (the pricing docs describe individual plans as Cost mode only, as of October 2026). Where you do have them, the three modes are points on that frontier: Intelligence is “Frontier quality, with performance matching the most expensive and powerful models,” Balance is “Strong quality, with performance matching the frontier models that most people like to daily drive,” and Cost is “Good quality, reaching the highest available intelligence while optimizing token spend” (all three the Router post’s phrasing).

For the bulk of a working day - the CRUD endpoints, the small refactors, the rename-this-everywhere chores - Auto is the right default. What any given route costs depends on your plan, whether usage-based pricing is on, and current Cursor pricing; the live pricing page and your usage dashboard are the source of truth.

The reflex to build - a capability-and-cost call in one line: capability bought only where it changes the answer, cost contained everywhere else - is default to Auto, and only override the picker when you can name why. “This is a hard reasoning problem and I want a specific frontier model on it” is a reason. “I always use this model” is a habit, and habits are what burn budget on mechanical work.

Try it

Open the model picker and note which optimization mode Auto is set to (on plans without the modes, note which model Auto picks instead), then what it selects for a simple rename task. Override it with a stronger model for a design question. Check your usage dashboard to see the cost difference.

Auto covers the bulk of a working day, but there are turns where you want a specific model, or more context than the default - and both have billing consequences. Next: pricing, Composer, and context limits.