Research
How Cursor Trains Composer 2
Composer 2 is Cursor's in-house coding model. It starts from an open base model, gets continued pre-training on code, then long-horizon reinforcement learning on real coding tasks run in copies of real repos. Cursor grades it on CursorBench, an internal benchmark built from real engineer queries.
On this page
What is Composer 2?
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. is the coding model Cursor trained in-house to run inside Cursor. At release it scored about level with Opus 4.6 and slightly behind GPT-5.4 on coding, while serving much faster and costing far less. Composer 2 Fast generates at roughly 200 tokens per second, and at release the model was priced about an order of magnitude below Opus 4.6.
It is a specialist. Cursor did not build it to win at legal reasoning, financial analysis or general knowledge. The bet is narrower: be excellent at software engineering, and serve quickly because the model carries fewer parameters than a general-purpose one. That narrowness shapes how it gets used, though. 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. is trained for execution rather than planning, so the usual pattern is to plan with a frontier model and hand the build to Composer.
Fewer parameters is the whole point. A model that only has to be good at coding can be smaller, which is why 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. Fast answers at conversational speed while a larger general model is still thinking.
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
Open base model -> continued pre-training on code -> long-horizon RL on real tasks -> graded on CursorBench.
This is covered hands-on in Cursor First Hour — 4 short modules, free to read.
What base model is Composer 2 built on?
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. starts from Kimi K2.5The open base model Cursor continued-trained into Composer 2 (1T parameters, 32B active, 256K context), chosen mainly for how well it fit Cursor's serving infrastructure. Press Enter for the full definition., an open model. Cursor tested many open base models and several were strong; K2.5 won mostly on infrastructure fit, meaning how cleanly it slots into the serving stack Cursor already runs.
- Total parameters
- 1T
- Activated per token
- 32B
- Layers
- 61
- Context window
- 256K
- Attention
- Multi-head latent attention (cheap to serve)
A mixture-of-experts model: 1T parameters exist, but only 32B activate on any given token, which keeps serving cost down.
Multi-head latent attention helps for the same reason the parameter count does. It is efficient to serve, so the base already leans toward the speed 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. is built around.
Fit was not the only test, and none of the criteria Cursor named is a leaderboard rank. One is perplexity against Cursor's own internal codebase, which measures how well a base predicts the code it will actually be asked to work on. Coding knowledge already in the base is another, so post-training builds on a real prior instead of repairing fundamentals. The last is state tracking, whether the model can follow what a program and a task are doing across many steps.
State tracking is the one I would weight highest. Long-horizon agent work comes apart without it, which is presumably why Cursor measured it itself rather than reading a rank.
What is continued pre-training?
Before any reinforcement learning, Cursor keeps training the base model on code. This runs in stages: short-context pre-training over a large pile of tokens, a long-context extension out to 256K, then supervised fine-tuning on agent-like data that resembles how the model will actually work in Cursor.
- 1Short-context pre-training over many tokens to raise code-domain knowledge.
- 2Long-context extension to 256K so the model can hold a real repo and a long task in view.
- 3Supervised fine-tuning on agent-like traces (tool calls, edits, multi-step work).
The order is not arbitrary. Short context comes first because long sequences are the expensive part of training, and most of the code knowledge bought at this stage does not need the room. The extension to 256K follows, so the model can hold a repo and a long task at the same time. Supervised fine-tuning lands last, which means reinforcement learning starts against something that already behaves like an agent instead of a chat model.
This step targets code knowledge specifically rather than general ability. Ablations, where Cursor trains a version with the step removed and compares, showed a real effect on the final model, which is not a given, since a stage can sit in a pipeline for a long time on the strength of everyone assuming it helps.
How does the reinforcement learning work?
The reinforcement learning loop teaches 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. to finish real engineering work. Cursor collects actual coding problems, features, debugging, migrations and documentation, then runs many attempts per problem inside simulated copies of real repositories. Successful attempts get reinforced; failures push the model away.
A single rollout can reach 200,000 tokens and hundreds of tool calls. The model is not answering a question, it is doing a job: reading files, editing, running tests, reacting to what broke.
Auto Install builds the environment first
A rollout only means something if the repo it runs in actually works. Before RL begins, an "Auto InstallA step where a prior Cursor model sets up each training repo's environment, proposing install commands and writing tests until the build verifiably works. Press Enter for the full definition." pass, run by the prior model 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. 1.5, sets up each environment in two stages.
- 1Explore the repo, propose about 10 install commands, and write tests that prove the project is functional.
- 2Run the install, mock what cannot run for real, and retry until the tests pass.
Only then does the new model train against the repo. 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. 1.5 prepares the ground that 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. learns on.
A working test suite is the point of the setup pass. A repo that never installs has nothing to grade, so a rollout inside it returns noise where a reward should be. Doing that setup by hand would also cap how many real repos you could train against, which is arguably the more interesting reason to hand the job to a model. The count then scales with compute instead of headcount.
How does it solve very long tasks?
Two mechanics let 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. run long without wasting effort: a nonlinear length penaltyA training reward that discourages a model from being too verbose or too terse, so easy tasks finish fast and hard tasks get more room. Press Enter for the full definition. and self-summarizationA model summarizing its own work at a trigger point and continuing from that summary, so it can keep working past its context limit. Press Enter for the full definition..
The length penalty
A nonlinear penalty on length keeps easy problems efficient while still allowing hard ones to run long. A trivial fix that rambles for thousands of tokens gets discouraged; a genuine migration that needs the room is not punished for taking it. The shape is the point, since a flat penalty would either bloat the easy cases or starve the hard ones.
The linear version is the tempting one to write, and it fails quietly. Its optimum sits at zero tokens, so the policy learns to stop early and drop the last edit to collect a shorter completion. Penalizing both ends closes that route, and the quality signal still dominates the reward, so length only breaks ties between answers that are already correct.
Self-summarization
When a task approaches the context limit, the model hits a trigger, summarizes what it has done so far, and continues from that summary. Training this behavior teaches 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. to work past its own context window. The same mechanism powers context compactionAutomatic compression of earlier conversation when the context window fills up; it can read like lost context while still costing tokens. Press Enter for the full definition. in the product, so a long Cursor session does not simply run out of room. I do not know whether the training behavior came first or the product feature did.
What is CursorBench?
CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. is Cursor's internal benchmark, built from real engineer queries and kept uncontaminated, meaning it is not in any training set. Uncontaminated is doing most of the work in that sentence, since the fixes behind a public benchmark are sitting in the pre-training corpus, and a high score there can be recall rather than capability. The rest of the design is realistic in ways public benchmarks usually skip.
- Prompts are short and under-specified on purpose. Resolving the ambiguity is part of the task, the way it is for a real engineer.
- Scoring counts both quality and completion tokens, so a correct-but-bloated answer does not look as good as a correct-and-tight one.
- It separates strong from weaker models more sharply than SWE-bench does.
- Across training, best-of-16 kept climbing, which is the signal Cursor watched to know the model was still improving.
Real requests rarely spell out every constraint. A benchmark of clean, fully specified prompts rewards a model that follows instructions but never tests whether it can figure out what you actually meant. CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. keeps that ambiguity in on purpose.
Separation reads like a bragging point about the benchmark. It is closer to an operating requirement. When the top models bunch near a ceiling, a small movement sits inside the noise and no release can turn on it, so a spread-out field is what makes a few points of movement something anyone can act on.
Best-of-16 is doing a different job, closer to a health check on the policy. Sample sixteen attempts, keep the best, and watch whether that number is still moving. If it stopped beating a single sample, the sixteen would be near-identical, which is what mode collapse looks like from outside the training run. It kept climbing, on Cursor's own account of the run.
Why does the harness matter?
Cursor runs one harness across every model: the same scaffolding of tools, prompts and orchestration that turns a raw model into something that can edit a codebase. A separate team owns it.
Cursor's framing for why a dedicated team owns the harness. The model is only one input. The harness around it is much of what users actually experience.
There is outside evidence for how much the harness carries. Artificial Analysis found that the best coding results came from other labs' models running inside Cursor's harness rather than from those models on their own. The measurement comes from a third party, which is what gives it weight in an argument Cursor is otherwise making about itself.
One consequence is an attribution problem. When a benchmark number moves, somebody has to decide whether the model improved or the scaffolding around it did, and those are two different teams. The first place I would look is what changed in the harness over the same window.
What's next? Composer 2.5 and 3
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. has since shipped, and it is the model Cursor now serves. It posts a stronger Terminal-Bench score, and the gains come mostly from cleaner reward signals and refined training data rather than a new base, which barely changes between 2 and 2.5. 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. 3 is the bigger jump: it trains on a much larger cluster.
- Composer 2.5
- Shipped; better Terminal-Bench from cleaner rewards + refined data, base barely changes
- Composer 3
- Trains on a much larger cluster
For scale, about 40 people built 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., split roughly half researchers and half engineers. A small team, on purpose.
Frequently asked questions
Is Composer 2 a fully from-scratch Cursor model?
No. It starts from the open Kimi K2.5 base, then Cursor adds continued pre-training on code and long-horizon reinforcement learning on real tasks. The training that makes it Composer 2 is Cursor's; the starting weights are open.
Why did Cursor pick Kimi K2.5 as the base model?
Cursor tested several strong open bases and judged them on internal criteria rather than a public rank: perplexity against Cursor's own internal codebase, the coding knowledge already in the base, and state tracking across many steps. K2.5 also fit the infrastructure Cursor already runs, helped by its mixture-of-experts layout, multi-head latent attention and native 256K context.
How fast is Composer 2?
Composer 2 Fast generates at roughly 200 tokens per second. It serves quickly because it is a coding specialist with fewer parameters than a general-purpose model, and the base it builds on already uses efficient multi-head latent attention.
How good is Composer 2 at coding?
At release it scored about level with Opus 4.6 and slightly behind GPT-5.4 on coding, while costing roughly an order of magnitude less than Opus 4.6. It is tuned for software engineering, not general knowledge.
What is CursorBench and why not just use SWE-bench?
CursorBench is Cursor's uncontaminated internal benchmark built from real engineer queries, with deliberately short, under-specified prompts and scoring that counts both quality and completion tokens. It separates strong from weaker models more sharply than SWE-bench.
What is coming after Composer 2?
Composer 2.5 has shipped and is the Composer model Cursor now serves, with a stronger Terminal-Bench score from cleaner rewards and refined data while the base barely changes. Composer 3 trains on a much larger cluster.
Sources & last verified
Cursor ships frequently. Last updated July 28, 2026.