Claude Code v2.1.172 shipped June 10 with a changelog that reads like routine maintenance: Bedrock config improvement, marketplace search bar, CPU idle fix. Buried in the middle was the actual news: sub-agents can now recursively spawn their own sub-agents, up to five levels deep.
This sounds incremental. It is not.
What the recursion limit meant before#
Claude Code’s multi-agent architecture has always enforced a hard ceiling. The Agent tool — used inside workflows and skills to spin up sub-agents — enforced a rule: a sub-agent cannot itself invoke the Agent tool. The orchestrator at level 1 spawns agents at level 2. Those agents cannot go further. The architecture was wide but flat.
The practical implication was design overhead. Any task requiring hierarchy had to be explicitly wired by the user or workflow author. If you wanted a planning agent to spawn specialists, the orchestrator — not the planning agent — had to do the dispatching. The planning agent returned a task list; the human-defined orchestrator looped over it and spawned the workers. The planning agent was a participant, not a coordinator.
After v2.1.172: a sub-agent can invoke the Agent tool, spawning its own sub-agents, who can themselves spawn agents, down five levels. The orchestrator at level 1 can delegate to a coordinator at level 2 who builds a work queue and dispatches specialists at level 3, each of which might use parallel tool-calling sub-agents at level 4. The hierarchy emerges from the task, not the scripting.
Five levels: why that number#
The 5-level cap is deliberate. Unbounded recursion in an agent tree creates two problems: runaway token burn and debugging opacity. At five levels you have: orchestrator → coordinator → specialist → tool-use agent → parallel tool-caller — which covers every real decomposition pattern documented in production multi-agent work. A sixth level would be noise.
The hard limit also enables deterministic budgeting. A workflow that spawns N agents at level 2, each spawning M agents at level 3, each spawning P agents at level 4, has N×M×P agent instances at the bottom of the tree. Knowing the ceiling is five means you can bound the worst case before the run starts. Anthropic’s existing concurrency cap (min(16, cpu cores - 2) per workflow, 1,000 total agents per run) still applies; recursion multiplies breadth, it doesn’t override the caps.
Patterns this unlocks#
Hierarchical decomposition without pre-enumeration: An orchestrator dispatches a “feature planner” agent with a high-level description and permission to delegate. The planner decomposes the feature into sub-tasks and spawns specialist agents for each — one per file change, one for tests, one for documentation — without the orchestrator needing to enumerate those sub-tasks up front. The planner adapts the work tree to what it discovers in the codebase.
Self-delegating reviewers: A code-review agent, rather than producing a shallow comment on a cryptography implementation, spawns a security-specialist sub-agent for that section. The depth of review matches the finding. Previously this required the user to design a two-pass review workflow; now the reviewer can decide at runtime when to go deeper.
Adaptive research trees: A research agent investigating a codebase delegates sub-agents per subsystem. When those agents discover inter-system dependencies, they spawn further agents to trace them. The exploration tree unfolds organically without a manual discovery phase. The prior pattern — fixed-width fan-out, then synthesize — is replaced by a tree that shapes itself to the problem.
Delegating test writers: A test-generation agent, encountering a complex integration scenario, spawns a sub-agent to investigate the external service contract before writing the test. The sub-agent returns a spec; the test-writer uses it. Two levels of delegation, zero manual scaffolding.
All of these patterns existed before v2.1.172 — but only if the human explicitly designed the full tree in workflow script code. The change is that the agents themselves can now build the tree.
The rest of v2.1.172#
Bedrock auto-configuration: AWS region is now read from ~/.aws/config automatically. Teams already managing AWS config via standard tooling (aws configure, the config file, AWS_PROFILE) no longer need a separate AWS_REGION environment variable in their Claude Code setup. Reduces friction for Bedrock deployments managed through standard IAM/config patterns.
OTEL model attribute: A model attribute is now added to OpenTelemetry metrics. If you route Claude Code telemetry to Datadog, Grafana, or any OTEL collector, you can break down costs, latencies, and token usage by model. Useful now that production workflows may run Haiku, Sonnet, Opus, and Fable 5 in different layers of the same workflow — each with very different cost profiles.
1M context session hang fix: Long-context sessions using the full 1M token window would sometimes enter a permanent stuck state. This is now resolved. Reliable 1M context was the promise delivered by Fable 5 and Opus 4.8; the hang was a quiet reliability regression that blocked real use of the feature on long-running sessions.
Plugin marketplace search: A search bar is added to the marketplace UI. With the plugin ecosystem past several hundred entries, discovery had become a function of already knowing what you were looking for. A search interface removes that prerequisite.
Idle CPU reduction: Background CPU usage during waiting states is measurably reduced. Relevant for persistent background sessions or multi-session setups where idle Claude Code processes were consuming non-trivial CPU.
VS Code PowerShell rendering: A rendering bug in the VS Code extension on PowerShell terminal emulation is fixed.
v2.1.173 (June 11): Fable 5 name normalization#
The June 11 patch addressed one practical issue with yesterday’s Fable 5 launch. Some integrations — including some Claude Code tooling and third-party plugins — were passing claude-fable-5[1m] as the model ID, including the [1m] suffix that indicates the 1M context window. Fable 5 always has a 1M context window; the suffix is redundant. Passing it literally was causing “invalid model” errors across tools that integrated quickly after the June 9 announcement.
v2.1.173 auto-strips the [1m] suffix on any claude-fable-5 variant, normalizing it to claude-fable-5. Also fixed: a spurious “sandbox dependencies missing” warning that appeared on Windows in some configurations. The warning was harmless but confusing.
What this means for multi-agent architecture#
The conventional advice for Claude Code multi-agent design has been: design your hierarchy explicitly, because the agents themselves cannot build one. v2.1.172 invalidates that advice.
The new guidance: give your top-level agent a clear goal, the Agent tool, and permission to delegate — and let it decide when to go wider (more parallel agents at the same level) versus deeper (a sub-coordinator managing a subtree). The explicit pre-design is still available for deterministic workflows that need it. But it’s no longer the only option.
This pairs directly with Dynamic Workflows (Opus 4.8), which enabled fan-out across hundreds of parallel subagents. Dynamic Workflows gave Claude Code horizontal scale; recursive sub-agents give it vertical depth. The two features together describe something closer to genuine organizational AI — a system that can both parallelize work and hierarchically coordinate it — than anything Claude Code shipped before last week.
Sources: Claude Code GitHub Releases, Releasebot Claude Code Updates