How Cursor Trains Composer 2

Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. is the coding model Cursor trained to run inside its own agent. In Cursor's technical report, it scored between Opus 4.6 at high effort and GPT-5.4 on CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition.-3, the version of Cursor's benchmark of real coding work in use in March 2026. On Cursor's launch chart, the Fast variant ran at about 200 tokens per second, and Composer 2's price per output token was about an order of magnitude below Opus 4.6's.

Cursor built it as a specialist. Its report says that by focusing entirely on coding, Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. reaches that level at a lower serving cost than leading models charge. The report also counts strong long-term planning among its strengths, along with solving problems efficiently in interactive use. A Cursor presenter said in a talk that it was not built to be the best at legal or financial work or general knowledge.

The base is Kimi K2.5Moonshot's open model that Cursor used as the base for Composer 2 and Composer 2.5 (1T parameters, 32B active, 256K context). Cursor's report says it chose Kimi K2.5 for strong results on its internal tests and for its efficiency on Cursor's infrastructure. Press Enter for the full definition., an open model. Cursor's report says it evaluated several open base models, including Kimi K2.5, GLM-5 and DeepSeek V3.2, and that all three performed well. It chose Kimi K2.5 for strong results across its tests and for other reasons, such as how efficiently the model runs on Cursor's infrastructure.

Cursor scored the candidates on three internal tests. The first measures perplexity on Cursor's private monorepo, code the candidate models could not have seen in training. The second asks coding questions built from moments when earlier 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. models had to read library source code or search the web. The third tests state tracking: rebuilding a file after a long series of edits, since coding agents often need to follow dozens of past edits before they act.

Cursor left coding-agent benchmarks out of this choice on purpose. Its report says they predict the final model less well, because reinforcement learning can change a model's agent and long-horizon skills drastically.

Cursor's research talk on Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. put the weight differently. The presenter said Cursor chose Kimi K2.5Moonshot's open model that Cursor used as the base for Composer 2 and Composer 2.5 (1T parameters, 32B active, 256K context). Cursor's report says it chose Kimi K2.5 for strong results on its internal tests and for its efficiency on Cursor's infrastructure. Press Enter for the full definition. "primarily for infrastructure reasons", and described its multi-head latent attention as efficient to serve.

Continued pre-training means Cursor keeps training the base model on a large, code-dominated data mix before reinforcement learning starts. The goal is coding knowledge specifically. Cursor's report splits this stage into three phases.

1. 1Most of the compute goes to training on sequences of 32K tokens.
2. 2A shorter phase extends the sequence length to 256K tokens.
3. 3A short supervised fine-tuning phase trains the model on targeted coding tasks.

Continued pre-training exists to make reinforcement learning work better, and the report calls the link between the two stages an area of active research. To study it, Cursor ran the same recipe on a smaller open model, Qwen3-Coder-30B-A3B, at three compute levels. Each checkpoint was then fine-tuned on a small dataset and given an identical RL run. Lower loss after fine-tuning predicted higher reward after RL.

On Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. itself, loss on Cursor's internal codebase fell steadily through the run. Cursor's post on the report sums up the finding: lower pretraining loss improves RL, and better base knowledge reliably makes a better agent.

Reinforcement learning trains Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. on realistic coding tasks, in environments built to match real Cursor sessions and with the same tools the shipped model uses. For each problem, Cursor samples a group of attempts, scores each solution and updates the model toward the better ones. The task mix follows what developers ask for most, from feature work and debugging to refactoring, documentation, testing and migrations.

Autoinstall builds the environment first

RL needs environments that run. If a repository is broken at the start, the model spends tokens debugging setup instead of learning the task. In the worst case, a broken environment can make the problem unsolvable and burn compute for no reward. Cursor's fix is autoinstall, which uses an earlier 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 to set up each environment. For Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition., Composer 1.5 did the work in two stages.

1. 1In the goal-setting stage, an agent explores the checkout and proposes 10 commands that should run once the environment works, with a description of their expected output.
2. 2In the setup stage, a separate 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. agent gets three of those commands and works to make them run. Cursor then checks that all three run and that their output matches the description. If not, the setup stage runs again, and after five failed attempts the environment is discarded.

To make the commands run, the agent mocks missing files, creates placeholder images and can even create fake database tables. Cursor's post says the aim is an environment set up as completely as possible.

Autoinstall is inspired by a product feature. Cursor's cloud agents can set up their own environment, starting from a git checkout, so that later requests start from a working setup. Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. scores higher than 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 on Terminal-Bench, which includes tests of environment setup, so Cursor expects it to be a better base for the next run's autoinstall.

Two mechanisms help Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. with long tasks: a nonlinear length penaltyA penalty on effort added to the reward during RL. In Composer 2's training it grows with effort, but each extra unit costs less than the last, so easy tasks finish quickly while hard tasks can run longer. Press Enter for the full definition. that shapes how much effort a task gets, and self-summarizationA trained behavior in which the model, on reaching a fixed token-length trigger, summarizes its own context and continues from that summary, so one task can run past the context window. Cursor trains Composer this way and rewards the summaries along with the rest of the run. Press Enter for the full definition., which lets work continue past the context window.

