Models: Auto, Composer, MAX Mode, and billing

The last two chapters were about posture - how much latitude a task deserves before you look - and material: what the agent has in front of it when it answers. This one is about engine: which model answers at all, and what that choice costs. They’re different dials, and the mistake is to wire them together in your head. A mode change is free, and so is pointing at the right file; reaching for the biggest model on a one-line fix is not.

Here’s the trap. People find a model they trust, pin it, and pay for it on every prompt - burning a frontier model’s tokens to stamp out a CRUD endpoint that any cheap model would have nailed. Or they leave it on the cheapest thing and watch it flail at a genuine reasoning problem that needed the heavy engine. Both are the same error: a fixed setting against a variable workload. The operator’s move is to let the cheap, routed default carry the everyday work, and spend the expensive engine only on the turns that actually change the outcome.

Before Cursor’s own vocabulary for this - pools, Auto, MAX Mode - price the mistake generically. In Cursor’s terms the light corner is Auto routing from the included pool; the capable corner is a pinned frontier model billing per-token:

A lumpy day: four kinds of task, and two dials on each - which model answers, and how much effort it spends thinking. Everything starts where most people leave it: pinned to the expensive corner. Re-dial each task and watch what the day costs.

• copy tweaksmechanical · five today

  Fix the onboarding typo, reword two error strings, update the footer year - one obvious answer each.

  modellightcapableeffortlowhigh

  top dollar, one answer

  The most expensive corner on the board, spent on work the cheap corner ships identically. This is where a pinned dial leaks.

• pattern-following endpointsmechanical · three today

  Add list/create endpoints that mirror the handler in the next file over.

  modellightcapableeffortlowhigh

  premium for boilerplate

  Nothing about list/create forks or surprises; the expensive reasoning has nothing to grip. Reserve this corner.

• the intermittent failurehard · once, thankfully

  A test that fails one run in five, timing-dependent, with the cause three files from the symptom.

  modellightcapableeffortlowhigh

  matched - spend it here

  A genuine reasoning problem: timing-dependent, cause far from symptom, no pattern to copy. This corner exists for exactly this task.

• the design forkhard · once

  Choose how rule conflicts resolve in the categorisation engine - several defensible designs, one gets built on.

  modellightcapableeffortlowhigh

  matched - the wrong call costs a rewrite

  Several reasonable designs, and whichever wins gets built on. The delta between corners here is noise next to the cost of unpicking a bad choice later.

presetspin everything expensiveroute by taskunderpower the hard task

first runs495 unitsredo tax0 unitsvs the matched day1.9×

Everything ships - no failures, no redo tax - and the day still costs 1.9× what it should. That’s the quiet leak of a pinned dial: the mechanical work bills like hard work, five and three times over. Dial it down to the cheapest corner that ships it; the hard problems keep their budget.

Numbers are illustrative - the ratios are the point (capable ≈ 5× per token, high effort ≈ 3× the tokens). The redo tax counts an underpowered task’s failed attempts plus the escalation you’d run anyway, not the hour lost to confident wrong answers.

What makes Cursor different from the single-vendor agents - and the reason this chapter exists at all - is that “the model” isn’t one company’s model. Cursor lets you pick across vendors per chat, route automatically when you don’t care, and run its own in-house agentic model. Underneath all of it sits a plan-dependent billing structure (laid out in Pricing, Composer, and MAX Mode) that decides what a given request actually costs. Get the decision pattern straight and the rest of the chapter is just judgment.

The four moves of this chapter

• The per-chat model picker and Auto - the roster spans vendors, the picker is per-conversation, and Auto routes everyday work without requiring you to pin a model - The per-chat model picker and Auto
• Composer and billing - Anysphere’s own agentic model, plan-dependent usage, and the MAX Mode control that can change context and cost - Pricing, Composer, and MAX Mode
• Mixing models - plan with a stronger model, build with a lower-cost one, and spend deliberately on the single turn that earned it - Mixing models: plan with one, build with another

The arc runs from the dial to the meter and back to judgment. The first lesson gives you the control surface and the default that should carry most of your week. The second names the in-house model worth understanding. The third turns the whole thing over and shows the plan-dependent billing structure underneath - because once you can see how routing and usage interact, “which model?” stops being a taste question and becomes a spending one. The fourth puts both dials in the same loop: a strong engine on the design, an efficient one on the typing. The person who’s merely installed Cursor pins a favourite model and pays for capability they do not need. By the end of this chapter you’ll be the other kind of user - the one who lets Auto carry the everyday and reaches for stronger reasoning on purpose.