Model selection in Cursor

Model selection in Cursor is the choice of which model runs each agent task. The rule this site follows: start on one strong default model, tune that model’s effort variant before switching, and switch only when a small benchmark of tasks from the team’s own repository, checked by its own tests, shows another model passing more tasks for less money.

You are halfway through a feature. The agent’s plan looks right, the model picker lists more models than you could ever compare, and a colleague swears by a different one. You pick by habit, the agent loops on the same failing test, and the month’s usage is gone by the third week.

This page is for developers who choose a model per task in the Cursor IDE, and for tech leads who set the team’s default and want that choice backed by numbers rather than preference. It assumes you have finished essential configuration.

Why this page names no Cursor price or default

Cursor’s model list, defaults, and prices change independently of the model vendors, and cursor.com could not be re-checked for this page on 2026-09-26. Treat your own model picker and Cursor.models.list() as the authority for what your account offers. Vendor prices and context windows live in one place on this site: the models hub.

What a model-selection routine gives you

• A four-question triage that maps a task to a model class in seconds.
• A script that prints every model your account exposes, with its effort variants, so you know what you can choose from today.
• A benchmark runner that runs one task per model in separate Git worktrees and reports pass or fail, diff size, tokens, and cost.
• Three copy-paste prompts: plan with a strong model, build with a cheaper one, and get a second opinion when the agent is stuck.
• A failure-modes table for the day your favourite model disappears from the picker.

Which model class fits which task?

Pick the class first and the model second. The class depends on how hard the task is to get right and how cheaply a mistake is caught, not on how large the task is.

Task shape	Model class	Vendor models in that class (check that your picker lists them)
Cross-module change, architecture, security-sensitive code, a bug whose cause is unclear	Frontier reasoning model: your default	Claude Opus 5.5, which Anthropic names as the model to start with “for most workloads”
The default at a higher effort variant still fails your benchmark	Highest tier, chosen deliberately for one task	Claude Fable 5.1, which Anthropic recommends “when your evals on Claude Opus 5.5 at higher effort still fall short”
Well-specified routine edit that a test proves	Everyday, lower-cost model	Claude Sonnet 5, or the lower-cost models your picker describes as fast
High-volume small work: renames, explanations, subagent fan-out	Fast, cheap model	Claude Haiku 4.5 (Anthropic commits to Haiku 4.5 until at least 2026-10-15 and gives at least 60 days’ notice), Gemini 3.8 Flash
The default loops on the same mistake	A different model family, in a fresh chat	Grok 4.7, which was available in Cursor from its launch day (secondary source: MarkTechPost, 2026-09-21)

The table names vendor models, not Cursor’s catalogue. Whether a model is in your picker depends on your plan and on the date, so confirm it with the script in the next section. Prices for every model above are on the models hub.

Four questions place any task:

1. Would a wrong answer be caught by a test within minutes? If not, use the default: a subtle mistake costs more than the model does.
2. Does the task span more than one module or change a public interface? Use the default, and plan before you build.
3. Is it a pattern you have done before, with a test that proves it? Use the everyday or fast class.
4. Has the current model failed the same check twice? Start a new chat with a different family instead of a third attempt.

Should you change the Cursor model or its effort first?

Changing the model resets everything you know about how the agent behaves on your repository. Changing the effort variant of the same model does not, and it is often enough. In Anthropic’s launch table for Opus 5.5 (2026-09-22), Opus 5.5 at its default medium effort scored 52.5% on CursorBench 4.0, against 51.8% for Fable 5.1 at max effort. Anthropic itself cautions: “at these levels of capability we’ve found that benchmark margins have become a less reliable guide to real-world differences. In our own use, the gap between Opus 5.5 and Claude Fable 5.1 is narrower than these scores suggest.” That is why the last step below is your own benchmark.

1. List what your account exposes. Install the Cursor SDK as a dev dependency (it needs Node.js 22.13 or later) and export an API key from your secret store. In your terminal:

   npm install --save-dev @cursor/sdk@1.0.32 tsx
   export CURSOR_API_KEY="$(op read 'op://Dev/cursor-api-key/credential')"

   The second line reads the key with the 1Password CLI; use whichever secret store your team has. Never paste the key into a command line or a file. Then save this script:

   bench/list-models.mts

   // Run from the repository root: npx tsx bench/list-models.mts
   import { Cursor } from '@cursor/sdk';
   
   const models = await Cursor.models.list();
   for (const m of models) {
     const aliases = m.aliases?.length ? `  (aliases: ${m.aliases.join(', ')})` : '';
     console.log(`${m.id}  ${m.displayName}${aliases}`);
     for (const v of m.variants ?? []) {
       const params = v.params.map((p) => `${p.id}=${p.value}`).join(' ');
       console.log(`    ${v.displayName}${v.isDefault ? ' (default)' : ''}  ${params}`);
     }
   }

   In @cursor/sdk 1.0.32 each model carries an id, a displayName, optional aliases, and optional variants, each variant being a set of params with one marked isDefault. The variants are where effort or thinking settings appear. The SDK hard-codes no model IDs, so this list is the only reliable source.