The length penalty

The length penaltyA penalty on effort added to the reward during RL. In Composer 2's training it grows with effort, but each extra unit costs less than the last, so easy tasks finish quickly while hard tasks can run longer. Press Enter for the full definition. pushes Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. to finish easy requests quickly and lets it think longer on hard ones. The penalty grows with effort, but each extra unit of effort costs less than the one before. On an easy task that needs only a few tool calls, each extra step therefore costs more than it would on a long task, where the agent might make hundreds. Effort is a weighted mix of thinking tokens, tool-call and tool-output tokens, final-message tokens, tool calls and turns.

Cursor reports that the penalty taught the model efficient habits, such as making several tool calls in parallel. Other rewards cover coding style and communication, and penalties target poor tool use, such as creating to-do items and leaving them unfinished.

Self-summarization

Self-summarization lets one task run past the context window. When 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. reaches a fixed token-length trigger, it summarizes its own context and continues from that summary, often several times on a hard task. In training, the final reward applies to every token in the chain, summaries included. Summaries that helped a run succeed are reinforced, and poor ones that lost critical information are pushed down.

Cursor introduced the technique with 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 and kept it for Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition.. Composer runs the same procedure in Cursor when it reaches the trigger. Against a tuned prompt-based summarizer, Cursor reports fewer errors from compaction while using far fewer tokens.

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 coding sessions by Cursor's own engineers, and Cursor uses it throughout training and evaluation. Cursor's report notes that public benchmarks are built from open-source code, which often leaks into training data. It says CursorBench avoids that contamination completely. Cursor's CursorBench post words it more cautiously: many tasks come from Cursor's internal codebase and controlled sources, which reduces the risk that models have seen them in training.

• Prompts are short and underspecified on purpose, so working out what the developer meant is part of the task.
• Cursor plots correctness against median completion tokens, so each score shows what it cost in tokens and time.
• During RL, the average score and best-of-K (the best of several attempts) both rose: best-of-16 on a held-out evaluation set and best-of-4 on CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition..
• Cursor refreshes the suite every few months. Version 3.1, with harder problems, replaced CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition.-3 in May 2026, and Cursor says to compare scores only within one version.

A benchmark is useful only if it separates models that perform differently in practice. When the strongest models score almost the same, a real improvement can disappear inside the noise. Cursor's CursorBenchCursor's internal benchmark that scores models on both task performance and token efficiency, not accuracy alone. Press Enter for the full definition. post says public benchmarks such as SWE-bench no longer tell frontier models apart, even when developers find them very different to use. CursorBench, the post says, separates them more. It also says CursorBench rankings track Cursor's live measures of how developers experience each model more closely than public benchmarks do.

The best-of-K result speaks to a debate about RL. A growing body of research, cited in Cursor's report, argues that RL often raises the average mainly by narrowing a model onto solutions it already knows. Its answers can then become less varied. If that had happened here, best-of-K would have stayed flat while the average rose. Cursor's report says both rose, and takes this to suggest that in its setting RL also widened the set of correct solutions the model can reach.

Cursor's agent harness is the set of instructions and tools it gives a model. Cursor tunes it for each frontier model it supports, and some improvements, such as how context is gathered over a long run, apply to every model inside it. Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. trains in the same harness the shipped model uses, with equivalent tools. Cursor's report calls this close match between training and real use a core rule of 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. training.

In a Cursor talk, a presenter said a separate team owns the harness, and explained why:

Training runs against a shadow deployment of Cursor's backend, so rollouts can call the full tool set of the Cursor client. Some tools behave differently in training on purpose. Stricter checks on tool arguments push the model toward precise calls, and some tools are removed to make the model easier to steer.

Because Cursor works on the harness and the model side by side, a benchmark gain can come from either one. When a score moves, check what changed in the harness over the same period before you credit the model.

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. followed and is now the 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 in Cursor. Cursor's docs list it as one of four Cursor models, beside Grok 4.7Cursor and SpaceXAI's current lead Cursor model, in the weekly pool at $2 per million input tokens and $6 per million output, with a 256k context window and a 500k variant; above 256k input tokens it bills at 2x the standard rate. Press Enter for the full definition., Grok 4.6A Cursor and SpaceXAI model for complex coding and knowledge work, still in the Cursor model pool and succeeded by Grok 4.7; it is a selectable model and is separate from the Grok Bot product. Press Enter for the full definition. and Grok 4.5, which Cursor builds with SpaceXAI. The Composer 2.5 page covers its pricing and when to use it, and the Grok 4.7 page covers the newest Grok model.

The technical report lists 54 people on the 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. research team. In the research talk, the team behind Composer 2Cursor's own coding model, built on the open Kimi K2.5 base as a software-engineering specialist. Cursor calls it frontier-level at coding and more cost-efficient than comparable models; Composer 2.5 has since replaced it in Cursor's model list. Press Enter for the full definition. was put at about 40, roughly half researchers and half engineers.