Composer 2.5: Cursor’s Cheap Shot at Opus and GPT-5.5
Table of Content
- What actually dropped
- Benchmarks in dev language
- Speed and real-world vibes
- Cost: where things get ugly (for the big guys)
- So which one should you actually use?
What actually dropped
Cursor just pushed Composer 2.5, their new in-house coding model, and it’s not a toy update. It’s built on Moonshot’s Kimi K2.5 checkpoint, with a ton of extra pre-training and RL on top to focus on long, multi-step coding work. Most of the compute budget apparently went into that extra training instead of just inflating the base model.
They also changed how they steer the model: targeted RL with textual feedback to tune behavior like tool use, communication style, and “don’t rewrite my whole repo for a typo.” On paper, that means fewer derailed agents and more “do exactly what I asked, no more, no less.” In practice… it’s surprisingly close.
Composer 2.5 is now the default in Cursor, with Composer 2 still available if you miss the old chaos. Same base pricing as before, plus a faster (and more expensive) variant if you’re allergic to spinners.
Benchmarks in dev language
On coding benchmarks, Composer 2.5 is basically sitting in the same weight class as Claude Opus 4.7, and Cursor is not shy about it.
Numbers you actually care about:
- Terminal-Bench 2.0: Composer 2.5 at 69.3%, Opus 4.7 at 69.4%
- SWE-Bench Multilingual: 79.8% vs 80.5% in favor of Opus
- CursorBench (harder internal tasks): Composer 63.2%, Opus 64.8%
So no, it’s not “destroying” Opus, it’s basically mirroring it with a small penalty here and there. That’s already insane for a model that isn’t coming from Anthropic or OpenAI.
Compared to GPT-5.x land, Cursor and a few testers claim performance in the same ballpark as GPT-5.5 on coding-style tasks, especially relative to cost. BenchLM data also shows Composer 2.5 with a larger context window (200K) than a mid-tier GPT-5 model (128K), so for huge codebases it actually has an edge.
Speed and real-world vibes
Benchmarks are nice, but you don’t ship pull requests with charts. People using it inside Cursor report what actually matters: it feels fast and doesn’t wreck your repo as often.
One power user coming from GPT-5.5 says they ended up preferring Composer 2.5 for day-to-day coding because of the combo of speed, quality, and cost. They highlight that it places code in the right files, avoids massive unnecessary rewrites, and adapts to project conventions without needing five examples each time. Translation: fewer “why did you touch that file” moments in code review.
A few folks still swear by Opus 4.7 and say Composer 2.5 feels a bit less robust on the hardest tasks, which sounds fair given the benchmark gaps are small but not zero. But for typical “implement this feature, fix this bug, refactor this mess” workflows, Composer 2.5 seems to hold its own just fine.
If you care about latency and throughput more than theoretical IQ points, this is exactly the niche Cursor is aiming at: “good enough to be scary, cheap enough to leave on all day.”
Cost: where things get ugly (for the big guys)
Here’s where Composer 2.5 stops being “interesting” and starts being “annoying” for Opus and GPT-5.5.
Official Cursor pricing for Composer 2.5 standard:
- Input: 0.50 USD per 1M tokens.
- Output: 2.50 USD per 1M tokens.
Fast tier (same brain, more GPU):
- Input: 3.00 USD per 1M tokens.
- Output: 15.00 USD per 1M tokens.
By comparison, various breakdowns put Claude Opus 4.7 around 15 USD input and 75 USD output per 1M tokens. That makes Composer 2.5 roughly 10x cheaper on input and around 30x cheaper on output at list price. Analyses grouping Opus 4.7 and GPT-5.5 label both as “frontier-tier” pricing—several times more expensive than Composer 2.5 fast, never mind the cheap standard tier.
And for launch week, Cursor doubled the included usage, so heavy users basically get to stress-test the thing on Cursor’s tab. If you live inside Cursor all day, that’s the difference between “cool toy” and “default model because accounting hasn’t yelled at me yet.”
Quick snapshot:
| Model | Coding benchmarks (vs Opus) | Context window | Price in (per 1M) | Price out (per 1M) |
|---|---|---|---|---|
| Composer 2.5 | Within ~1-2 points of Opus 4.7 on key coding tests | 200K | 0.50 USD | 2.50 USD |
| Composer 2.5 fast | Same quality, lower latency | 200K | 3.00 USD | 15.00 USD |
| Claude Opus 4.7 | Slightly ahead on most coding metrics | N/A | ~15 USD | ~75 USD |
| GPT-5.5 (frontier) | Similar “frontier-tier” coding performance | ~128K (mid-tier GPT-5) | Frontier-tier, several× higher | Frontier-tier, several× higher |
So which one should you actually use?
If you’re already in Cursor and mostly doing code:
- Make Composer 2.5 your default.
- Keep Opus/GPT-5.5 in the drawer for the truly cursed tickets or for non-coding reasoning tasks where you know they still have an edge.
If you run big teams or agents hammering models all day, the economics are almost rude. Getting Opus-like coding performance for an order of magnitude less on tokens is hard to ignore, especially once you multiply that by CI jobs, refactors, and “please fix the tech debt I created in 2019.”
If you’re a benchmark maximalist who only trusts the absolute top number, Opus 4.7 and GPT-5.5 still look slightly better on paper and in some real-world feedback. But if you’re a busy dev who just wants fast, cheap help that doesn’t ruin your repo, Composer 2.5 hits a very sweet spot—and that’s probably exactly what Cursor was aiming for.
Day 1 verdict: Composer 2.5 delivers near-Opus coding performance at a price point that makes it the obvious default for most developers. The only question is whether the small quality gap matters more than the massive cost savings for your use case.