Building Cursor Composer: A Fast, Intelligent Agent-Based Coding Model with Reinforcement Learning

cursor · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Agentic coding model training and deployment

Cursor wanted a coding agent model that felt fast enough for interactive editor use while retaining frontier-level coding intelligence on realistic software-engineering work. The challenge was to train a production-like agent, not just a text model: it had to call tools, edit files, search codebases, run terminals, operate in real environments, and improve through reinforcement learning without diverging from the production Cursor agent experience.

Constraints:

• The model had to preserve developer flow by producing useful edits and tool actions quickly, not merely generating tokens fast.
• Evaluation needed to reflect large-codebase work and codebase-standard adherence rather than arbitrary public benchmarks alone.
• RL rollouts had to match the production Cursor tool format and responses while running at far larger scale.
• Realistic coding rollouts can consume 100,000 to 1 million tokens and hundreds of tool calls, creating straggler and synchronization problems.
• The infrastructure had to coordinate mixture-of-experts training, rollout inference, tool execution, and stateful development environments.

Architecture

Composer is an agent-based coding LLM trained with reinforcement learning against Cursor-like production environments. A user query goes to the Cursor backend; the Composer agent emits tool-call XML patterns and selects from roughly 10 tools such as read file, edit file, codebase search, lint collection, and terminal execution. Training treats user queries as rollout starts, runs many Cursor instances in parallel, scores outcomes, and updates a large mixture-of-experts model. The infrastructure is split into a PyTorch trainer, a Ray-based inference server that orchestrates rollouts and manages advantages, and an environment server that spins up microVMs where files can change, commands can run, and linters can execute. Cursor reuses its Cloud Agents production VM infrastructure for RL, uses custom MXFP8 kernels for low-precision MoE training, and trains Composer against the same semantic-search model and tool structure used in production.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  user-query[User query] --> cursor-backend[Cursor backend]
  cursor-backend --> composer-agent[Composer agent]
  composer-agent --> tool-space[Tool space]
  composer-agent --> training-data-queries[Training data queries]
  tool-space --> read-file-tool[Read file tool]
  tool-space --> edit-file-tool[Edit file tool]
  tool-space --> codebase-search-tool[Codebase search tool]
  tool-space --> lint-collection-tool[Lint collection tool]
  tool-space --> terminal-command-tool[Terminal command tool]
  codebase-search-tool --> embedding-search-model[Embedding search model]
  training-data-queries --> inference-server[Inference server]
  inference-server --> environment-server[Environment server]
  inference-server --> ray-controller[Ray controller]
  inference-server --> trainer[Trainer]
  environment-server --> microvm-environments[MicroVM environments]
  environment-server --> cloud-agents-infrastructure[Cloud Agents infrastructure]
  cloud-agents-infrastructure --> production-agent-server[Production agent server]
  trainer --> mxfp8-kernels[MXFP8 kernels]
  trainer --> mixture-of-experts-model[Mixture-of-experts model]
  mixture-of-experts-model --> inference-server
  internal-benchmark[Internal benchmark] --> composer-agent

Components

Data flow

A user query enters the Cursor backend and is passed to Composer. Composer generates tokens, including XML-pattern tool calls, then selects serial or parallel tool actions across file reading, editing, codebase search, lint collection, and terminal execution. In production, those tool calls update the editor and show summarized reads, live edits, and terminal output. In RL training, the same query becomes a training-data prompt; the inference server runs many rollouts from that starting point, calls production-like tools against microVM-backed environments, collects tool results, scores rollout outputs, computes advantages, and returns them to the trainer. The PyTorch trainer updates the mixture-of-experts model, ships new weights back to inference, and repeats the rollout-check-update loop while internal benchmarks and user feedback measure whether the model is both intelligent and fast.

Why this architecture

