Users have reported an issue where Composer 2.5 uses <motion> instead of <div>. This should be fixed now, but discussions happening over in this thread!
I was using Composer 2 regularly and it was already great in terms of cost VS performance, but I definitely saw a big improvement with Composer 2.5! It’s as good as a medium effort flagship model, which is way enough for most tasks, and it’s still the same price as Composer 2, so obviously I’m very satisfied.
I hope that Composer will continue to evolve over time to stay this really great compromise, even if Cursor proposes an even more premium one in parallel
I like where composer is going. 2.5 feels like an intelligent progress from the previous 2.0.
Some critical feedback: composer 2.5 feels a little unhinged and seems to spend less time thinking and more doing. Which is great for simple tasks but whenever I gave it something more complex, it didn’t think for long before it started doing.
Now this is fine if you want composer to be more like a utiliser rather than coding partner. One example: I had a security flaw where users could change the price metadata of something, composer created over 500 lines of mess. I gave the same prompt and problem to Opus 4.6 High and it spent a long time thinking, and came back fixed it with about 10 lines of code.
This is where it’s important to separate an agent’s abilities into three categories:
- Reading
- Coding
- Thinking
I don’t know where composer sits but for me: Opus is in the Thinking category, Sonnet and Codex can be in the Coding, while Gemini Flash might be Reading category for me.
The difference that I want to see though, is honesty, brutal honesty (not of the sake of arguing, but because it has data that stands against my thoughts). Push back, go double check things, check online, but bring a version that has a more worldly view on the best approach in the current environment. Now, current means look at the codebase and figure out if this is B2B, B2C, small, medium or large business software, who is audience, etc. These overarching details help us decide how much effort to put in.
e.g. I would never create helper functions if a piece of code was used once. Composer always decides to create a lot of bloat like I’m building an enterprise SaaS product for 100m people. This is great but not always necessary. It sometimes makes it confusing to follow and just understand what is going on.
Another advantage would be to have better comments and auto-documentation built in. e.g. “Do you want this documented?” Then go and add it into a folder /docs/ or something like that. You should be extending the agent into other areas that help businesses keep on top of changes and manage their features.
I hope this feedback helps 
It’s a great product. very fast and noticeable improvement.
it still require self checks and iterations.
Keep doing great work Cursor !
Hi Team,
Overall positive experience with composer 2.5 in it’s communication style. Much improved at explanation, leverages diagram and visual effectively, and provide summary and conclusion. Overall, I see clear improvement. I also executed many smaller fixes and features and it has been smooth.
In one instance where I needed a bigger scope refactor. I find that the plan was on the brief side for how complex the scope is. In addition, it executed with a lot of logical misses. There were a ton of bugbot fixes needed to get this one clean (details below)
Request ID Reference: bc-1d2a72ed-d7df-4e3b-bcd7-afa1cadb7007
Context: This was a multi-file backend refactor (~3k LOC): merge two divergent code paths into one shared “generate structured workout → validate → write DB” pipeline, wired from both a batch nightly job and an interactive coach tool. Human review + Bugbot ran ~50 fix commits after the first “working” implementation. Below is what went wrong in general terms an agent team can act on—no app domain required.
Composer 2.5 is strong at success-case flow architecture but weak at data-boundary discipline, applying fixes symmetrically, and error-path semantics—the sort of bugs that slip past typecheck and simple unit tests but show up as long review/autofix loops.
Most bugs were logic at boundaries:
- The same mistake was often fixed in one place and left in another, so it doesnt check related surfaces well enough
- Small patches broke unrelated behavior (e.g. a performance optimization nullified by a bad
if/elseedit).
Disclosing sample of plan in attached for reference if the team wants to review for future improvement
When using a frontier model in plan mode, Cursor still automatically switches to Composer 2 for the build step. Probably not intentional if you are retiring it?
hi @mmh, this is surely because you either selected or cursor did manually composer 2.0, the quick fix is to go in settings and manually set once either a stronger model or what I like to do is to set it as inherit, so that I don’t have to check what model will be used since I already knew
Good job guys! After spending 1000-2000USD per month on gpt 5.5 and opus 4.6 and 4.7 I feel I can just use composer 2.5 fast for 200USD per month for almost the same result, and its so mutch faster!! I love the speed of it! Only feedback would be to make it use thinking a little bit more, its so eager to execute.
Hi Tom,
Thanks for the prompt reply. However, I don’t fully understand your phrasing.
Every time I used GPT-5.5 in plan mode, then pressed the “Build” button, the chat switched to Composer 2 for building. Is there a separate setting to set a default model for the build (plan execution) process?
I can try a screen recording later today if needed.
These are/were my model settings:
Composer 2.5 seems to also be able to carry a conversation better. Composer 2 would often speak in a more '“code-like language”, making me have to switch to Auto or Claude for conversational sections of the build process.
Now I can leave it on Composer most of the time. Anyone experience the same?
For overarching architecture and to get out of a rut, I’m still invoking Opus 4.7 by default, but maybe I could be more trusting?
I’m still using Opus for overarching work. i.e. planning, conversations.
When I have my work planned out I use medium reasoning agents to implement the work.
excited to use Compser 2.5 at 90% off!! thanks for the Python SDK guys
Amazing @Tom_Coustols , let us know what you build this weekend with it 90% off!
yay! currently building something that will make use of all the useful ressources of this forum!
Pretty elite tbh
Does the 90% discount on the Composer 2.5 SDK offered this long weekend apply to the Node/TS SDK? Or is it only when used from Python?
Composer 2.5 is totally not good at conversations. You have to nudge and push and remind it every turn of the original intent, what is working, what is distracting and it often acts like you just hired a rideshare driver instead of a capable high-reasoning 2026 model, just above 40k tokens of context used.
Attention to detail is like 95% of Opus 4.7.
Simplicity of implementation is like GPT-5.5.
But there is always a snag, a missed point, a dice roll for what some words mean, a wild ride outside the box when it gets distracted by tool calls and forgets user imperatives. Single user usage is very cheap, I calculated budgets close to 2000$ on the Cursor Pro+ plan, that’s enough for 35 days of work every month.
But I can never leave it unattended or without review as a single mistake will lose hours of work. I don’t need to double-check Opus or GPT at all, at a glance I can see they understood the task, thus it is finished correctly. Not so with Composer. Teenage behavior.
Cursor needs to work more on sub-agents, or sub-sub-agents and agentic workflows to increase the costs and results quality, as less than 100$ a month for full time senior engineer is not a sufficient value transfer.
Try again with my Agent Compass - maybe it’ll help.
I’m using it in Cursor-SDK and it works great; I’d say it’s wonderful; I’m thinking it might be an issue with the IDE itself.