Funny right after my post above, I asked Cursor to do again a similar work that I just showed/told/explained what gaps it did when updating 2 parts in B using A as pattern. And it recognized where and fixed it. But now I just asked it to do the same on C using A… The same gaps, had missing parts! Now I can attest that this is a real issue - even for pattern coding of a snippet - that Composer2 loses context so easily, and just skips easily parts is not acceptable. This could lead to a lot of code drift if left unchecked.
Please bring back Composer 1.5 it was so good and 2 Fast is pretty garbage.
2 takes forever.
2 Fast forgets context and ignores rules in .cursor/rules and AGENTS.md
Real, Composer 1 was not nearly as capable. At the time though, the reason I used it for easier things was because it was so much faster than every other model, specifically GPT 5/5.1 on high, it wasn’t even on the same planet. Like using the Space Shuttle instead of a Lambo. Sure, one is nicer, but it’s still painfully slow compared to a literal rocket.
After two weeks of agony using Composer2, I too have resigned to the idea that I cant trust it to do solid code. I see first hand the kind of gaps it created on the code. Today alone, I thought I can have it do some small tasks (evaluate a bug), and it kept going in circle changing code like its playing guesswork. And the worse part, it kept giving this loongggg analysis of technical blurb (I can sense its a way to make it look like superior). But I know whats going on. So after 2+ hours I gave up (this was earlier today). So I changed the agent to Sonnet, the in a quick glance, Sonnet fixed the thing in one swoop, no blurb, scan, found, fix - very quick. The feeling of having an agent that you can feel comfortable giving work was amazing!!! The past two weeks was pure agony that the feeling after Sonnet made quick fix was a real one. Now I feel the difference between a solid LLM and a crappy one. I will not go back to Composer anytime soon.
They never intended to keep 1.5 it was a model with more parameters, that was more capable than their quantized comp2. They never intended for it to run on auto usage when they released it, but the backlash on the cost was the main reason they did that, and when they realized they weren’t fleecing us for $$$ they had to pull it down and put up something cheaper to run i stg.
i feel composer 2 is costly and consuming too many tokens in short period and tell me how to use composer 1,5 in auto mode i dont want 2.0 .
Composer 1.5 was usable, Composer 2 consistently fails to listen to instructions - makes beginner coding mistakes, duplicates code all over the place. It’s OK, but unfortunately, in the time passed since Composer 1.5 came out Claude got a whole lot better and Composer 2.0 got worse.
I agree with people who say Composer 2 over-engineer stuff and make assumptions. I much prefer Kimi K2.5 which it is based on. To me Kimi is more “Claude like” in its coding style and ability to write concise yet informative documentations. Whatever additional training they did completely changed it’s behavior.
I haven’t found more mistakes in the code it writes vs. Kimi or Composer 1.5, but the formatting is less readable and I waste more time reviewing and removing the unnecessary code it keeps adding despite rules instructing against it.
Nah, Composer 1.5 was excellent at understanding what we asked for.
When a task was more difficult it assumed a smaller more doable task.
In other words, it knew what it was capable of.
Composer 2.0 thinks its Claude Opus 4.6 and acts like GPT-5.4 Mini making many really wrong undisclosed assumptions. So you can’t even predict its going to spend next 10 million tokens doing completely something else than what you asked for. That never happen with Composer 1.5, as it always asked questions instead of making stupid assumptions.
Yes, Composer 2.0 acts like a excellent programmer who makes no coding mistakes, but you can’t trust its reasoning.
It can be excellent as a sub-task agent when it receives exact very clear specific detailed instructions by a more intelligent model.
I absolutely love Composer 1.5, with its construction-level coding capability and dry, focused communication that has become my daily driver.
Enough has been said in this thread about the specific differences that I don’t care to repeat, but I can say that I won’t be switching to 2.0 and will have to choose something outside Cursor when 1.5 becomes unavailable.
It’s….. pretty bad. Like GPT 4, maybe 3.5 bad.
It gets stuff egregiously wrong more often than not, the code it outputs is insanely complex for simple tasks, it never removes code, just adds it. It often forgets tasks & constraints literally within 1 turn.
It’s bad, so bad that it’s actually faster to write code by hand than use composer 2. Seriously, I could spend 3h writing it by hand, or I can spend 30m having composer write it and 4h fixing it and 50x the tokens.
You cannot trust it, that’s the biggest failing. You really cannot trust it with your codebase, it outputs trash, and then spreads that trash as far as possible.
IDK how you get the numbers you get on your benchmarks, but they are wrong, misleading, or fabricated.
This, very much this.
I was making really good feature progress with auto mode and heavy guardrails, and then overnight it essentially dumped out hundreds of files of slop regardless of the guardrails, I didn’t realize this for a couple days, by then it was too late.
Turns out it was composer 2. It’s been 1 week and I’m STILL slogging through it all and trying to un-f it.
Would not recommend.
A lot of great answers to this. I have experienced with disappointment all the issues previous individuals explained myself as well.
The problem is obviously related to the fact that Cursor 2 is way smaller as a model than Cursor 1.5. The issues we all face are ones from smaller models.
One specific but critically important issue is that small models have very short attention span and are incapable of proper generalization required for important “understanding” of scope. Especially in small models we see a characteristic of transformers where they pattern-match to the opposite of what is being prompted - this is a known feature - in large models it provides proper generalization, but in small you get very easily lost in translation.
For example you say something like: “I told you that this is not the case because this and that”
The model responds something like: “I agree that this and that IS the case, you are right” - which is the exact opposite of what the user said.
Anyway, there is something way more important that we are all trying to say to you. Composer 1.5 WAS A REALLY GOOD MODEL in the sense it touched frontier level of quality! I mean personally I had a great experience with it as a user who works with all frontier models for years now every day and in highly complex tasks. It was a breakthrough and you should definitely reinstate and keep upgrading it!
Keep two models and train the small model with the larger one.
This is my version:
Version: 3.0.16 (system setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
I never got on with Composer 1.5, but was mostly spamming Anthropic via opencode at that time. I find Composer 2 great, but do prefer other models for planning. Composer is a great executor or search agent and fixer of small issues – for bigger tasks you do need to pull out GPT 5.4 to verify and expand upon plans
I do wonder if 1.5 used a different base, perhaps GLM/DeepSeek (whilst 1 & 2 are Kimi)
Why composer is not free for forever.. ?