Claude Code's Forked Sub-Agents: What They Are and When to Use Them

Claude Code now supports forked sub-agents, a new way to spawn parallel work that carries the full conversation history of the parent session. This changes how you split tasks across multiple agents, and it has real implications for both context quality and token cost.

How Normal Sub-Agents Work

When you deploy a standard sub-agent in Claude Code, it starts with a completely fresh context. The parent session generates a summary of the conversation so far and passes that summary along with task instructions to the new agent. The sub-agent has no direct access to the full history. It only sees the summary and whatever instructions you give it.

This means the sub-agent needs to reload system prompts, re-read tool definitions, and reconstruct enough context to do its job. That reload costs tokens and can lose nuance from earlier in the conversation.

What Forked Sub-Agents Change

A forked sub-agent gets deployed with the entire conversation history of the session that created it, plus the task instructions. There is no summary step. The forked agent sees everything the parent session has seen, including all prior tool calls, file reads, and decisions.

This has a practical side effect on cost. Because the forked agent inherits the already-loaded system prompts and tool definitions from the parent session, it does not need to re-read those on startup. Depending on the size of your system prompts and tool configuration, this can actually save tokens compared to deploying a normal sub-agent.

How to Enable Forked Sub-Agents

To use the feature, add the forked agent configuration to your global settings.json file. Once configured, you can invoke it with the /fork command during a session. The video shows this as a straightforward settings change, not a complex integration.

The Best Use Case: Parallel Evaluation With Shared Context

The strongest use case for forked sub-agents is when you need to evaluate the same problem from multiple angles, and each angle requires the full context of your prior conversation to produce an accurate result.

Examples include:

Generating multiple UI plans for the same feature, where each plan needs to reference the same design constraints and prior decisions
Reviewing a pull request from different perspectives (security, performance, maintainability, user experience) with each reviewer agent having full awareness of the codebase discussion
Comparing implementation approaches (A, B, C, D) where each approach needs the same background on requirements and trade-offs

The key pattern is: one conversation builds up shared context, then you fork into parallel tracks that each need that context to do their job well.

Key Takeaways

Forked sub-agents inherit the full conversation history of the parent session, not just a summary
Normal sub-agents start fresh with only a summary and instructions, which means re-loading system prompts and tools
Forked agents can save tokens because they skip the re-read of system prompts and tool definitions already loaded in the parent context
Enable via settings.json and invoke with /fork
Best for parallel evaluation tasks where multiple agents need identical background context to produce useful output