Models: Auto, Composer, and billing

Every turn of agent work passes through three dials: the agent’s posture (how much latitude it has before you look), its context (what files and instructions sit in front of it), and its engine (which model does the reasoning at all). This chapter is about the engine - the dial with a meter attached. Changing the agent’s posture - its mode - 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.

Price the mistake before Cursor’s own vocabulary comes in. The board below has two independent dials - which model answers, and how hard it thinks - which are the two controls inside the engine dial this chapter is about, with the matched corners on the diagonal and both off-diagonal corners leaking. In Cursor’s terms, the light corner is Auto routing an everyday task; the capable corner is a pinned frontier model at its higher per-token rate:

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 categorization 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 context limits) that decides what a given request actually costs. Get the decision pattern straight and the rest of the chapter is just judgment.

The moves of this chapter

• The per-chat picker and Auto - the picker is per-conversation, and Auto routes everyday work across models (as of October 2026; models doc) without requiring you to pin anything - The per-chat model picker and Auto
• Composer and billing - Cursor maker Anysphere’s own agentic model, and how your plan, your routing, and the model’s context limits decide what a request costs - Pricing, Composer, and context limits
• 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 and shows the 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 third 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 favorite model and pays for capability it never uses. 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.