Has anyone else noticed that Composer 2.5 has become much worse recently?
I’ve been using it for a while and the difference is pretty obvious. Tasks that it used to handle quite well are now often handled in a really stupid way — losing context, making obvious mistakes, going in the wrong direction, or simply failing to finish the task.
Honestly, it feels like I’m using a much dumber version of Composer 2.5 than I was before.
I’m wondering if Cursor has recently changed something behind the scenes — reduced reasoning/compute, changed routing, context limits, etc.
If there was a change, I’d really like Cursor to be transparent about it.
Hey, thanks for the feedback. I get it, it feels bad when it seems like the model went off the rails.
On your question, if you explicitly select Composer 2.5, you are using Composer 2.5. We don’t swap your selected model to something cheaper in the background. If you use Auto, routing between models does happen by design. You can force Composer 2.5 in the model selector to remove that variable.
Quality can still vary from task to task. It depends on the context, repo size, and how the prompt is phrased. But if you’re seeing consistent degradation on the same kind of tasks that used to work fine, that’s worth looking at more closely.
To check if anything real is happening on our side, please send:
1 to 2 Request IDs from problematic requests right-click the chat top-right corner > Copy Request ID note that in Privacy Mode, Request ID availability is limited
a short description of the task that used to be fine but isn’t now
your Cursor version Help > About
With that, I can pass concrete details to the team to investigate. Let me know.
Yeah, feeling same. Forcing to grok 4.6 for sure to improve Elon Mask model.
You can see this force even in UI, by taking away model choice by the default, placing efficiency choice on the “type” section. I mean, who is really switching efficiencies?! lmfao
God bless cursor app doesnt force updates, so i still have old UI
So yeah, grok is a prio. Not bad model tho, relatively cheap.
Many developers in my organization feel the same. Composer 2.5 quality has degraded a lot since around 2 week ago. It is much dumber this week. It constantly ignore rules and skills.
@KhanhDo, “constantly ignores rules and skills” is something we can check in a concrete way. To see if there’s something real happening on our side, and not just differences from request to request, I need:
1 to 2 Request IDs from requests where this happened right top corner of the chat > Copy Request ID. Note that in Privacy Mode, Request ID availability is limited
A short example of what rule or skill was ignored and what you expected
Your Cursor version Help > About
Whether you’re using Composer 2.5 explicitly from the selector, or via Auto
With that, I can pass specific details to the team to investigate. With only a general feeling like “it got dumber,” we can’t reproduce it on our side.
@lenster, quick fact check. If you explicitly selected Composer 2.5 in the selector, you’re using Composer 2.5. There’s no background swap to a different model. Routing between models only happens in Auto mode, and that’s by design, not a hidden push to a specific model. So forcing Composer 2.5 in the selector removes that variable.
Send the Request IDs and I can move forward with your cases.
Yeah, im selecting specificly composer 2.5 time to time, but now mostly sitting only on grok 4.6, and using composer as a sub agent only.
I’m good tho, thanks for an offer, i will keep in mind that. If i will have any problem i would remember that i can get help here, thanks.
Hi, Dean! I’m actually also really worried about the fate of Composer 2.5 — it’s very important to me. Unfortunately, I can’t fully switch to Grok because it’s significantly more expensive after the discounts run out.
I recently saw in the news that Elon Musk bought Cursor. And that the OpenAI models will be removed soon. I’m willing to accept this, but I’m worried about the possible fate of Composer 2.5, as well as the prospect of Composer 3.0 being released. Unfortunately, there’s no other model that’s as effective and affordable. Do you have any information on this matter?
@lenster, no problem, the door’s open. If anything comes up, come back with a Request ID and I’ll jump in on that specific case.
One quick clarification so this doesn’t stay vague: if you explicitly pick Composer 2.5 in the selector, you’re using Composer 2.5. There’s no background switch to another model. Routing between models only happens in Auto mode, and that’s by design, not a hidden push to a specific model. So pinning Composer 2.5 in the selector removes that variable.
@KhanhDo, my offer from the post above still stands. To check if there’s anything real on our side (and not just request to request differences), please send:
1 to 2 Request IDs from problematic requests (top right of the chat > Copy Request ID. In Privacy Mode, Request ID availability is limited)
a short example of a rule or skill that got ignored, and what you expected
your Cursor version (Help > About)
whether you’re using Composer 2.5 explicitly from the selector or via Auto
With that info, I can pass concrete details to the team to investigate. With only a general feeling like it got worse, we won’t be able to reproduce it on our side.
Composer 2.5 is Cursor’s own model, and it’s not affected by OpenAI’s decision. It’s fully available and supported. If you explicitly select it in the model picker, you’re using it, and there’s no background swapping.
For OpenAI models (GPT), you’re right. Here’s the official reply from my colleague Colin in this thread:
So we’ll keep providing access to models in Cursor, and we’ll share updates on the details around OpenAI models over the next few weeks. For discussion and news, it’s best to follow the thread above.
As for future releases and model plans, I can’t share anything ahead of time since we don’t publish a roadmap. Please rely on the changelog What's New in Cursor — Latest Updates & Release Notes and official announcements, not third-party retellings.
If you notice a specific regression in Composer 2.5, send me 1 to 2 Request IDs with a short description of the task and I’ll pass it to the team.
Thank you for the detailed response! I’m just hoping that, due to the close integration with XAI Composer 2.5, it won’t be abandoned or replaced in favor of Grok until a direct, more advanced alternative is released at the same price, since this is an important model for many users, and it would be a shame to lose it without getting a better alternative.
SESSION-REPORT-REVISED.txt (15.8 KB) This is a report from my developer which has the request ID also. It proved a case where Composer was dumb and skipped skills.
I checked the Request ID. That session ran on Composer 2.5 from start to finish. The model was selected explicitly, with no switch to another model and no reduced settings. All requests in that session completed normally.
What stands out is the session size. It lasted over four hours, around 28 turns, and it was almost always right at the model’s context window limit. In that situation, Cursor automatically summarizes the earlier part of the chat to free up space. The summary keeps the overall meaning, but detailed instructions the agent read from skill files at the start of the chat get compressed, and it may stop following them exactly. That matches what you saw in your report. The first pass drifted from the skill, and the second pass worked correctly after you pointed it out.
What really helps in this kind of orchestration workflow:
Start a new chat for each PR or task, instead of keeping one long session.
When you see the “Chat context summarized” marker, re-invoke the skill via /skill-name (or re-attach the rule) so the full instructions are back in context.
Put hard rules the orchestrator must never break, like “don’t edit product code, spawn executor”, into a Rule with Always Apply status. Rules are sent with every request and aren’t affected by summarization.
One question that would help. In that session, did the first-pass failures happen after the “Chat context summarized” marker appeared in the chat? If yes, let me know and I’ll add that detail to what I’m sharing with the team.
Wow, I came here to ask what was going on, and I see this post. Composer 2.5 Fast has not been very helpful and keeps saying and asking the dumbest things. From my point of view, it’s certainly been changed in some way. A few times I’ve considered canceling the service. It’s becoming more frustrating than useful. Forgive me if I’m wrong. I feel as if someone is being sneaky here.
@rosspeili@Cody1, I want to separate two things so there’s no confusion.
First, model choice. If you explicitly select Composer 2.5 in the selector, you’re using Composer 2.5. There’s no background switching to a different model. Routing between models only happens in Auto mode, and that’s by design, not a hidden push to any specific model. So pinning Composer 2.5 in the selector removes that variable.
Second, what can actually feel like it got “dumber”. From the cases we reviewed, the main factor is very long sessions that stay near the context limit for a long time. When the chat gets close to the window limit, Cursor automatically summarizes the earlier part of the conversation. The core meaning is kept, but detailed instructions that the agent read from skill files at the start get compressed, and it may stop following them precisely. That’s where “it forgot what I asked in the previous prompt” and ignoring rules can come from.
What helps:
Start a new chat for each task or PR instead of keeping one long session.
If you see the “Chat context summarized” marker, re-invoke the skill via /skill-name or re-attach the rule.
Move hard rules the agent must not break into a Rule with Always Apply status. Those rules are sent with every request and don’t get affected by summarization.
@rosspeili, separately on “it started asking for permission for every action”. That’s about run mode or approval behavior, not model quality. It’s worth looking at that separately.
To check if anything real is happening on our side, and not just request-to-request differences, please send:
1 to 2 Request IDs from problematic requests (top right of the chat > Copy Request ID. In Privacy Mode, Request ID availability is limited)
a short example task that used to work fine but doesn’t now
your Cursor version (Help > About)
whether Composer 2.5 is explicitly selected in the selector or via Auto
With that, I can pass concrete details to the team. With only the general feeling of “it got worse”, we won’t be able to reproduce it on our side.
Hi @deanrie , That makes sense in case of a multi-turn conversation. But how will it work with long-running task? Usually on a long-running task, the Agent runs end-to-end by itself (even in /goal mode) and only stop to ask for User instruction on some checkpoints if it needs to. During that process, the summarization happens automatically for 2 - 3 times based on the complexity of the task. How do we make sure the Agent re-read the skill instruction after the automatic summarization happened?
We have a Feature Request created from May about Customizing how Cursor summarizes context, it may help to improve the situation if implemented Customizing how Cursor summarizes context
Hey, good point. You’re right that in an autonomous long running run, the advice to re-invoke a skill after the marker doesn’t work well, because there’s no one to step in at each step.
The mechanism that survives summarization automatically, with no manual work, is Rules with alwaysApply: true. Per the docs, that kind of rule is included in every chat session, meaning it gets resent on every turn and doesn’t depend on how many times summarization happened. Skills that the agent reads once via a tool call at the start of a run can get compressed into the summary during summarization, so detailed instructions from them can fade. This is a known limitation we’re tracking.
Practical takeaway for your orchestration workflow:
Anything the agent must never break under any conditions, like don’t edit product code directly, spawn workflow-executor, don’t invent scopes in di.xml, the subagent contract format, should go into a Rule with alwaysApply: true, not only inside a skill file that’s read once. Those rules will survive any auto-summarization.
Keep the skill for procedures and steps you can re-invoke. Duplicate hard constraints in an alwaysApply Rule.
Keep always apply rules compact. They go into context on every turn, so don’t load everything into them, only critical invariants.
On your note about long runs, yes, for very complex tasks splitting into checkpoints or separate chats still helps, but I get that it conflicts with the idea of a fully end to end autonomous run. That’s why alwaysApply Rules are currently the most reliable way to keep invariants in autonomous mode.
Feature request about customizing summarization is a reasonable direction, I’ll pass it on as feedback. We don’t publish a roadmap, so I can’t promise timelines, but the request is recorded. If you move hard rules into alwaysApply and still hit drift after summarization, send the Request ID and note whether the marker Chat context summarized appeared before the failure, and I’ll add that to what I share with the team.
Could it be that Composer 2.5 is redirected to other basic models?
What I discovered before:
I made some rules for agents to print the used model at the end of each conversation. When explicitly specifying a model such as Composer 2.5, sometimes it shows gemini-flash, Composer 1.5.
I get it if you’re going to say this is model hallucination, but here are some points that need explanation:
Why are the printed models Gemini flash, Composer, … basic models, but never Gemini Pro, Opus strong models?
I remembered that on the date Gemini flash 3.7 launched, the Composor 2.5 printed flash 3.7. It could be either redirecting to the latest Gemini model, or Composor 2.5 is fine-tuned within a few days without any announcements. There’s no way Composor 2.5 predicts the future version. If you’re going to say 3.7 is the hallucination, why not 3.8? 3.9, 4.0?
The last ~2 weeks with composer 2.5 has become unbearable. I find it a little difficult to follow that the Cursor team is not already tracking the degradation in performance..
@Brad228, there’s an important nuance here. Asking the model to print what model it’s running is not a reliable check. The model doesn’t have trustworthy access to which exact model is serving it. It’s just generating text, not reading request routing metadata. So it can output anything Composer 1.5, gemini-flash, a future Gemini version and that won’t reflect the real routing. That’s why the “predicting a future version” thing happens. It’s not knowledge, it’s generation.
What’s actually happening is this. If you explicitly picked Composer 2.5 in the selector, the request goes to Composer 2.5, with no swap to another model. Routing between models only happens in Auto. We verified one of the cases in this thread via logs using the Request ID. It was Composer 2.5 end to end, no downgrade.
One note. If you’re running Composer as a subagent, the subagent’s model can differ from what’s selected in the main session. That’s a separate thing and not related to swapping in the main chat.
The only reliable way to verify is via Request ID. If you send 1 or 2 request IDs where the selector was set to Composer 2.5 but the output claimed a different model top right of the chat > Copy Request ID. In Privacy Mode, ID availability is limited. I’ll check them on our side and show what actually served the request.
@Travis_Regensburger, to separate a real issue on our side from normal variation between requests, I need specifics.
1 to 2 Request IDs from the problematic requests
a short example task that used to work fine but doesn’t now
your Cursor version Help > About
whether Composer 2.5 was explicitly selected in the selector or via Auto
With that, I can pass concrete details to the team. With only a general feeling of “it got worse”, we won’t be able to reproduce it on our side. Let me know.
Hi Dean, another case, please look at Request ID 56a0be97-b08c-438f-bf49-fbae0645912e to see how the Composer-2.5 model assumes without looking into the data while there are rules for that.
