Composer 2.5 degraded for a week – subagents spawning multiple times

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

For about a week now, Composer 2.5 seems to be degraded.

We are consistently seeing subagents being created multiple times for the same task. Instead of spawning a single subagent, Composer often creates several duplicate instances.

This makes multi-agent workflows quite unreliable and also wastes a lot of resources.

Has anyone else noticed the same behavior over the last week?

Steps to Reproduce

Setup composer 2.5 as subagent expert

Operating System

Windows 10/11

Version Information

3.20.21 (system setup)

For AI issues: which model did you use?

Composer 2.5

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report. It doesn’t look like this is Composer 2.5 itself, the model hasn’t degraded.

Recently, some users on 3.20.21 and newer got a change in how local subagents are launched. On that path, a custom subagent sometimes launches another instance of its own type instead of exiting. That ends up looking like duplicate subagents for the same task. We know about this and we’re tracking it. I can’t share an exact ETA yet, but I’ll post an update in the thread when I have one.

A couple things that can help right now:

  1. In every subagent definition file under .cursor/agents/, add a line in the instructions like “Do not launch any subagents”. Subagents that are explicitly told this stop re-spawning.
  2. If a run starts multiplying, click Stop All in the subagent tray instead of closing the chat. Closing the chat doesn’t stop subagents that are already running.

If it still happens after step 1, please send the Request ID from one of the affected runs (three dots in the top right of the chat > Copy Request ID) and a screenshot of the subagent tray showing the duplicates. Note that with Privacy Mode enabled, the Request ID may include limited data, but the ID itself will still help. Let me know how it goes.

okay, request-id is 527202c7-4e73-43fc-b13e-67cdfd70f5b3 and attached a screenshot

it spwans the same subagents about 20-30 times. It does it with every subagents, it is like crazy! I have a linter expert and jobs for 5 files, then every file gets linited 20x times. This kills my quota right now. Fur further information I would need to upgrade my subscription… If this is NOT composer 2.5 related it would even come much more expensive! This issue starts roughly a week before, my setup runs months without any problems before.

Just stopped my latest work. It spawns more than roughly ~40-50 subagents for a single task. I cannot use it anymore.

Might it be possible every “new prompt” or subagent torunaround gets an new subagent? - I think this is that happens here. Start with one subagent and every turn gets a “new” one.

Hey, thanks for the request ID and screenshot. That’s exactly what we need.

Confirmed: this is the same issue I mentioned above, and your analysis in the last post is correct. Instead of finishing and returning a result, each subagent launches a new copy of itself for the next step, and one task turns into a chain of 20 to 50 identical subagents. This is not Composer 2.5 degrading and it’s not anything in your setup. It’s behavior in the new local subagent launch path that recently rolled out to some users on 3.20.21 and newer. We’re tracking it. I can’t share an exact ETA yet, but I’ll reply in the thread when there’s an update.

What helps right now:

  1. In every subagent file under .cursor/agents/, add an instruction line like “Do not launch any subagents”. Subagents that are explicitly told this stop re-spawning.
  2. If a run starts multiplying, hit Stop All in the subagent tray instead of closing the chat. Closing the chat doesn’t stop subagents that are already running.

On the screenshot specifically: one of the Expert Git agents shows Blocked: Ask mode cannot run git. If your Expert Git front matter has readonly: true, that’s the reason. On Windows, a read-only subagent can’t run shell commands like git log or git blame, so it reports itself as blocked and the main agent retries the task. Remove that line from the Expert Git file, or have the main agent run those commands, and the repeated retries should stop.

Can you paste the front matter part between --- from your expert-git .md? That’ll help us reproduce your config.

Sorry about the wasted usage. Let me know if it helped after a full Cursor restart, fully quit and reopen, not reload. I’m here.