If I choose any model (other than Auto) - Cursor doesn’t work and sometimes the UI Jumps.. I know why it doesn’t work (maybe i have hit some limit) - however cursor is not handling it well on the IDE.
Hey, this is probably the most detailed report I’ve seen all week. Thanks, it really helps.
Here’s how it breaks down:
Misleading Switched to composer-2.5 when you’re already on Composer 2.5
This is a known wording bug in that message. We’re tracking it, but I can’t share an ETA yet.
Why Composer 2.5 itself fails in about 1s
You’ve used up your included usage on the Pro plan. When you manually pick a model, the request hits the limit, and after the Composer 2 retry path was removed on May 28, the fallback path is currently behaving incorrectly. That’s also a known issue on our side, with no timeline yet. Auto still works because it routes to available capacity.
Spawn storm UI jumps, agents keep multiplying
From your logs, this looks like a separate issue. Every failed send on a limited model seems to create a new agent instead of reusing the current one. I’ll file this for investigation. To confirm on our side, it’d really help if you can share the zip logs you mentioned at ~/Library/Application Support/Cursor/logs/20260601T181450/, plus a Request ID from one of the failed Composer 2.5 requests. If Privacy Mode is off, you can copy it from the chat menu in the top right > Copy Request ID.
Workaround for now:
Stay on Auto, it avoids the broken fallback path
Don’t spam Submit and don’t switch models quickly back to back, each attempt can spawn a new agent
If you want to run specific models right now, either wait for your usage to reset or enable usage-based pricing on-demand spending in the dashboard. The reset time is shown in Settings > Usage
Let me know once you’ve shared the logs. If the spawn storm is confirmed, I’ll start a separate thread for it so we don’t mix everything together.
Hi Dean, No worries! thanks for the clear breakdown. That matches what I was seeing.
Logs attached:cursor-logs-20260601T181450.zip (full session from ~/Library/Application Support/Cursor/logs/20260601T181450/).
Request ID: I don’t have a Request ID copied from the chat menu for the failed Composer 2.5 attempts or jumps… (I didn’t grab it at the time). i tried to reproduce it again but jump didn’t happen this time in a new thread. it happened in the “monpage workspace” see below.
@saad I went through the full logs. Thanks for the correlation ID, it made this much faster.
Quick recap in 3 points:
Model selection on the client side looks fine. In the logs, the client consistently sends composer-2.5 (you selected it manually and it was sent correctly). So the misleading Switched to composer-2.5 message and the failed fallback are from server-side handling of the usage limit, and that part doesn’t show up in the client log. These are the same two known bugs I mentioned in my last reply. No ETA yet.
The Composer 2.5 failures around 1s are confirmed (3 attempts at 01:45 to 01:46, then it rolls back to default). There are no client errors, the rejection comes from the backend. Also, the [error] lines about OTLPExporterError / Trace spans collection is not enabled in that window are unrelated telemetry noise. You can ignore them.
Spawn storm: confirmed, this is a real client bug. The logs show two bursts (01:39:55 to 01:40:06 and around 00:58:35). Agents aren’t being spawned by you, they’re spawned by the tab handling logic. When the active tab is a terminal, the handler keeps creating a fresh agent instead of reusing the current one. This is on our side, I’ve reported it internally. I can’t share an ETA yet, I’ll update you when I have one.
To avoid mixing everything in one thread, let’s split the spawn storm into a separate report. If you can, please create a new post in Bug Reports (Cursor 3.6.31, macOS, Layout: glass) describing the bursts and include the same correlation IDs you already shared: workspaceId=cb63fd33d71ab71e51714be8df07905c, example agent composerId 9c978720-5774-42ec-8af5-5a5a116ebece, burst timestamps, and attach the same zip. Drop the link here after you post it and I’ll pick it up there.
Workaround is the same: stay on Auto (it avoids both the broken fallback and the burst trigger) and don’t switch models quickly back to back. Let me know if you catch it again, especially with a Request ID.