2. Commit the list. Run npx tsx bench/list-models.mts > bench/models.txt and commit the file. The next time you run it, git diff bench/models.txt shows exactly which models or variants appeared, changed, or disappeared.

3. Pick the default. Choose the strongest reasoning model your plan includes and select it in the model picker. For most teams that is the frontier class from the table above. Leave it there for a week of real work before you judge it.

4. Tune effort before you switch. If the model shows variants, stay on the default variant for routine work. When a hard task fails, rerun it on a higher variant of the same model first. Move down a variant when the agent over-explains simple edits.

5. Switch only on evidence. A different model becomes your default, or your pick for a class of task, only after it wins the benchmark in the next section.

Automatic routing makes measurements non-reproducible

If you use an automatic routing option in the picker, the model can differ from one request to the next, and Cursor’s routing rules could not be re-checked for this page. Pin a named model whenever you measure or compare. Use routing only for work where you do not need to know which model wrote the code.

Prove a model switch with a benchmark on your own tests

Public benchmarks measure other people’s repositories. Before a switch, run three to five tasks from your last sprint, each with a command that proves the task is done. Store each task as a Markdown file in bench/, written the way you would prompt the agent, and name its acceptance command, for example npm ci && npm test -- rate-limit.

This runner gives every model its own Git worktree from the same commit, so the models cannot see or overwrite each other’s work:

bench/compare.mts

// Run from the repository root:
// npx tsx bench/compare.mts bench/task-01.md "npm ci && npm test -- rate-limit" MODEL_A "MODEL_B?PARAM=VALUE"
import { execSync } from 'node:child_process';
import { readFileSync } from 'node:fs';
import { basename, resolve } from 'node:path';
import { Agent } from '@cursor/sdk';

const [taskFile, check, ...specs] = process.argv.slice(2);
const task = readFileSync(taskFile, 'utf8');

for (const spec of specs) {
  const [id, query = ''] = spec.split('?');
  const params = [...new URLSearchParams(query)].map(([pid, value]) => ({ id: pid, value }));
  const dir = resolve('..', `bench-${basename(taskFile, '.md')}-${spec.replace(/[^a-z0-9.-]/gi, '_')}`);
  execSync(`git worktree add --detach "${dir}" HEAD`, { stdio: 'inherit' });

  const agent = await Agent.create({
    apiKey: process.env.CURSOR_API_KEY,
    model: { id, params },
    local: { cwd: dir, settingSources: ['project'] },
  });
  const result = await (await agent.send(task)).wait();
  const { cost } = await agent.getUsage();
  agent.close();

  let passed = true;
  try {
    execSync(check, { cwd: dir, stdio: 'inherit' });
  } catch {
    passed = false;
  }
  execSync('git add -A', { cwd: dir });
  const diff = execSync('git diff --cached --shortstat', { cwd: dir, encoding: 'utf8' }).trim();

  console.log(JSON.stringify({
    task: taskFile, model: spec, agentId: agent.agentId, status: result.status, passed, diff,
    ...result.usage, rawCostCents: cost?.rawCostCents ?? null,
  }));
}

MODEL_A and MODEL_B are IDs from bench/models.txt. To test a variant, append its parameters after a question mark, copied from the same file. The local agent edits files and runs commands in each worktree, so run the benchmark on a machine with no production credentials in the environment. Each task and model gets its own worktree directory, so you can run every task before cleaning up; remove the worktrees with git worktree remove when you are done. Remove a pair’s worktree (git worktree remove <dir>) before rerunning the same task on the same model; otherwise git worktree add fails and the run stops. Cost is reported with a delay; if rawCostCents is null, call Agent.getUsage(agentId) later with the logged agentId, as described in token management in Cursor. rawCostCents is the undiscounted model cost, which is the right figure for comparing models (it is 0 for request-priced usage); cost.chargedCents is what your plan actually billed.

Judge the results with one rule: cost per passing task, not price per token. A model that fails the acceptance command scores zero for that task, however cheap it was.

Switch the default when the candidate…	Keep the current default when…
Passes at least as many tasks	It passes more tasks, even at a higher cost
Costs less per passing task	The candidate is cheaper only because it did less (a smaller diff that fails)
Produces a diff of similar size to the plan	The candidate’s diff touches files outside the task