Cursor optimized for the product experience of fast, intelligent agentic coding rather than isolated benchmark wins. That pushed the architecture toward production-like RL: the same tool formats, semantic-search model, and cloud-agent environment infrastructure used by real users also appear in training. The three-server split separates concerns: PyTorch training updates the MoE model, Ray inference handles rollout orchestration and straggler mitigation, and microVM environments provide stateful tool execution. Custom MXFP8 kernels reduce the cost of training and sampling enough to keep the rollout loop practical, while parallel tool calling targets end-to-end latency rather than token speed alone.

Models used: Composer · Cursor Tab · Cheetah prototype · Mixture-of-experts language model · Embedding search model

Scale

• Composer was reported as four times more efficient at token generation than comparable-intelligence models.
  “the model is four times more efficient at token generation than models of comparable intelligence.”transcript, stated
• The production tool space uses about 10 Cursor tools.
  “In practice, we have about 10 tools that we use in cursor.”transcript, stated
• Realistic modern agent rollouts can use 100,000 to 1 million tokens.
  “In modern models, rollouts use a 100,000 to a million tokens”transcript, stated
• Realistic rollouts can make hundreds of tool calls.
  “they're making hundreds of different tool calls as they go.”transcript, stated
• The training model is distributed across thousands of GPUs.
  “doing this distributed across thousands of GPUs.”transcript, stated
• MXFP8 custom kernels produced a 3.5x speedup for MoE layers on Blackwell chips.
  “for a mixture of experts layers, this gives us a 3.5 times speed up when using Blackwell chips.”transcript, stated
• Naive rollout orchestration was described with 10 rollouts returning at different times.
  “if you run 10 rollouts, they might come back at varying different times.”transcript, stated
• Users could see a full edit and summary a second or two after the query in the demo experience.
  “just a second or two after your original query, you have the full edit and a summarization of what happened in your code.”transcript, stated
• The talk described results from the first week after Composer's release.
  “let me talk a little bit about what we've seen so far in the first week of Composer's release.”transcript, stated

Alternatives considered (roads not taken)

Optimize for arbitrary public benchmarks.

Rejected because: Cursor chose an internal benchmark over its own repositories because day-to-day coding quality depends on large-codebase work and codebase-standard adherence.

Train against mocked or simulated tool environments.

Rejected because: The team preferred the real production environment so Composer could learn exact tool formats, responses, and semantic-search behavior used by customers.

Treat actions only as next-token generation.

Rejected because: For RL, Cursor modeled the action space as combinatorial tool calls, which better matches agent behavior and tool strategy.

Run naive rollout orchestration without load balancing.

Rejected because: Agent rollouts can install libraries, execute unpredictable commands, and finish at different times, so Cursor used Ray and a single controller interface to manage stragglers.

Rely on post-training quantization for rollout sampling.

Rejected because: Low-precision MXFP8 training let the team train faster and sample efficiently without a separate post-training quantization step.

Patterns

tool-use-orchestration (architecture)

Composer treats coding as an agent tool-use problem, choosing among read, edit, search, lint, and terminal tools in serial or parallel rather than only generating code tokens.

eval-driven-development (evaluation)

Cursor built an internal benchmark from its own repositories to measure realistic coding ability, codebase-scale work, and adherence to repository standards.

latency-optimization (operations)

Cursor optimized both token generation and end-to-end editor latency through efficient model serving and parallel tool calls so developers could stay in flow.

rag-retrieval (architecture)

Composer uses Cursor's semantic codebase search tool, backed by a custom embedding model and the same indexed-file structure users see in production.

observability-tracing (operations)

The team monitored RL infrastructure utilization and rollout behavior with dashboards, including dashboards built with Composer itself.

cost-aware-routing (operations)

Cursor reduced training and sampling cost through low-precision MXFP8 kernels and by avoiding post-training quantization before rollout inference.

Tradeoffs

Train through the production Cursor environment.

Chose Production-equivalent tool formats, responses, semantic search, and Cloud Agents VM infrastructure over Mocked or simulated training environments.

Rationale: The production environment made training harder and burstier, but it let Composer learn to be a power user of the exact tools it would use after release.

