Short version: Claude Code 2.1.212 added two hard, session-scoped ceilings you didn't have before: a cap on how many subagents one session can spawn and a cap on how many web searches it can run. Both default to 200. You can raise either ceiling to any positive integer, but you cannot turn the subagent cap off — which is the clearest signal of intent Anthropic could send: an agent with no spawn ceiling is a bug, not a feature. The catch a lot of the coverage misses is that the spawn cap counts subagents by number, not by cost — so it stops a runaway loop, but it is not your spend budget. Here's what each knob actually governs, and the three you should set on purpose.

If you're choosing between coding agents on exactly this axis, we compared the field in Claude Code vs Cursor vs Cline: who actually stops a runaway subagent. This piece is what you configure after you've picked Claude Code and want the guardrails set before your next parallel-agent run.

The one mental model: three failures, three knobs#

A "runaway agent" is not one problem. It is three, and Claude Code now has a distinct mechanism for each. Conflating them is why people set the wrong number and still get surprised by a bill.

None of those three is a spend limit. Spend is governed separately, by which model each subagent runs. Keep these four straight and the rest of this is configuration.

1. The subagent spawn cap — a loop-breaker, not a budget#

The default: Claude can spawn at most 200 subagents per session. Raise it with the env var:

# Raise the ceiling for a heavy, legitimately-parallel job:
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=500

There is no upper bound, and there is no off switch — the lowest you're allowed is "some finite number." When the session hits the ceiling, the Agent tool fails with Subagent spawn limit reached, and the error tells Claude to complete the remaining work directly with its own tools rather than delegating.

What counts toward the 200 is broader than most people assume:

What does not count: a separate background session you create with /fork (it runs with its own budget), and agents a workflow script spawns with agent() (workflows enforce their own per-run limit).

The spawn cap counts subagents by number, not by cost — so 200 Haiku workers can be cheaper than five Opus ones. It breaks a runaway loop; it does not cap your bill.

That last point is the whole reason not to treat 200 as a spending guarantee. If you want the cap to reset between distinct jobs in a long session, run /clear — it resets the count and starts fresh. The one gotcha: if work that can still spawn subagents survives the clear (a running workflow, say), the count carries over instead of resetting.

2. The depth limit — the recursion backstop you can't tune#

Separate from the spawn cap is the depth limit: how many subagent levels can sit below your main conversation. It is fixed at 5 and not configurable. A subagent at depth five simply doesn't receive the Agent tool, so it cannot spawn a sixth level. A /subtask fork can spawn other subagent types, and those count toward the depth limit; a fork still can't spawn another fork.

You don't set this — you design around it. If a task genuinely needs more than five levels of delegation, that's a signal to flatten your agent graph, not a number to raise.

3. The web-search cap — stopping the doom-scroll#

CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION is a session-wide limit on WebSearch calls, default 200, added specifically to stop an agent that keeps searching without converging on an answer.

# A research-heavy session that legitimately needs more headroom:
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=400

For most work the default is generous; if you're hitting it in normal use, the honest read is usually that the task is underspecified, not that the cap is too low.

4. The knob that actually controls spend: model routing#

Because the spawn cap counts by number, the lever that moves your bill is which model each subagent runs. Route exploration and mechanical subagents to a cheaper model and reserve the expensive one for the main thread:

---
name: explore
description: Read-only search agent for broad fan-out
model: haiku
---
Search the codebase and return only the conclusion, not the file dumps.

Claude Code's built-in Explore agent already inherits the main conversation's model (capped at Opus on the Claude API) rather than always running expensive — but for your own subagents, setting model: haiku on the fan-out workers is the single highest-leverage cost move you can make. A hundred cheap workers finishing a search sweep is the point of subagents; a hundred Opus workers doing it is the bill you didn't mean to sign.

Bonus: keep long calls from stalling the session#

One more 2.1.212 addition worth knowing: set CLAUDE_AUTO_BACKGROUND_TASKS=1 to force-enable automatic backgrounding of long-running agent tasks — and, in non-interactive mode, of long MCP tool calls — so a slow tool doesn't block the whole session. Background subagents also carry a stall timeout, CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS (default 600000, i.e. 10 minutes), that aborts a background subagent if no streaming progress arrives inside the window; the timer resets on each progress event.

The founder takeaway#

Set three things on purpose before your next big run: route your fan-out subagents to Haiku (this is your spend control), leave the spawn and web-search caps at 200 unless a specific job needs headroom (they're backstops, not budgets), and /clear between distinct tasks to reset the spawn budget. The depth limit takes care of itself at five. And remember the one asymmetry that catches people: the spawn cap counts heads, not dollars — so a "safe" 200 subagents is only safe if you also told them which model to run.

For the wider picture of what else Claude Code shipped this month, see the Founder's Wire, week of July 20, which covers the worktree data-safety fix in 2.1.210 you'll also want before running parallel agents.