Composer 3 isn't a button in Cursor yet, and there's no published model ID. But there's already a strong signal around it: Cursor states outright that it's training a significantly larger model from scratch together with SpaceXAI, using roughly 10x more total compute. The market has already started calling it Composer 3.
If that name sticks, Composer 3 could turn out to be more important than a routine IDE update. Cursor is trying to own not just the interface for coding agents, but also the model that understands real Cursor sessions better than anyone else.
Where we are now: Composer 2.5
Composer 2.5 is already available in Cursor. The official page describes it as a price-efficient coding model for long-running agents. The standard version costs $0.50 per 1M input tokens and $2.50 per 1M output tokens; fast mode runs $3.00 / $15.00.
Technically, Composer 2.5 is built on Moonshot Kimi K2.5 and enhanced with Cursor's proprietary training and RL. Cursor says 85% of the compute goes into additional training and RL, not just a light wrapper around the base model.
According to Cursor's own benchmarks:
- Terminal-Bench 2.0: 69.3%;
- SWE-Bench Multilingual: 79.8%;
- CursorBench v3.1: 63.2%.
This isn't "the strongest model out there" — it's a model with a good trade-off: smart enough, fast, cheap, and built right into Cursor's workflow.
Why Composer 3 is different
The key difference with the expected Composer 3 is training from scratch. Composer 2 and 2.5 were built on top of Kimi K2.5. The next model, according to Cursor, is being trained together with SpaceXAI as a significantly larger system.
If that's true, Composer 3 will stop being "a coding fine-tune on top of someone else's base" and become its own frontier coding model. That's strategically important for Cursor: less dependence on OpenAI, Anthropic, Google, and Moonshot, and more control over cost, latency, behavior, and product integration.
The second important layer is data. Cursor has something a typical LLM lab doesn't: a massive volume of real coding-agent sessions, diffs, tool calls, user interventions, failed attempts, accepted changes. That's gold for RL, if it's anonymized and used correctly.
Rumors about scale
A breakdown from Compile 2026 floated a figure of 1.5T parameters and training on the SpaceX Colossus cluster. That's a secondary source, not an official model card. Cursor's official wording is more cautious: "significantly larger model from scratch" and "10x more total compute" together with SpaceXAI.
So the honest position is:
- the name Composer 3 hasn't been officially confirmed;
- a new large Cursor/SpaceXAI model has been confirmed as a direction;
- the exact size, architecture, context window, pricing, and release date haven't been published.
What Composer 3 needs to improve
First — long-running agentic tasks. Cursor is already building its product around parallel agents, cloud/local handoff, Slack/GitHub/Linear triggers, and review flows. The model needs to do more than write code — it needs to live inside that runtime.
Second — tool discipline. A good coding agent isn't one that thinks a lot. It's one that calls the right tools, reads the right files, tests hypotheses, and avoids chaotic mass edits.
Third — review and self-correction. The future Composer needs to better understand diffs, tests, regressions, style, architecture boundaries, and risk. Cursor is already moving toward Bugbot, PR review, and multi-agent workflows; a model without strong verification will quickly hit a wall here.
Fourth — cost. Composer only makes sense if it delivers frontier-like coding at a lower price. If Composer 3 ends up as expensive as top closed models, it loses part of its appeal.
Router changes the game
On July 22, Cursor shipped Cursor Router: Auto mode now analyzes the request and routes it to the appropriate model. There are Cost, Balance, and Intelligence modes, and admins can control which models are allowed.
This matters a lot for Composer 3. In this kind of architecture, the new model doesn't have to answer every request. It can be a high-value specialist: kicking in when the task is complex enough, while cheaper models like Composer 2.5 or Grok 4.5 handle the rest.
Routing is exactly what makes a large model economically sensible. You don't need to run the flagship on every tiny edit. You need to call it where it actually pays off.
Take
Composer 3 could turn out to be one of the most interesting coding releases of the year, if Cursor gets the product-model fit right. OpenAI, Anthropic, and Google have strong general-purpose models. Cursor has a shot at building a model that understands a specific development environment better than anyone: files, diffs, PRs, terminal, browser, cloud agents, review, handoff.
The weak spot is obvious too: the model could end up too specialized or too tied to Cursor. For users who live inside Cursor, that's actually a plus. For the API market, it's an open question.
Once Composer 3 ships, the right way to test it isn't "generate a React component" — it's a real workflow: issue → plan → patch → tests → PR → review fixes. On GPTunneL, coding models like this are worth comparing by completed tasks and cost per result, not by a vague sense that "it feels smart."