How Many Subagents Can Really Run in Parallel

The two ceilings on how many subagents can run in parallel

You ask Claude Code to handle a job with real breadth: refactor the auth module, check three call sites, update the docs to match. It decides the job splits, and subagents start spinning up one after another. Either you hit a wall with an actual message, Concurrent subagent limit reached, or nothing errors at all and you simply end up with six or eight pieces of finished work landing in the same two minutes, more than you can read closely before the next batch arrives.

Both of those are the same question wearing different clothes: how many subagents can run in parallel before something gives. There are two real answers, and almost everyone only asks about the first. The first is a number Claude Code writes down in its own docs and enforces in code. The second is not written down anywhere, because it is not a setting. It is whatever you can actually review before the next task finishes.

The number Claude Code actually enforces

Start with the documented ceiling, because it is real and worth knowing exactly. Claude Code's default max for concurrent subagents is 20. Ask for a twenty-first subagent to run at the same moment as twenty already in flight, and you get the message Concurrent subagent limit reached. That cap is only on how many run at once. Nothing stops a session from spawning far more than 20 across its full lifetime, one after another, over the course of an afternoon.

Depth is a separate number from concurrency. By default, a subagent can spawn another subagent, which can spawn another, three layers deep, and then it stops. If a workflow genuinely needs a longer chain of delegation, the environment variable CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH raises or lowers that number.

The part most people miss: every subagent's requests count toward the same usage limits as the main conversation. Running twenty subagents at once is not twenty times the headroom. It is the same headroom, spent twenty times faster.

• Default max concurrent subagents: 20, before Concurrent subagent limit reached appears.
• No cap on how many subagents a session spawns in total, only on how many run at once.
• Default nesting depth: 3 layers, changeable with CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH.
• Every subagent draws on the same usage limits as the main conversation, not a separate pool.

Why the real ceiling has no number printed anywhere

Cursor's own documentation describes the Agents Window, where you watch every running agent across your repositories, and it publishes no recommended number of concurrent agents at all. Instead it frames the practical limit as reviewing what comes back, not how many the software can technically run side by side.

Anthropic found the same thing from the inside, building one of the more sophisticated orchestrators anyone has written about in public. Early versions of its multi-agent research system spawned fifty subagents for simple queries that Anthropic says should need just one agent and a handful of tool calls. The system was not broken in the sense of crashing. It simply had no sense of how much a question was worth, so it spent compute the way an eager new hire spends company money: generously, with nothing telling it to stop.

That is the pattern sitting underneath every documented number in the last section. Twenty concurrent subagents is a ceiling on compute and rate limits. It says nothing about whether a human on the other end can read twenty pieces of returning work and tell which ones are actually right.

Finding your own number

Skip trying to find a universal answer, because there is not one. The right count depends on the job, the model doing the work, and how fast you personally read a diff. What exists instead is a method you can run tonight, on whatever you are already working on.

Start at two or three subagents, on a job you understand well enough to judge quickly. Watch what happens when their work comes back. If you are reading each result closely, catching the mistakes, and still waiting on the next one rather than the other way around, add one more next time. If you ever catch yourself skimming instead of reading, or two pieces of work are sitting unread while a third lands, that was one subagent too many. Drop back down.

The number that matters is not the one where the run finishes fastest. It is the one where the work is waiting on you, instead of you waiting on the work. Past that point, more subagents just means a longer queue of things you have not actually checked yet.

• Start at two or three, on a job you can judge quickly.
• Add one when you are keeping up with review, not falling behind it.
• Drop back down the moment you are skimming instead of reading, or work is stacking up unread.
• The right number is where work waits on you, not the other way around.

What other vendors say about the same wall

Claude Code is not the only place this shows up. OpenAI's Codex CLI turns subagent workflows on by default through an agents table in its config file, lets an AGENTS.md file set delegation instructions, and spawns subagents in parallel without asking first. Its own docs recommend subagents for read-heavy work, specifically to avoid what they name context pollution and context rot, and warn plainly that parallel write-heavy work can create conflicts.

That is the same shape as Claude Code's shared usage limits, stated a different way. A vendor that makes parallel delegation easy still has to warn you about what happens once several subagents touch the same thing at once. No vendor's documentation promises that more subagents means more gets done. Read carefully, every one of them is telling you where its part of the job ends and yours begins.

Why a squad is not won by the count of helpers

A Forkbench squad lets a lead agent call in helpers, Claude Code, Codex, Cursor CLI, Aider, or anything else you can start from a command, and nothing stops you from naming several of them for one job. But the count was never the part worth building. The part that makes a higher number workable is being able to see all of them at once, clearly enough to act on what you see.

Each helper shows as a chip on the lead's tab with its state, and every terminal tab carries a live pulse that quickens as its agent works harder, driven by CPU use and output rate, so a glance tells you which ones are actually busy right now. A red needs-you flag, with a count, plus a desktop notification, marks any agent that is blocked waiting on you specifically, so you are not hunting through several tabs for the one that stalled ten minutes ago. The task each helper claimed shows beside its terminal, so the board tells you who has what without you having to ask.

None of that raises how many subagents run at once inside any one vendor's own session. It changes how long it takes you to notice when one of them actually needs you, and that was the number limiting you the whole time.

• A live pulse per tab shows which agents are actually working right now.
• A needs-you flag with a count surfaces every blocked agent, plus a desktop notification.
• The board shows which task each helper claimed, without you asking.
• None of this raises any vendor's own concurrency limit; it shortens how long a blocked agent waits on you.

Accept the work in one place

The last part of the ceiling is acceptance, not spawning. A helper can report a task finished, and that only moves it to awaiting acceptance. It takes a human saying yes to make it done, because no agent can verify its own work and no tool lets an agent raise its own rank. A disagreement between agents becomes a discussion attached to the task, and the task cannot close while that discussion stays open.

That single gate is what makes a bigger number sustainable instead of reckless. If accepting work means clicking through several different tools or scrolling several different terminal histories, two subagents already feels like too many to track. If every finished task lands in the same place, with the same notes, waiting on the same yes or no, five stops feeling any harder to review than two did.