Share your experience with Composer 2!

@Colin It is just an example of chat. Firstly, I tried to fix the compilation error with Composer 2. Attempt 1 - error, Attempt 2 - error. Attempt 3 - Composer 2 returns to the initial variant. Fiasko! After that, I switched to Composer 1.5 and it resolve this problem from the first attempt. It does an elementary error.
```cpp

C:/Projects/ESP-IDF/SigmaTransfer/main/testSuiteFlow.cpp:189:22: error: cannot ‘dynamic_cast’ ‘transport’ (of type ‘class Sigma::NonOwningRefSigma::Transfer::ITransport’) to type ‘class Sigma::Transfer::ZeroTransport*’ (source is not a pointer)

Inspecting the code and NonOwningRef to fix the dynamic_cast error.

Casting the underlying pointer: transport is NonOwningRef, not ITransport*. dynamic_cast requires a pointer or reference to a polymorphic type. Using transport.get() (same pattern as elsewhere in the codebase for owned transport pointers).

testSuiteFlow.cpp
+1
-1
auto zTransport  = dynamic_cast<ZeroTransport*>(transport);
auto *zTransport = dynamic_cast<ZeroTransport *>(transport.get());
if (zTransport == nullptr) {
Here’s what was wrong and what we changed.

Cause: transport is a Sigma::NonOwningRef, not an ITransport*. dynamic_cast only works on pointers or references to polymorphic types, so casting the wrapper itself is invalid.

Fix: Cast the stored pointer, which NonOwningRef exposes with .get() (same idea as std::unique_ptr / std::shared_ptr):

auto *zTransport = dynamic_cast<ZeroTransport *>(transport.get());
After this change, the compiler should accept it. If your environment doesn’t have idf.py on PATH, run a full build in your usual ESP-IDF shell to confirm.

ESP-IDF Build (1046-1054)

testSuiteFlow.cpp
+1
-1
auto *zTransport = dynamic_cast<ZeroTransport *>(transport.get());
auto *zTransport = dynamic_cast<ZeroTransport *>(transport.Get());
if (zTransport == nullptr) {
Sigma::NonOwningRef exposes the raw pointer via Get() (PascalCase), not get().

Updated line:

auto *zTransport = dynamic_cast<ZeroTransport *>(transport.Get());
Rebuild in your ESP-IDF environment; that should clear the error. If the IDE still shows a dynamic_cast warning, it’s often clangd without the same flags as the IDF build—trust the full idf.py build result.

ESP-IDF Build (1046-1054)

Get() returns an ITransport&, not an ITransport*. dynamic_cast to a pointer requires a pointer — use the address of the reference:

testSuiteFlow.cpp
+1
-1
auto *zTransport = dynamic_cast<ZeroTransport *>(transport.Get());
auto *zTransport = dynamic_cast<ZeroTransport >(&transport.Get());
if (zTransport == nullptr) {
What was wrong: NonOwningRef::Get() gives you an ITransport&, not a pointer. dynamic_cast to ZeroTransport needs a pointer (or a reference with a different cast form).

Change: take the address so the source is an ITransport*:

auto *zTransport = dynamic_cast<ZeroTransport *>(&transport.Get());
ITransport is polymorphic (virtual destructor and methods), so this downcast is valid. Rebuild to confirm.

ESP-IDF Build (1046-1054)

Restoring the fix: the file still uses dynamic_cast<…>(transport.Get()); Get() returns a reference, so we need &transport.Get().

testSuiteFlow.cpp
+1
-1
auto *zTransport = dynamic_cast<ZeroTransport *>(transport.Get());
auto *zTransport = dynamic_cast<ZeroTransport *>(&transport.Get());
if (zTransport == nullptr) {
The compiler error is from using dynamic_cast on a reference: Get() returns ITransport&, so the operand must be a pointer.

Use the address of that reference:

auto *zTransport = dynamic_cast<ZeroTransport *>(&transport.Get());
That was missing again in your tree; it’s applied now. Re-run the build.

Why: dynamic_cast<T*>(x) needs x to be a pointer (or you use dynamic_cast<T&>(ref) for references). transport.Get() is the object, not a pointer, so you need &transport.Get() to get an ITransport*.

```

Crazy hallucination! Not doing things i ask to do, miles away from Opus 4.6 . Older models are much better, this model is guessing to much, not following tasks and “wants“ to do much but just makes more mess then helping. Honest opinion after working with this model for the last 3 days.

It severely overthinks extremely basic UI adjustments, making tiny changes take forever (compared to other models). Its communication can lean into the unnecessarily technical, as well. Communication is far more fluid with Claude or Codex. With that said, it’s done a decent enough job for me so far.