Optimize for both intelligence and speed.

Chose A model that scored near frontier models while generating tokens four times more efficiently over Maximizing coding quality without preserving interactive latency.

Rationale: Cursor believed the product experience changed when users could receive edits in seconds and stay in flow instead of waiting on a slow agent.

Model RL actions as tool-call strategies.

Chose A combinatorial tool-call action view over Only reasoning about next-token generation.

Rationale: Composer still generates tokens, but the useful behavior being trained is which tools to call, in what order, and whether to parallelize them.

Use custom low-precision kernels.

Chose MXFP8 custom kernels for MoE training and sampling efficiency over Standard higher-precision training plus post-training quantization.

Rationale: The custom kernels improved training speed and made it easier to ship updated weights to the inference server for rollouts.

Use Ray controller-based rollout orchestration.

Chose Load-balanced rollout orchestration across many threads and processes over Letting each rollout run independently with no straggler control.

Rationale: Real agent rollouts perform unpredictable environment actions, so controlling stragglers was necessary to keep RL efficient.

Gotchas (what bit them)

Training and inference versions of the model must stay synchronized during RL.

Root cause: RL requires both a training version and a sampling version of a large distributed MoE model, doubling the coordination burden compared with pretraining or SFT.

Resolution: Cursor split responsibilities across trainer and inference server infrastructure and designed low-precision training so updated weights could be shipped efficiently for rollouts.

Realistic coding rollouts create severe straggler problems.

Root cause: Agents can install libraries, run arbitrary terminal commands, and take different numbers of tool calls, so parallel rollouts finish at very different times.

Resolution: Cursor used Ray with a single controller interface to load-balance work across threads and processes.

Production-like RL training creates bursty infrastructure load.

Root cause: Peak RL training spins up many more environments than normal product usage, creating burstiness in the same backend used by Cloud Agents.

Resolution: The team monitored backend utilization and adapted the production agent infrastructure to handle spiky training workloads.

Early agent behavior made edits without enough evidence.

Root cause: Initial RL behavior optimized coding actions before the model learned to gather enough file and search context.

Resolution: As training progressed, the model learned to read more files and search more before editing.

Mocked environments can train agents to use the wrong tool behavior.

Root cause: If RL training does not match production tool formats, responses, and semantic search behavior, the trained agent may not transfer cleanly to the product.

Resolution: Cursor reused the production Cloud Agents infrastructure and semantic-search model so the training environment matched production.

Evaluation

Cursor evaluated Composer with an internal benchmark drawn from its own repositories, rollout-performance curves over log-scale RL compute, direct product release feedback, and observed agent behavior such as whether training increased parallel tool calls and evidence-gathering before edits. The talk emphasizes product fit and realistic coding performance more than external benchmark maximization.

Metrics: Internal repository benchmark score · Comparison with frontier models · Comparison with prior-summer models · Comparison with open-source models and fast-branded coding models · Token generation efficiency · End-to-end editor response speed · Parallel tool-call frequency · Benchmark performance versus log-scale RL compute · User feedback after release · Agent behavior: files read and searches before edits

Outcomes

• Composer scored nearly as well as the best frontier models on Cursor's internal benchmark
• Composer was reported as four times more efficient at token generation than comparable-intelligence models
• RL training improved benchmark performance at a regular rate as compute increased
• training increased parallel tool calling and improved end-to-end response speed
• training shifted the model from too many low-evidence edits toward more reading and searching before changes
• users liked the first-week release experience because speed and intelligence changed the coding workflow
• Cursor's team used the same agents to build dashboards, backends, and infrastructure

The talk reports about 10 production Cursor tools, 100,000 to 1 million tokens per modern rollout, hundreds of tool calls per rollout, training distributed across thousands of GPUs, a 3.5x MoE-layer speedup with MXFP8 on Blackwell chips, 10-rollout straggler examples, edits visible a second or two after the query in the demo, and first-week release feedback.