The developer decides for their own tasks. For a team default, the tech lead signs off and commits the benchmark output next to bench/models.txt, so the next person can rerun the same tasks when the picker changes. For building a larger eval set, see reading coding-agent benchmarks and building your own evals.

Plan with one model, build with another

The cheapest reliable pattern is to spend the strong model on the decisions and a cheaper one on the typing. Plan Mode in Cursor creates a detailed implementation plan before any code is written, which gives the cheaper model an exact script to follow. Select your default model, switch the agent to Plan Mode, and paste the first prompt. For more on the modes, see agent modes in depth.

Copy-paste prompt: plan with the default model

Plan the change described in docs/specs/rate-limit.md. Do not edit any files.
List every file you will touch, the tests you will add or change, and for each
step the command that proves it is done (for example `npm test -- rate-limit`).
Mark every point where the spec is ambiguous and ask me instead of assuming.
Stop after the plan.

Read and approve the plan. Then choose the everyday model in the picker, switch back to Agent, and send the build prompt. If the plan is long, save it to a file first and attach it with @ in a new chat, so the cheaper model starts with the plan and nothing else.

Copy-paste prompt: build the approved plan with a cheaper model

Implement the approved plan one step at a time.
After each step, run that step's check command and show the last 20 lines of output.
Do not touch any file that is not in the plan.
If a check fails twice, stop and report the failure and your best diagnosis
instead of widening the change.

The same split works from code: in @cursor/sdk 1.0.32, agent.send() accepts mode: 'plan' for one message and a model that stays the agent’s model from that message on, so a script can plan on one model and switch to another to build in the same conversation. See the Cursor SDK guide.

When the build model fails the same check twice, do not raise the stakes by retrying. Open a new chat on a different model family, so the earlier wrong diagnosis is not in its context:

Copy-paste prompt: second opinion from another model family

An earlier attempt keeps failing `npm test -- checkout` with the same assertion error.
Read the failing test and src/checkout/total.ts from scratch; assume any earlier
diagnosis is wrong. State the root cause in two sentences and quote the line that
causes it. Then propose the smallest fix and the test case that would have caught it.
Do not edit files until I confirm.

How do you know the output is right whichever model wrote it?

The model changes how often the agent gets it right, not how you check it. Keep the same gates for every model, so a cheaper model cannot lower the bar:

• An acceptance command per task. Every plan step names one, and the build prompt makes the agent run it. You read the output, not the whole diff.
• Type check and lint in the same run. Add them to the check command (npm run typecheck && npm run lint && npm test -- rate-limit), so a model that skips types fails visibly.
• Scope check. Compare git diff --stat with the plan’s file list. Files outside the plan are the first sign that a model is widening the task.
• Review on the pull request. Bugbot reviews pull requests for bugs, security issues, and code quality problems; set it up with Bugbot in Cursor. The human reviewer reads the plan, the check output, and the review findings.
• Rollback. Work on a branch or worktree, so a bad run is one git worktree remove away. Checkpoints and branching covers undo inside the IDE.

When model choice goes wrong in Cursor

Symptom	Likely cause	Recovery
The model you used yesterday is missing from the picker	Cursor’s model pool changed	Rerun bench/list-models.mts, read git diff bench/models.txt, and rerun the benchmark on the replacement before you adopt it
Results got worse on the same model name	A new variant or a new default variant	Check the (default) marker in the list, pin the variant that won your benchmark, and rerun one task to confirm
A cheaper model passes the benchmark but fails in real work	The benchmark tasks were too easy	Add the hardest task from the last sprint to bench/ and compare again
Usage runs out before the end of the month	The frontier model runs routine work	Move routine tasks to the everyday class and measure the saving with token management in Cursor
Output turns confused right after a model switch mid-chat	The new model inherits a long history built by another	Save the plan to a file and start a new chat that attaches only the plan
Two runs of the same benchmark disagree	Automatic routing chose different models	Pin a named model and variant for every measured run
The agent loops on the same failure	The chat carries a wrong diagnosis	Use the second-opinion prompt in a new chat on another model family

When a new model ships, follow the 48-hour evaluation playbook rather than switching on launch-day enthusiasm.

Where to go next after choosing a model

The next step in Quick Start is rules, which make every model follow your conventions. Claude Code and Codex users make the same choice with their own settings.

Project rules in Cursor Set up rules so any model generates code that matches your team's conventions.

Model comparison hub Current vendor model names, prices, and context windows in one place.

Token management in Cursor Measure tokens and cost per task and cut the context each model pays for.

Evals for coding agents Grow the five-task benchmark into an eval set the whole team trusts.

Model and effort in Claude Code The same default-then-effort rule, set with Claude Code's settings files.

Model settings in Codex Choose and pin a model and effort level in Codex's configuration.