Composer 2 gets pretty much everything wrong in my case. And reading this thread seems I’m not alone. And now I get an email saying Composer 1.5 is going away in a week? Are you kidding me?

Composer 2 fails consistently, I don’t care what your benchmarks say. Things Composer 1.5 can one-shot fix, Composer 2 can’t get right after multiple turns.

I added an entire new prompt to my workflow after using Composer 2. I switch to Opus or even Composer 1.5 and tell it: “The last model can’t see to do anything right. Can you thoroughly review this chat and any referenced plans and fix this mess?”

I haven’t had that much of bad experience with Composer 2, was not any worse than most of the models that price. Put all benchmarks aside, from my experience if I want job to be done Opus is most reliable and leveled model, GPT does some things brilliant, but tends to overdo stuff or act confused sometimes and behind them Composer 2 does things pretty much as good as the rest or bit better but blazing fast so with little more effort in planning and writing more specific and detailed prompts combined with patience C2 can do the the job fair. I heard someone said once that biggest difference between Claude models and others is that Claude does the job despite bad prompts and it has proven to me many times since

same experience, orchestration is broken, instruction are not followed, composer 1.5 was probably not the smartest model, but it was quite good to work with. 2.0 at least for me is a step back. Will switch on antropic stuff for now.

Personally, I don’t trust Kimi K2.5. However, Cursor works great with Composer 2. Even when using the same base model, it has improved a lot.

Also doing things with Composer 2 is much better than with Composer 1.5. This will become my default model.

I noticed it doesn’t seem to display markdown the right way, instead, it just shows up as code. I think it could be improved to actually render the markdown like it’s supposed to.

I have had constant issues with Composer 2 that i have to keep reverting back to 1.5. Composer 2 over-engineers simple asks/tasks. Makes wild assumptions and performs changes that I do not ask for. Even trying to explicitly define guardrails of what is to add or update, it ignores those guardrails. I spend more time cleaning up unwanted changes than actually making forward progress. If Composer 1.5 is going to be retired, and these issues with 2 are not addressed, I will not be sticking around. I would rather have accuracy over speed any day. Just because it’s faster doesn’t make it better.

Yeah blowing away 1.5 after just a week of feedback is CRAZY.

@Collin can someone explain how this is being framed as an upgrade?

I just committed to the yearly Ultra plan. $2k because Composer 1.5 was working for me. Now a month later I’m being told the model I’m paying for is going away and I need to use something that makes my workflow worse.

In the last week and a half I’ve pushed over 560 million tokens through Cursor. ~410M on Composer 2/2-fast, ~135M on 1.5, ~19M on Opus for the hard stuff. I gave Composer 2 three times the token volume. I keep choosing 1.5.

Because Composer 2 doesn’t do what I ask it to do. It does what it thinks I should have asked.

I give it exact text to insert, specific wording, specific structure, and it rewrites it. Drops things I intentionally included, rephrases copy I didn’t ask it to rephrase, collapses structure I purposely separated. I shouldn’t have to tell my code editor “no really, I mean it” every time I give it an instruction.

1.5 follows my patterns. It reads my codebase and matches what’s there. When I give it literal input, it uses it. Composer 2 treats everything I say like a rough draft it needs to improve.

Calling it smarter and cheaper doesn’t matter if I’m spending extra time reviewing every change to make sure it didn’t add things I never asked for or rewrite things I told it to leave alone. That’s not faster. That’s more work.

I get the point of Composer 2. For new projects, for people who want more guidance, I can see the value. But in an established codebase with existing patterns and conventions, a model that proactively adds and changes things you didn’t ask for is a risk. That’s how subtle bugs get introduced. That’s how consistency breaks down.

And look, I’m not going to threaten to cancel. I’ll be real, there’s nowhere better to go right now. But that makes this worse, not better. You had something genuinely unique with 1.5. It felt like a true extra pair of hands, not a wild junior engineer who thinks they know your codebase better than you do. That’s rare. Every other model out there is racing to be smarter and more autonomous. 1.5 was the one that just listened.

Please keep it as an option. Even if it’s not the default.

I had exactly the same experience and questions. Composer 2 is not even close to being as intelligent as Opus 4.6, it’s also extremely lazy, I have to constantly force-feed it or drag it into fixing the problem like an agent would, instead its hell-bent on explaining how I should fix things, this is maddingly annoying. that chart is probably true but misleading - I dont know what that chart is actually showing… but it looked good because its in a higher position than Opus. But I doubt if that position mean much in any real context.

To be honest, I don’t understand people who previously used Composer 1 and Composer 1.5, given that they were as expensive as GPT-5.x, but noticeably dumber.

