Cursor released Composer 2.5 on May 18, 2026, and the release tells a clear strategic story about where Anysphere is positioning its in-house coding model lineage. Composer 2.5 is not the most capable coding agent on the market. Claude Opus 4.7 in Claude Code and GPT-5.5 in Codex both beat it on the standard benchmarks. What Composer 2.5 does instead is deliver competitive-if-not-leading capability at a fraction of the per-task cost: roughly 10 to 60 times cheaper than the frontier alternatives depending on the tier. For workloads where the marginal capability difference does not justify the marginal cost difference, Composer 2.5 is the better economic answer. That is the position the release stakes out, and it is a defensible one for the largest segment of the agentic-coding market.
This piece walks through what Composer 2.5 actually is, the model lineage it sits at the end of, the architecture and training approach that distinguish it, the benchmark results and how to read them, the pricing story that is the headline value proposition, the community reaction since the May launch, the broader strategic move toward foundation-model independence that Composer 2.5 represents for Cursor, and when Composer 2.5 is the right choice versus when the frontier alternatives still win. The piece assumes you have context on Cursor itself; if you do not, the foundational pillar on Cursor covers the IDE and the company.
The short version is that Composer 2.5 is the kind of release that does not show up at the top of leaderboards but does show up disproportionately in actual production usage because the economics work. For Cursor users on the standard subscription tier who run Composer-driven workflows at any volume, Composer 2.5 is the recommended default rather than the more expensive frontier models. For workloads at the capability ceiling where the marginal quality difference matters more than the marginal cost difference, the frontier alternatives remain the right choice. The two patterns coexist within the same Cursor IDE without friction, which is part of why the Composer model lineage has been a strategically smart investment for Anysphere.
The Composer model lineage
Cursor has shipped three generations of in-house Composer models so far:
Composer 1 released October 29, 2025. The first Cursor-trained coding model, positioned as a cost-effective alternative to the frontier models for routine agentic coding work. Composer 1 was meaningful as a proof-of-concept that Cursor could train usable models internally; the practical capability was below the frontier alternatives by enough that most users still preferred routing to Claude or GPT for serious work.
Composer 2 released March 19, 2026. The second generation closed a meaningful fraction of the capability gap and shifted to using Moonshot’s open-source Kimi K2.5 as the base checkpoint. The Kimi K2.5 choice was a meaningful strategic decision: it gave Cursor a stronger foundation to fine-tune from than building a base model from scratch would have. Composer 2 was the first Composer release that significant fractions of Cursor users actually selected as their default rather than treating as a curiosity.
Composer 2.5 released May 18, 2026 (the subject of this piece). The third generation continues with the Kimi K2.5 base and focuses on training-process improvements rather than a different foundation. The headline change is approximately 25 times more synthetic training tasks than Composer 2, with approximately 85 percent of the compute budget going to post-checkpoint reinforcement learning training. The training innovation Cursor has been most vocal about is "targeted textual feedback": instead of feedback only at the end of a training episode, feedback is injected directly at the trajectory point where the model went wrong. This is a more efficient learning signal than end-of-episode reward and is the kind of technique that small specialized labs can iterate on faster than the giant frontier labs can.
The lineage shows a clear pattern: Cursor is iterating quickly, learning from each release, and treating the Composer model lineage as a strategic asset rather than as a side project. The release cadence of roughly one major model every 3-4 months is faster than the frontier providers’ release cadences for their flagship models.
What Composer 2.5 actually is
Composer 2.5 is a single fine-tuned model, not a router or an ensemble. The underlying base is Moonshot’s Kimi K2.5, an open-source large model that Cursor has fine-tuned for agentic coding workloads. The total parameter count and the specific architectural details follow Kimi K2.5; the fine-tuning is what makes it Composer 2.5.
The context window is 1 million tokens, which is competitive with the current frontier models and is sufficient for most agentic-coding workloads. The exact handling of attention over the long context (whether it’s true 1M attention or some chunking pattern) follows the Kimi K2.5 architecture; Cursor has not published implementation specifics beyond the 1M number.
The model is designed specifically for the agentic coding workload that Composer (the Cursor feature) embodies. The training data includes synthetic agentic-coding trajectories where the model learns to plan multi-step changes, invoke tools (file reads, file writes, terminal commands), iterate based on outcomes, and synthesize the result. The targeted-textual-feedback training innovation is what differentiates Composer 2.5’s training from a more conventional RLHF approach.
Capabilities the model is tuned for: long-horizon agentic tasks, multi-file edits across a codebase, terminal command execution and iteration, codebase semantic search, autonomous planning of multi-step changes. Cursor has explicitly tuned for communication style and "effort calibration," meaning the model’s ability to decide how much work a given task warrants and to communicate progress appropriately as it works.
The model is not currently available outside the Cursor product. There is no public Composer 2.5 API for use in other tools. If you want to use Composer 2.5, you use it inside Cursor.
The base-model transparency story
One detail of the Composer model lineage worth being explicit about is the Kimi K2.5 base. When Composer 2 launched in March 2026, Cursor was criticized for not being fully upfront about the Kimi K2.5 base in the initial communications. The community discovered the connection through inspection and Cursor confirmed it after the fact. The Composer 2.5 release has been substantially more transparent about the Kimi K2.5 base from the start, which addresses the earlier criticism.
The transparency matters for two reasons. The first is practical: developers evaluating Composer 2.5 want to know what’s underneath so they can reason about behavior, capabilities, and limitations. The second is positioning: Cursor’s pitch is partly that the Composer models give it foundation-model independence, but the dependency on the Kimi K2.5 base means the independence is partial. The base model is open-source so Cursor controls its own destiny on it, but the underlying training expertise still flows from Moonshot’s K2.5 work.
This is not a criticism of Cursor’s approach. Fine-tuning a strong open-source base is a sensible and economically efficient way to build a specialized model. It is a more responsible strategy than training a frontier model from scratch when the open-source baseline is already competitive. But the framing in some early Composer 2 communications was less clear about the underlying dependency than it should have been, and the Composer 2.5 release reflects the lesson.
Benchmarks and how to read them
Cursor published a set of benchmark results with the Composer 2.5 launch:
- Artificial Analysis Coding Agent Index: 62, placing third behind Claude Opus 4.7 at 66 and GPT-5.5 in Codex at 65
- SWE-Bench Multilingual: 79.8 percent
- Terminal-Bench 2.0: 69.3 percent
- CursorBench v3.1: 63.2 percent
- SWE-Bench-Pro-Hard-AA: +35 points improvement vs Composer 2
The numbers tell a consistent story: Composer 2.5 is competitive with the frontier models on standard agentic-coding benchmarks but not the leader on any of them. The 4-point gap behind Opus 4.7 on the Coding Agent Index is meaningful in absolute terms (each point on these benchmarks is hard-won) but small enough that for many workloads the difference may not be operationally important.
Two caveats on the benchmark numbers worth being explicit about:
First, the numbers are from Cursor’s own benchmark harness. Independent reproduction is in early stages as of mid-2026 and the published numbers should be treated as directionally credible rather than definitively verified. The general direction (third place, behind Opus 4.7 and GPT-5.5) is consistent with what early-adopter users have reported anecdotally.
Second, the benchmark community has known critiques of how agentic-coding benchmarks measure capability. The benchmarks tend to favor models that produce well-formatted output and follow the expected agent pattern reliably, which may not perfectly correlate with the qualitative experience of using the model for real work. Some community members who tested Composer 2 (the prior version) reported that the benchmark results were stronger than the real-world feel, which is a critique that applies to most benchmark-vs-practice comparisons in this category.
The honest reading is that the benchmark numbers are credible and the third-place placement is real, but the practical workload-fit comparison requires actually using Composer 2.5 on your own work to evaluate.
The pricing story
The pricing is the headline value proposition. Composer 2.5’s per-task economics are dramatically better than the frontier alternatives:
- Composer 2.5 standard tier: approximately $0.07 per task
- Composer 2.5 Fast tier: approximately $0.44 per task
- Claude Opus 4.7 in Claude Code (max effort): approximately $4.10 per task
- GPT-5.5 in Codex (xhigh effort): approximately $4.82 per task
The standard tier is roughly 60 times cheaper than the frontier alternatives. The Fast tier (which provides more compute and faster response time) is roughly 10 times cheaper. The gap is dramatic enough that for any workload where Composer 2.5’s capability is sufficient, the economic case for it is overwhelming.
The API pricing per million tokens follows the same pattern: $0.50 per million input tokens on the standard tier, $3 per million input and $15 per million output on the Fast variant. These numbers are competitive with mid-tier frontier-model offerings and are dramatically below the top-tier offerings.
For Cursor users on the standard subscription tiers (Pro at $20/month, Business at $40/month per user), Composer 2.5 usage counts against the plan quotas. The substantially lower per-task cost means the same plan quota goes substantially further with Composer 2.5 than with frontier models. For teams that were previously hitting plan quotas with frontier-model usage, switching to Composer 2.5 effectively expands the plan without needing to upgrade.
The cost comparison has produced some pushback. One Cursor user with a small four-person team reported that their monthly Cursor bill jumped from approximately $20-100 per person to approximately $1,000 total after Fast became the default tier. The complaint highlights that "approximately 10 times cheaper than frontier models" still adds up at volume, and that the move from "almost free" Composer to "still cheap but not free" Composer Fast is a meaningful step. The right framing is that Composer 2.5 is dramatically cheaper than the frontier alternatives, not that it is free.
Community reaction since launch
The community response to Composer 2.5 since the May 18 launch has been mixed but generally positive on the value proposition:
Praise has focused on the Fast tier being competitive with frontier models at a fraction of the cost. The pattern is: users try Fast for a workload they would normally route to Opus or GPT-5.5, find that the result is good enough for the workload, and switch their default for that workload to Composer 2.5 Fast. The default-switch is the most visible adoption signal.
Skepticism has come primarily from users who remembered Composer 2’s gap between benchmark numbers and real-world feel. The concern is that Composer 2.5’s benchmarks may similarly overstate the practical experience. The honest read on this concern is that it’s partly valid (benchmark-vs-real-world gaps are common) but Composer 2.5’s real-world feedback through May and June has been better than Composer 2’s was, which suggests the improvement is genuine rather than just benchmark-tuning.
Frustration with pricing changes has come from teams whose costs went up after Fast became more prominent in the default routing. The complaint is fair but reflects the normal tension between platform pricing and customer expectations; Cursor has been responsive to feedback and has been adjusting the default routing based on usage patterns.
General framing in the community has settled on "Composer 2.5 is a specialized cost-and-latency-optimized model, not an Opus 4.7 killer." This is the correct framing and is the position Cursor itself takes in its messaging. The model is not trying to be the best on every dimension; it is trying to be the best value for the dimensions it serves.
The strategic context
Composer 2.5 is meaningful beyond its immediate product value. The release signals Cursor’s continued investment in foundation-model independence, and the trajectory of that investment is becoming clearer.
The Composer model lineage represents Cursor’s ability to deliver good-enough capability at fraction-of-frontier-cost economics. As the underlying frontier models continue to improve, Cursor’s challenge will be to keep the Composer models close enough on capability that the cost advantage matters. The training pace Cursor has demonstrated (a major release every 3-4 months) suggests they can keep up.
The strategic complement to Composer 2.5 is the announced SpaceXAI partnership for a from-scratch Cursor foundation model. The partnership gives Cursor access to approximately 10 times more compute than Composer 2.5 used, on the Colossus 2 cluster with its million-H100-equivalent capacity. The from-scratch model would represent a meaningfully different commitment than the open-source-base fine-tuning approach Composer 1 through 2.5 used. The timing is unclear; the SpaceXAI partnership has been announced but the resulting model has not.
The broader implication is that Cursor is moving from "best AI coding tool" to "AI coding platform with multiple model options including its own." The platform framing is the strategic position Anysphere is building toward, and the Composer model lineage is the foundation for that position. Whether the platform play succeeds depends on Cursor’s ability to keep the IDE experience strong while building out the model capability and the underlying infrastructure.
When Composer 2.5 is the right choice
The practical decision framework for Cursor users:
Use Composer 2.5 as the default for the bulk of agentic-coding work where capability requirements are moderate and cost matters. This covers most routine refactoring, most multi-file edits, most code generation from clear specifications, most test writing, and similar workloads. The economics make Composer 2.5 the right default for most everyday work.
Use Composer 2.5 Fast for higher-stakes work where speed and quality matter more than absolute cost. Fast is approximately 6 times more expensive than standard but produces meaningfully better results on harder tasks. The threshold for when Fast is worth the cost is workload-specific; experiment to find the right balance for your patterns.
Use Claude Opus 4.7 in Claude Code for the hardest agentic-coding work where the marginal capability difference matters more than the marginal cost difference. This covers novel problem-solving, complex architectural work, the most difficult debugging sessions, and work where you would rather pay 10 times more for the best available result.
Use GPT-5.5 in Codex for the same category as Opus 4.7 work where the GPT-5.5 capability fits better. The Opus-vs-GPT choice for hard work is partly about which model’s specific strengths align with your codebase and language ecosystem; experimenting with both for representative tasks is the best way to decide.
The right pattern in practice is to use multiple model options across the same Cursor IDE based on the workload at hand. The IDE lets you switch models per task without friction, which means the choice is per-task rather than per-session.
Frequently asked questions
Is Composer 2.5 available outside Cursor? No. The model is only available inside the Cursor IDE. There is no public API for using Composer 2.5 in other tools.
Does Composer 2.5 work in the free Cursor tier? Yes, with the same usage limits that apply to other AI features in the free tier. The free tier is sufficient for evaluation but not for serious daily use.
How does the standard tier vs Fast tier choice work in practice? Cursor’s routing layer decides which tier handles each task based on the request characteristics and the user’s settings. Users can also explicitly choose Fast for specific requests when they want the higher-capability tier.
Is Composer 2.5 the right choice for very large codebases? Generally yes for the routine work, with the caveat that very large codebases sometimes benefit from the frontier models’ larger context handling on tasks that need broad context. The 1 million token context window of Composer 2.5 is sufficient for most codebases.
Can I fine-tune Composer 2.5 on my own codebase? Not currently. Cursor has not exposed a fine-tuning API for the Composer models. The model is shipped as-is and benefits from Cursor’s continuous improvements rather than from customer-specific fine-tuning.
What happens to my Composer 2 usage now that 2.5 is out? Existing Composer 2 workloads continue to work; 2.5 is the new default for new sessions but does not retroactively change in-progress work. Users can explicitly select 2 if they prefer it for some reason.
Does Composer 2.5 use my code for training? Per Cursor’s privacy policy, business and enterprise tier code is not used for training. Free and Pro tier code handling depends on the user’s privacy settings. The specific data-handling commitments are detailed in Cursor’s privacy documentation and are typical for the AI-tool category.
How does Composer 2.5 compare to the upcoming Cursor + SpaceXAI from-scratch model? Comparison is not possible yet because the from-scratch model has not been released. The expected positioning is that the from-scratch model targets the capability frontier (competing more directly with Opus and GPT-5.5) while the Composer 2.x lineage continues to target the cost-efficiency lane.
Is there a Composer model for non-coding work? Not as of mid-2026. The Composer model lineage is specifically tuned for agentic coding workloads. For non-coding work in Cursor (chat with the AI about general topics, for example), the frontier-model routing remains the default.
Should I expect a Composer 3 soon? Cursor’s release cadence has been every 3-4 months for the Composer line. If the pattern continues, a Composer 3 release would land in the August-October 2026 window. The SpaceXAI from-scratch model may be released under a different naming convention if it lands in the same timefr
