Claude Code agents now spawn agents — set the caps first

Your coding agent stopped being one process. In its August 14 release, Claude Code turned subagent forking on by default, moved /fork to background sessions, and added a way for one session to message another by name. The same release quietly shipped two spend limits. Those limits are the interesting part, and the default values are almost certainly wrong for your team.

What actually happened

Per the Claude Code changelog, the release changes the topology of a coding session in four ways:

• Forking is the default. A subagent_type: "fork" subagent inherits the full conversation and the prompt cache instead of starting cold. Cheaper per spawn, which means more spawns.
• /fork went background. It now copies your conversation into a separate background session with its own row in claude agents while you keep typing. The old in-session behavior moved to /subtask.
• Sessions talk to each other. Type @ in the prompt to mention another Claude session by name; the agent reaches it through SendMessage.
• Two caps landed. A session-wide ceiling of 200 WebSearch calls, tunable with CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION, and a per-session ceiling of 200 subagent spawns, tunable with CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION.

Read those two numbers as what they are: a vendor shipping circuit breakers because runaway loops happen. A search loop that never converges and a spawn loop that fans out are the two failure modes that turn a debugging session into a billing event.

Why it matters for your business

We run agents on client work, so here is the operator read rather than the changelog read.

Cheaper spawns change behavior, not just cost. When a fork inherits the cache, the marginal cost of "just try it in parallel" drops. That is good for throughput and bad for anyone whose budget assumed a linear session. Model your spend per task, not per seat — five parallel forks on one ticket is now an ordinary shape.

200 is a ceiling, not a budget. A session that legitimately needs 200 subagents is rare. A session that needs 200 because a loop is eating itself is not. Set both variables to something you would be willing to pay for twice, put them in your shell profile or CI environment, and treat hitting the cap as an incident signal rather than an inconvenience.

Cross-session messaging is a new surface. Once one session can send a message into another, "what is this agent allowed to trigger" becomes a real question — the same question we ask about any service that can call another service. Decide deliberately which sessions are addressable, especially on machines with credentials for production.

Background work needs a review step. A fork that keeps running while you move on produces output nobody read. Add the same discipline you would apply to a junior contractor: a place the work lands, and a person who checks it before it merges.

None of this argues against multi-agent work. We use it. It argues for treating your agent fleet like infrastructure — with limits, ownership, and a log — instead of like a chat window that occasionally surprises you.

Sources: Claude Code changelog, Anthropic release notes.