Currently, Composer 2 is charged separately and with a noticeably higher usage quota than other models, which makes it an excellent light-tasks model with almost free usage.

Drawn to Cursor from Claude Code by the Composer 2 release.

After getting used to Claude Code cli I’m more accustomed to the terminal instead of the IDE for agentic coding. Finding the Cursor IDE frustrating.

I won’t be using the Cursor CLI until it ships voice mode on Linux. Also team-wide and user-scoped rules seem to be stored in the db or the cloud (???) which is a big negative.

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I’m having serious problems with Composer 2 that didn’t occur in previous versions: loss of context, loss of modified source code, unsuccessful implementations with a high error rate, as well as basic Python syntax problems.

I’ve lost a significant portion of my AI credits having to fix problems generated by the AI ​​itself, which is clearly not ready for use.

I really like the cursor, but something clearly needs to be done urgently with Composer 2, which has been a terrible experience and has harmed my projects more than helped them.

Steps to Reproduce

Just by using composer 2 in more complex projects. The times that the context is lost and implementations are made out of the dev instructions it’s really alarming.

Expected Behavior

Enable downgrande to composer 1.5 again.

Operating System

Windows 10/11

Version Information

Version: 2.6.22 (system setup)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
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

For AI issues: which model did you use?

Composer 2

Does this stop you from using Cursor

Yes - Cursor is unusable

Composer 2 is nowhere around the claude opus. Composer 2 is getting frustrated atleast for me, generated crappy code again and again.

Composer 2 Fast is typically decent, but it almost feels like a downgrade compared to 1.5.

It will frequently add stupid comments to my code like

// Fixed height only — width: 100% on .repair-progress-bar was stretching vertically in a flex column
.repair-progress-bar.repair-progress-bar-full {
width: 100%;
height: 50px;
flex-shrink: 0;
}

And will often name things very verbosely and strangely.

I’m making a game and it fails with logic like “this should be 2x more efficient” and it will then make it so the benefit is 2x, but the cost of something will then also be 2x.

It fails often with 0 based counting. Example would be I have an upgrade system where you can get the bonus given at a level N. There is text telling the user what the bonus will be when you upgrade. The model will often miss that it needs to do N+1 to show the next upgrade level.

It ignores instructions in AGENTS.md and then even when reminded not to do something, will quickly forget that it was told not to do something and then will do it again.

It is worthless to me.

It doesn’t listen, it doesn’t seem to have the context size you say because it can not recall what was written 3 messages ago and the worst part for me, it gives me incomprehensible answers.
It is using extremely weird terms/language for everything.

My experience with Composer 2 is the worst possible, and it’s making me strongly consider another LLM for my developments.

Composer 2 frequently loses context without explanation, makes gross indentation and syntax errors in Python, doesn’t properly execute commands, and performs unsolicited implementations or corrections, inexplicably undoing corrections that have already been made.

Composer 2 is simply unsustainable and has made me consume far more AI credits than necessary for increasingly simple projects.

A downgrade to version 1.5 is not only necessary, it’s urgent, because clearly, version 2 lacks the necessary capacity to meet the quality standards of its predecessors.

Ive been a heavy user of Cursor since August. In fact I have two accounts - one for work, and for personal. I have created 6 apps on a big part using Cursor. I have noticed that the new Composer2:
1-makes too many mistakes
2-missed a lot of logic or parts
3-doesnt have the ability to look at patterns in other parts of the code even if told clearly,
4-doesnt regress well, if it changes the UI, it forgets to check the routes/repo
5-even changes excellent queries to nested queries of the same thing (this blows my mind)
6-and many more

Speed is not enough measure of productivity if it doesnt do enough to scope out and set the full context of a code change. In the past one week, I have seen more simple mistakes than in the past month of work. I feel the quality of work is inferior - again depth, accuracy, completeness is more important than speed. I spend half of the time checking every part of the agents work.

I learned to love CURSOR. Even if I have CLAUDE on the side doing some of the heavy lifting, I always have CURSOR on the side to do the bulk of the tasks (CLAUDE just sucks up tokens soo fast). But with this experience, Im willing now to take time to test out another LLM (I was in windsurf at the beg for a month, tested grok/openai/gemini LLM via API in the past… maybe moving to codex and go back to pure VSCODE). With the experience I have with Composer2, it’s no longer a happy place to do work… it’s becoming a pain to spend half of the time checking, fixing, and telling CURSOR to show the gaps). My 2 subscriptions will end in a week.

The only option I can see is if I can go back Composer 1.5. Is this possible?

Also, this is an echo of a similar post below… Maybe if there are more posts like this, CURSOR will hear us. Get rid off Kimi!