The best model for Cursor depends on the shape of the task, not on which model tops a leaderboard. Reach for Composer 2.5 on fast interactive edits, Grok 4.5 on long agent sessions, and a frontier model like Claude Opus 5 or GPT-5.6 Sol when a change spans several files and has to respect conventions the codebase never wrote down. Auto covers everyday work. On current Cursor plans the real cost decision is which usage pool a model drains, not its per-token rate.
I burned through the third-party model allowance on my Cursor Pro seat in nine days, and not on anything hard. I had left the picker on a frontier model since the last time a refactor genuinely needed one, and every autocomplete-adjacent question I asked for the rest of that sprint quietly billed against a pool that starts at twenty dollars a month.
That is the friction behind this question. Nobody opens the model picker wanting the smartest model in the world. They open it because a task went sideways, or a bill did, and the honest answer has almost nothing to do with the numbers on any public leaderboard. Cursor argues that point itself, in a post worth taking seriously and then arguing with.
Which Model to Use in Cursor: The Short Answer
If you want the two-line version before the reasoning: use Auto for everyday work and stop thinking about it. Switch deliberately in three situations, and only three.
Switch to a frontier model, currently Claude Opus 5 or GPT-5.6 Sol, when the change spans several files that have to agree with each other and the repo has conventions an outsider would not infer. Switch to Composer 2.5, Cursor's own fast model, when you are in a tight edit loop and latency is the thing you actually feel. Switch to Grok 4.5, which Cursor describes as jointly trained with SpaceXAI for long-running coding and knowledge work, when you are handing off a session you expect to run for a while.
Everything else is defaults. The rest of this article is why those three exceptions are the right ones, and why the pages answering this with a score out of 100 are answering a different question.
Why a Benchmark Score Doesn't Transfer Into Your IDE
Cursor published a post called CursorBench explaining how it compares model quality internally, and the core claim is that its own eval predicts in-Cursor behavior better than public benchmarks do. Tasks come from real usage: "We source tasks for CursorBench using Cursor Blame, which traces committed code back to the agent request that produced it." They score four dimensions, "solution correctness, code quality, efficiency, and interaction behavior."
Strip away who is making the argument and the mechanism is sound. Three things break the transfer from a public score to your editor.
The harness differs. A model inside Cursor is not a model answering a prompt. It sits behind Cursor's own prompt scaffolding, a codebase index it retrieves from, an apply step that writes the edit, and a specific tool surface. It is not even alone on the job: Cursor's docs note that its built-in subagents, Explore, Bash, and Browser, "select their model automatically based on the subtask." The model you chose in the picker is one participant in a system you did not choose.
The task distribution differs. A scored benchmark task is a well-specified problem with a known good patch. Your Tuesday is a half-migrated pattern, two data-fetching helpers that both exist for historical reasons, and a component nobody has read in a year. Cursor's own critique lands here: "Many public benchmark tasks assume a narrow set of correct solutions, but most developer requests are underspecified enough to admit many valid approaches."
And the failure modes that matter differ. What ruins an afternoon is not a wrong algorithm. It is a model that rewrote three unrelated files, or picked the older of two conventions because it grepped and found more instances of it, or guessed at an ambiguity instead of stopping to ask. Pass-or-fail graders do not score any of that.
Neither does anything else in the loop, which is the uncomfortable half of the argument. A reviewer who knows the codebase catches the wrong convention. Nothing in the model picker catches a change that follows every convention and still breaks the behavior, and that is the narrow job Autonoma exists to do: exercise the running application after the diff lands, rather than grade the diff.
Now the other side, because it is not a small objection. CursorBench is unauditable. There is no public task set, and the closest thing to independent scrutiny is Epoch AI's page, which is explicit that it sources results from Cursor's public leaderboard rather than reproducing the evaluation. Cursor also is not a neutral referee: it trains and sells two of the models in the picker, and those two are structurally cheaper for you to run, which means "our internal eval says the cheaper option is good enough" is exactly the sentence a vendor with that cost structure would want to be true.
Which leaves you with the only workable position: treat every score, public or first-party, as a weak prior, and decide from task shape instead. Public leaderboards like Artificial Analysis and LMArena are still useful for tracking the frontier in general, and we work through what they can and cannot tell you in Best LLM for Coding. They are not a Cursor configuration guide.
The Five Axes, Resolved for Cursor's Harness
The durable way to make this call is by task shape, and there is no reason to invent a second framework for it. The five axes we set out in GitHub Copilot models hold here unchanged: context size needed, autonomy and session length, reasoning depth, cost sensitivity, and latency.
What changes is how each axis resolves, because the tool wrapped around the model is different. Copilot does not have Cursor's router, Cursor's two-pool billing, or Cursor's Max Mode gating. Same questions, different answers.
The axes are the same ones that govern model choice in any AI editor. The right-hand column is Cursor-specific, and it changes whenever Cursor changes its plans.
The axis that surprises people is cost. On current Cursor plans it is not really a per-token question, because there are two separate monthly pools. Cursor's own models, Grok 4.5 and Composer 2.5, draw from the Cursor Models pool, which the docs describe as carrying "significantly more included usage." Every third-party model draws from the Other Models pool, which on Pro, Pro Plus, and Ultra includes "at least $20 of third-party model usage each month." Teams and Enterprise seats also pay a Cursor Token Rate of $0.25 per million tokens on third-party requests, from which first-party models are exempt.
So the practical cost question inside Cursor is not "is Opus 5 worth $5 per million input tokens." It is "am I draining the small pool or the large one," which is why leaving the picker parked on a frontier model is the single most expensive habit available to you. The same trap exists on the Anthropic side of this decision, with a different billing shape, and we take it apart in Best model for Claude Code.
One Task, Two Models: What Actually Differed
Here is the part no ranking page in this category publishes, and here is the caveat first, because it matters more than the result.
This is one task, on one codebase, run once per model, by one person who knew which model was which. It is an observation, not a benchmark. I did not blind it, did not repeat it, did not control for cache state, and I have no reason to believe the ordering would hold on a different task. Read it as a worked example of what to look at, not as evidence about which model is better.
The task: add an archivedAt field to a Project entity in an internal Next.js and TypeScript app of roughly 40,000 lines, exclude archived projects from the default list view, and add a filter to include them. That touches a schema and migration, a repository module, a server action, and a React list component. The repo has a wrinkle that makes it interesting: two data-fetching helpers coexist, an older one used in more places and a newer typed client that new code is supposed to use.
Same prompt, fresh chat each time, same three files attached as context.
Composer 2.5 came back fast, in well under two minutes. It touched six files. It also reached for the older helper in the component, which is the majority pattern by instance count and the wrong one by convention, and it skipped the migration file entirely. The diff compiled and the list rendered. It was also wrong in a way the compiler could not see: it filtered archived rows in the component, after a paginated query, so page one silently came back short. It never asked me anything.
Claude Opus 5 took closer to seven minutes and touched four files, all of them ones that needed touching. It used the newer typed client. It stopped and asked whether archived projects should still be counted in a sidebar badge, which was a real ambiguity I had not thought about. It wrote the migration. It also named that migration inconsistently with our timestamp convention and added a defensive null check our lint rule rejects, so it was not a clean diff either.
The cost difference was not a percentage, it was a category. The Composer run drew from the Cursor Models pool and carried no Cursor Token Rate. The Opus 5 run drew from the Other Models pool at published Anthropic rates, currently $5 per million input and $25 per million output tokens. I did not instrument per-request tokens, so I am not going to invent a dollar figure. Your Spending dashboard has the real number, per request, which is more than any comparison page can give you.
What the two runs actually told me: the expensive model did not produce a correct diff. It produced a better-shaped one and one good question. That is the difference the four dimensions Cursor scores are trying to capture, and it is invisible in any pass-or-fail number.
It was also invisible to everything else I had running. The type checker passed both diffs. The page rendered in both. The Composer bug was a missing row on page one, which is exactly the class of defect that needs the application loaded and paged through to surface at all. That is the check Autonoma automates on each pull request, and the reason it does not appear anywhere in the axis list above: it is not a model decision.
Max Mode: What It Unlocks, and Who Can Still Get It
Almost every page ranking for this topic still explains Max Mode as a live decision you should be weighing. According to Cursor's own documentation, it is not one for most readers: "Max Mode is available only on legacy request-based plans." The usage-and-limits page says it flatly: "Current usage-based plans don't include Max Mode."
What it does, where it exists, is narrow and specific. It "extends a model's context window beyond the default limit," it is a toggle in the model selector that persists across conversations, models that require it enable it automatically when selected, and it is "billed at the model's API rate plus 20%." That is the entire documented behavior.
Worth stating plainly, because it is where competitor pages drift: the widely repeated claim that Max Mode raises the tool-call ceiling from 25 to 200 does not appear in Cursor's current documentation. Cursor also publishes no per-model token cost for Max Mode. The only figure is that flat 20% uplift, so the real cost depends entirely on how much context you end up sending.
Cursor's docs describe Max Mode as a context-window change and nothing else. No tool-call limit appears in the current documentation, and no per-model Max Mode price is published.
The Cursor Models List, as of August 5, 2026
Every model name in this article changes on a schedule nobody controls, so they all live in one block you can replace without touching the reasoning above it. The rates below are what Cursor published on its models and pricing reference on August 5, 2026, per million tokens. Check it before you act on any row.
| Model | Pool and rate | Extended context | Best-fit task shape |
|---|---|---|---|
| Composer 2.5 (Cursor) | Cursor Models pool | Not listed | Fast interactive edit loops |
| Grok 4.5 (Cursor) | Cursor Models pool | Built for long runs | Long agent sessions |
| Claude Opus 5 | $5 in / $25 out | Up to 1M tokens | Complex multi-file changes |
| Claude Sonnet 5 | $3 in / $15 out | Up to 1M tokens | Everyday multi-file edits |
| GPT-5.6 Sol | $5 in / $30 out | Up to 1M tokens | Agentic, reasoning-heavy work |
| Auto (Cursor Router) | $1.25 in / $6 out | Router's choice | Everyday work, cost control |
Six of the 40-plus selectable models, chosen because they anchor the corners of the decision. Claude Sonnet 5 is running a launch promotion of $2 input and $10 output through August 31, 2026. Auto's rate shown is Auto Cost mode.
Two things about that list are worth knowing before you go hunting in the picker. Many models, including most of the Opus tier, are marked "hidden by default," so a model you read about may not appear until you enable it in settings. And Cursor's reference publishes per-token rates with no per-model context-window column at all, which is a real gap if context is your binding constraint.
Does Cursor Auto Pick the Best Model?
No, and it is not trying to. Auto is Cursor Router, and the docs are direct about the goal: "Not every request needs frontier-level intelligence, so the router sends each request to the model that fits the task." It classifies each request and routes it. On Teams and Enterprise it runs in one of three modes, Cost, Balance, or Intelligence, and Cursor is upfront that Balance and Intelligence "on average cost about twice as much as Cost, and up to two to four times as much depending on the mode you select." The multi-mode router is a Teams and Enterprise feature; individual plans get the Cost routing logic.
Cursor says the router was trained on "600k+ live requests" and evaluated across millions more in online A/B tests, claiming "frontier-quality performance at 60% savings" for Intelligence mode against a single frontier model. Treat that number the way you treated CursorBench: plausible mechanism, unauditable measurement, and a vendor whose margins improve when you believe it.
The detail I find most telling is the default: the routed model's identity is hidden, in Cursor's words, "so you judge results on merit." Admins can flip it to displayed. That is a defensible design choice and also a real constraint, because if you cannot see what handled a request, you cannot build the intuition that would let you override Auto intelligently.
Practical answer: leave Auto on. Override it when you can name which axis is binding. If you cannot name the axis, Auto is almost certainly the better bet than your gut, and it will not park you on an expensive model for nine days.
Best Model in Cursor for Coding: Verdicts by Situation
There is no single winner here, and every honest thread on this question converges on the same thing: people use several, and they switch.
If you are a solo developer on a Pro seat, run Auto and Composer 2.5 as your defaults and treat frontier models as a budget you spend deliberately, a few times a sprint, on the changes that actually span files. The included third-party allowance is not built for casual use.
If you are on a large legacy codebase with strong undocumented conventions, invert that. The failure mode that costs you real time is a model confidently following the majority pattern instead of the correct one, and that is exactly where the frontier tier earns its rate. Pair it with the practice of asking for a plan before a diff.
If you are a tech lead standardizing a team, the router is the actual product decision, not the model. Setting Auto as a soft or hard default with an admin-chosen optimization mode gets you predictable spend across people with very different picker habits. Turn model visibility on for at least a sprint so the team can build intuition.
And if the model choice feels like it should not matter this much, that instinct is right. The harness often matters more than the weights, which is the argument for reading this alongside Claude Code vs Cursor and, if you are still choosing an editor, Cursor vs Copilot.
One last thing that no model choice touches. Every axis in this article changes the diff: which files get edited, which convention gets followed, whether the agent asks before it assumes. None of them tell you the feature works. The Composer run in my worked example compiled cleanly and rendered a list, and page one was still silently short, which is precisely the class of bug that survives a code review and a passing type check. That gap is where Autonoma sits: it reads your codebase, generates behavioral end-to-end tests, and runs them against the actual running application, with a Diffs Agent that updates the suite from each pull request's code diff so the verification keeps pace no matter which model in the picker wrote the change.
Frequently Asked Questions
There isn't one best model, there are three switching rules. Use Auto for everyday work. Switch to a frontier model like Claude Opus 5 or GPT-5.6 Sol when a change spans several files and has to respect existing conventions. Switch to Composer 2.5 when you are in a tight edit loop and latency is what you feel, or Grok 4.5 when you are handing off a long-running session. If you cannot name which of those applies, Auto is the better default.
Auto is Cursor Router, and it picks the model that fits the request rather than the most capable one available. Cursor's docs are explicit that not every request needs frontier-level intelligence. On Teams and Enterprise it offers Cost, Balance, and Intelligence modes, with Balance and Intelligence costing roughly twice Cost on average and up to two to four times depending on mode. By default the routed model's identity is hidden from you.
For most readers the question no longer applies. Cursor's documentation states that Max Mode is available only on legacy request-based plans, and that current usage-based plans do not include it. Where it does exist, it extends a model's context window beyond the default limit and is billed at the model's API rate plus 20%. Cursor does not publish a per-model Max Mode price, and its current docs do not describe any tool-call limit change.
Because the harness, the task distribution, and the failure modes all differ. Inside Cursor a model sits behind prompt scaffolding, a codebase index, an apply step, and a tool surface, and Cursor's built-in subagents select their own models per subtask. Real tasks are underspecified in ways benchmark tasks are not, and the failures that cost you time, like following the wrong existing convention or guessing instead of asking, are not what pass-or-fail graders score.
No, and this is the axis model choice does not touch. A stronger model changes the shape of the diff: fewer files touched unnecessarily, better convention matching, more questions asked before assumptions. It does not tell you the running feature behaves correctly. In our worked example the faster model produced a diff that compiled and rendered while silently returning a short first page. That is what a verification layer is for, not a model upgrade.
Not with a better model, and not in review. The Composer run produced a diff that compiled, satisfied the type checker, and rendered a list, and the defect was that page one came back short because the archived filter ran after a paginated query. Catching that means exercising the running application: load the list, page through it, count what comes back. That is what Autonoma does. It reads your codebase, generates behavioral end-to-end tests, and runs them against the running app on every pull request, with a Diffs Agent that adds, updates, and deprecates test cases from each pull request's code diff, so the check stays current whether Composer 2.5, Opus 5, or Auto wrote the change.
One that catches what a model switch in Cursor can't. Auto, Composer 2.5, and the frontier models this article compares all change the shape of the diff, fewer unnecessary files touched, better convention matching, but none of them confirm the resulting feature behaves correctly once it's running, which is exactly how a compiling, type-checked diff shipped a silently broken pagination bug in this article's worked example. Autonoma is an AI-native QA layer that reads your codebase, generates behavioral end-to-end tests, and runs them against the actual running application on every pull request, with a Diffs Agent that updates the suite from each pull request's code diff, catching regressions regardless of which model in Cursor's picker wrote the change.
