Cursor Model Roadmap Tracker

Cursor's model story has two layers: Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. Press Enter for the full definition. is available now, while Cursor says it is training a significantly larger model from scratch with SpaceX using 10x more total compute. The tracker also points readers to current model pages such as Claude Sonnet 5, because availability, pricing and task fit change quickly.

Knowing what shipped is the easy part. Turning Cursor model work into something a team relies on takes a few deliberate steps, mapped below.

1. 1Use Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. Press Enter for the full definition. facts when choosing a model today.
2. 2Use the larger-model announcement as roadmap context for Cursor's long-term differentiation.
3. 3Track whether new model availability changes pricing, latency, review quality or agent reliability.
4. 4Re-check official model docs before quoting pricing or benchmark claims.

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

A common assumption is that Cursor is a thin desktop client that pipes your prompt straight to a model provider. It is not. Between your prompt and the model sits Cursor's hosted harness - proprietary cloud infrastructure that does context selection, caching, retries, compaction and per-model tuning before and after the call.

Dynamic context discoveryIntroduced in Cursor 2.4

The older approach loaded everything - every file, every tool definition, all MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. output - into the context window. That bloats context and costs tokens, and as context grows model accuracy degrades. Dynamic context discovery flips this to a filesystem approach: the agent reads from files, tools and MCP output and pulls into the window only what it deems relevant to the task.

• Less irrelevant context means higher accuracy, not just lower cost.
• The token saving compounds with caching to reach the ~47% figure.
• There is no native model memory here - what feels like memory is the harness re-discovering the right context each turn.

Split the picker into two groups and match the model to the job. One group is async and high-reasoning - intelligent, strong at long-horizon work, more costly - which you use for planning, auditing and gnarly bugs. The other is fast and synchronous: the executors and implementers, near-frontier intelligence at much higher speed, which you use to build once the plan exists.

Plan with a smart model, build with a fast one

The dominant pattern across field workflows is the same: use a larger, more intelligent model to produce a very detailed plan, then a leaner, faster model to do the building. Once the plan is detailed enough, most frontier models will execute it correctly, so speed becomes the lever - and that is exactly what the fast executors optimize for. Internally Cursor plans this way too, then hands execution to a fast model. You can plan in plan mode, pick the execution model, and click Build to move into the building phase that writes the code.

A personal per-task cheat sheet

There's no single right answer - model choice is a bit like picking a t-shirt color, so try them on your own codebases and build an intuition for how each one approaches a problem and where it gets stuck. One practitioner's daily driver settled on a single Opus 4.x model for a month at a time, switching only to evaluate new releases. A rough set of defaults:

• Planning and high reasoning: a frontier Opus 4.x or GPT-5.x model.
• Auditing a plan or finding bugs: GPT-5.x models - they push back a lot and tend to score highest on terminal-bench.
• Medium-to-low tasks with edits under ~5 files: Composer 2Cursor's in-house agentic coding model: frontier-level coding quality at high speed and low cost, built as a software-engineering specialist rather than a general-purpose model. Press Enter for the full definition. / 2.5, the fastest option.
• Documentation: Gemini.
• Cheap, repeatable automations: Haiku.

When you don't want to choose

Two options take the decision off your hands. Auto routes the model per request: since 2026-07-22 it is powered by Cursor Router on Teams and Enterprise plans, which runs a classifier on each agent request and routes it by task type and complexity. What you choose is an optimization mode - Cost, Balance or Intelligence - not a model, and Cost keeps the previous Auto routing logic and its bundled Auto pricing while Balance and Intelligence bill at the routed model's rate. Best-of-N runs the same prompt with the same inputs across multiple models in parallel so you can see for yourself which one fits. You can even run a single model twice to see how much the output varies. There's an upfront cost in running a prompt redundantly, but it's far cheaper than going down a rabbit hole with the wrong model and redoing everything.

For a high-value debug, some teams push this further into a multi-agent run: kick off four or five models on the same problem - a ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. model, an Opus, a Sonnet, a GPT - all searching the same logs through an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. like Datadog, then compare their findings. If it costs you a dollar to fully debug the issue, that's worth it.

Use the model-specific docs for availability, pricing and task fit. The names move faster than any static guide, and one page can also be a warning: Cursor's Claude Fable 5 page currently says Anthropic removed access to that model for all customers.