Hello Cursor, did you nerf Composer?
25 PRs
7 accepted
16 restored
27.1% assertiveness — LOW
I’m asking because it was doing pretty well before. Now apparently every change is an opportunity to get restored.
To be fair, I know the bug I’m working on is genuinely difficult. The model is exploring the codebase and considering several plausible causes, but it’s struggling to find the actual issue.
Hey, thanks for the report (and for tracking stats too, that’s a serious approach).
Straight to the point. We didn’t nerf Composer. If you explicitly pick a specific Composer model in the selector, you get that exact model. There’s no silent swap to something cheaper. The only place where routing between models happens is Auto mode (that’s by design). If you want to remove that variable, pin the model in the selector manually.
From your description, this sounds more like task difficulty than a model change. You also said the bug is genuinely hard. Exploratory debugging is exactly where the accept rate drops for any model, since it has to try plausible hypotheses instead of relying on facts. For this kind of work, it helps to ask the agent to add logging first or write a failing test. Then it can reason from runtime data instead of guesses.
If tasks that used to work reliably are now failing just as reliably, send 1 to 2 Request IDs (in the chat top right → Copy Request ID) and your Cursor version, and I’ll pass it to the team to investigate.
Fair enough
And honestly, I think you were right about the task difficulty. I changed my Debug workflow instead of blaming the model.
After ~10 restored PRs on this bug, I added a stricter cycle:
Explore → explain the findings → clarify if needed → edit
And this time it got the actual issue on the first path. 
So here’s the plot twist: maybe Composer wasn’t nerfed…
maybe I was just letting it confidently guess.
Attaching the screenshot of the Debug run — 1 path, bug fixed, no restore button workout this time. 
The restore button can finally take a coffee break.
That’s the right plot twist. This is exactly how it works: with tricky bugs, the value isn’t the model guessing right on the first try, it’s gathering facts first and then editing. Your Explore → explain → clarify → edit loop does exactly that, the model reasons from real findings instead of cycling through guesses.
I’m saving this as a great example of a debug workflow. Let the restore button take a break. If things start acting weird again on tasks that used to work reliably, send a couple of Request IDs and I’ll take a look.