Yeah I’ve been getting this issue way more frequently in the last couple of days.
Having to restart the conversation and fix the mess that happens at new conversations is just so discouraging…
World record 79 interactions through composer and bang hit the limit were now it wont do anything, lol
With version 0.44.11, I’m now getting a mix of the above problems, sometimes the message that the conversation is too long can happen with 10 messages, 30, 50, it seems to be quite random as sometimes it happens with few messages, but it also happens that I don’t get the message anymore but in practice it’s as if I did, as composer stays in “Generating”, and the input box becomes available again with the prompt, and nothing happens, until I open a new composer and start over… Complicated.
1 Like
been getting the exact same thing numerous times a day for the last few days…composer just seems to seize up, often in the middle of an operation, requiring a new session start, full agent reorientation, and then attempting to fix the partially updated issue which often takes longer than the initial implementation.
It’s gotten to the point where its borderline unusable for me and i’ve wasted so much time…unbelievably frustrating. this is on 44.11 with premium and extra fast tokens.
& @isarmstrong – when I get the three dots, it ‘most times’ recovers if I type ‘continue’ or even ‘?’
But if its already lost context, there is no hope.
I’m no longer seeing the “too long” message, but the behavior of getting stuck on “generating” until a new composer is created happens after very few interactions. I assume it’s the same issue — it just seems that the way the Cursor API responds to the event, and how the IDE handles it, has changed.
It’s been almost three weeks since this started, and unfortunately, it’s becoming increasingly unusable. At first, we tried to maintain context and history in a minified way with each new composer when hitting the limit, but with little success. Then, we managed to continue using long composers, but with an excessive resource consumption that made the IDE nearly unusable.
It feels like we’ve had to adjust our usage to follow the variations of the bug, which has steadily degraded the experience.
1 Like
Honestly, I have an entire sub-app dedicated to managing long term memories and structures complete with an .sh init app. It’s a really cool pattern but it’s also kind of crazy that I had to come up with it. It’s been interesting to learn how a lot of you are managing context and memory though.
Note to self: if I ever want to innovate on a popular product for engineers, all I have to do is break something irritating and watch the forums for 3 weeks.
Seems like this is still happening more than we think it should, so I’ve passed this back to the team and hopefully will see some improvements soon!
Seems like this is still happening more than we think it should, so I’ve passed this back to the team and hopefully will see some improvements soon!
I’m a bit concerned about the “it should” part — specifically, the message limit that kicks in after a while in the composer. Is this something that will become common now?
Even though we keep context files and project details updated, there are many instances where it feels like new composers don’t take them into account. Beyond that, small details come up repeatedly, forcing us to explain the same things over and over. A lot of time gets wasted “retraining” the composer to understand everything again, especially when it keeps making the same mistakes.
The most frustrating part is that once we finally get it to the right point, we hit the limit again and have to start from scratch. In my case, I feel like I’m spending more time doing this than actually making progress on my projects.
In my humble opinion, this is something that shouldn’t happen in a paid product, especially after so many weeks of it persisting. It seems like a “bug” — or maybe it isn’t considered one anymore — that fundamentally changes how we use the product and, in many cases, could even render it unviable for medium, large, or complex projects.
I must admit that this comment may not add much value, but it might resonate with shared opinions among others. I use cursor rules and keep detailed project notes and logs of my changes and adjustments. However, starting a new composer can only resolve the ongoing issue when frozen. While it’s not necessary to retrain everything from scratch—thanks to my rules and notes—the real challenge lies in the probabilistic algorithm with which each new instance begins. Even if I import my rules and project notes, the app’s code defaults to a baseline algorithm, undermining continuity.
Yesterday was fantastic! After retraining the composer—having been stuck generating content the day before—I had the best experience I’ve ever had with Cursor and Claude. Unfortunately, the system has failed again, either timing out and instructing me to contact support or remaining stuck on “Generating…”. Now, I need to start a new composer, forcing me to retrain everything from scratch once more. This is incredibly frustrating—it’s like taking one step forward and two steps back.
As an AI integrated with an IDE, this system can become ineffective. Starting a new composer often results in AI overreach, leading to code sprawl, duplicated work, and a bloated codebase. Instead of adhering to instructions, or cursorrules, it frequently makes assumptions about what I want (e.g., crossing road theory). Proper retraining requires time and effort, yet the short-term results are often poor and costly. This process wastes valuable hours and risks jeopardizing project timelines.
Perhaps someday, there will be a way to export a composer and condense it into a concise, transferable format for use in a new composer tab. Anything that could eliminate the need for repeated retraining would be a significant improvement.
For now, the biggest blessing would be getting it back up and running. I’ll finish my commit and then open a new composer again.
1 Like
Yeah just updated now while enjoyed some holidays and its still giving me the same Conversation too long error.
Oh, yeah this is the other version of it.
And the comedic timing of it makes me wonder if Composer is sentient and actually an a**hole, lol. EVERY TIME.
