More training scale, still aggressive pricing, and a better model for long-running coding work.
That is Composer 2.5 in a nutshell.
It continues from the same base as Composer 2, and this version is trained to be better at sustained work, complex instructions, communication style, and effort calibration inside Cursor.
Targeted textual feedback helps the model improve specific mistakes inside long rollouts, while 25x more synthetic tasks push it into harder coding problems grounded in real codebases.
Looking forward to the next larger model trained from scratch with 10x more compute!
That was a no-brainer upvote! Testing Composer 2.5 since yesterday, and I'm extremely impressed. 2.0 was already a good one, but with 2.5, I feel like there's no need for Opus or GPT-5.5. Great job!
Report
The focus on long-horizon agentic tasks is the right unlock for real coding workflows. We've run into this building RetainSure where the model drops context mid-task once the chain gets 20+ steps deep. How does Composer 2.5 handle state management across very long multi-file agentic sessions, and is there a hard limit on task length before it degrades?
Report
Nice to see the new models and I have been using Composer this morning - sorry for the reality check - but c'mon - Composer 2.5 does not really compare well against Opus 4.7 or Sonnet.
Report
Specializing a model for code editing workflows rather than pure generation is the right call. Generic models fall apart on multi-file edits because they lose track of interdependencies. Building RetainSure, we've hit that quality cliff when an agent touches more than three or four tightly coupled files. How does Composer 2.5 handle semantic conflicts when simultaneous edits across files introduce inconsistencies?
Report
The effort calibration piece stands out to me. We've had agents lose coherence around step 6 or 7 in a long agentic chain, and it's tough to know if that's model drift or context decay. Curious how the targeted textual feedback is applied: at the step level within a rollout, or on the full trajectory?
Report
Has the team experimented with giving the agent more awareness of runtime behavior — like logs or error traces — so it can reason about what's actually happening vs just what the code says? Curious if that's on the roadmap.
Report
the shift from composer as a feature to composer as a versioned product with its own release cadence is an interesting signal about where Cursor thinks the value actually lives. it's not the editor anymore, it's the agent layer on top of it
Replies
Flowtica Scribe
Hi everyone!
More training scale, still aggressive pricing, and a better model for long-running coding work.
That is Composer 2.5 in a nutshell.
It continues from the same base as Composer 2, and this version is trained to be better at sustained work, complex instructions, communication style, and effort calibration inside Cursor.
Targeted textual feedback helps the model improve specific mistakes inside long rollouts, while 25x more synthetic tasks push it into harder coding problems grounded in real codebases.
Looking forward to the next larger model trained from scratch with 10x more compute!
Tabstack by Mozilla
@zaczuo S/O to Moonshot's Kimi K2.5!
Elentaria
Love cursor, been a power user for a long time now, and happy to see the native model getting better and better.
Unabyss
That was a no-brainer upvote! Testing Composer 2.5 since yesterday, and I'm extremely impressed. 2.0 was already a good one, but with 2.5, I feel like there's no need for Opus or GPT-5.5. Great job!
The focus on long-horizon agentic tasks is the right unlock for real coding workflows. We've run into this building RetainSure where the model drops context mid-task once the chain gets 20+ steps deep. How does Composer 2.5 handle state management across very long multi-file agentic sessions, and is there a hard limit on task length before it degrades?
Nice to see the new models and I have been using Composer this morning - sorry for the reality check - but c'mon - Composer 2.5 does not really compare well against Opus 4.7 or Sonnet.
Specializing a model for code editing workflows rather than pure generation is the right call. Generic models fall apart on multi-file edits because they lose track of interdependencies. Building RetainSure, we've hit that quality cliff when an agent touches more than three or four tightly coupled files. How does Composer 2.5 handle semantic conflicts when simultaneous edits across files introduce inconsistencies?
The effort calibration piece stands out to me. We've had agents lose coherence around step 6 or 7 in a long agentic chain, and it's tough to know if that's model drift or context decay. Curious how the targeted textual feedback is applied: at the step level within a rollout, or on the full trajectory?
Has the team experimented with giving the agent more awareness of runtime behavior — like logs or error traces — so it can reason about what's actually happening vs just what the code says? Curious if that's on the roadmap.
the shift from composer as a feature to composer as a versioned product with its own release cadence is an interesting signal about where Cursor thinks the value actually lives. it's not the editor anymore, it's the agent layer on top of it
Migma AI
Lets goo!!