Fork Subagents: When to Share Context vs. Start Fresh

The Problem Forking Solves

Regular subagents start fresh. They receive only the delegation message Claude writes for them, plus project context files. They do not know what you and Claude have discussed. For most tasks, this is exactly right — isolated workers do not need history.

But some tasks cannot work without context. Imagine you have spent twenty turns debugging a subtle concurrency bug with Claude. You've built a shared mental model: the race condition, the affected code paths, the constraints on the fix. Now you want to explore two different fix approaches simultaneously. A fresh subagent would need all that context re-delivered in the delegation message. A fork already has it.

What a Fork Inherits

When you fork a conversation, the fork subagent receives the complete parent state at the moment of forking:

• The full system prompt
• The complete conversation history — every message, every tool call, every result
• The same tools as the parent
• The same model as the parent

The fork then diverges from that point. Whatever the fork does — new tool calls, new messages, new reasoning — stays inside the fork. The parent's conversation remains unchanged.

Creating a Fork

Use the /fork slash command with a directive:

/fork Explore fix approach A: add a mutex around the shared counter. Report whether this fully resolves the race condition without introducing deadlock.

Claude creates a fork subagent with the full conversation history and the directive as its task. You can create multiple forks from the same parent point to explore competing approaches in parallel:

/fork Explore fix approach A: mutex around the shared counter
/fork Explore fix approach B: convert to an atomic operation using CAS

Both forks start from the same point in the conversation and work independently.

The Cost Benefit: Shared Prompt Cache

Large context windows are expensive. Every token in the conversation history is a token that must be processed.

Forks share the parent's prompt cache. When the parent conversation has already been processed and cached, a fork can reuse that cache rather than re-processing it from scratch. For large conversations, this makes forks significantly cheaper than starting a fresh subagent and re-delivering all the context in the delegation message.

The cost benefit of forking versus context-stuffing a fresh subagent depends on conversation size. For short conversations (under ten turns), the difference is minimal. For long investigations, forking is materially cheaper.

Fork Limitations

Forks have two hard constraints to know before designing around them:

• Forks cannot spawn forks. A fork subagent can spawn regular subagents, but it cannot create another fork. Nesting forks is not supported.
• Maximum nesting depth is five levels. A fork counts as one level. Regular subagents spawned from that fork count as additional levels. The chain cannot exceed five levels total from the main conversation.

These constraints exist to prevent runaway nesting hierarchies that would be difficult to monitor and debug.

Fork vs. Fresh: The Decision Rule

Use a fork when:

• The task requires understanding built up over many conversation turns
• You want to explore multiple approaches to a problem from the same starting point
• The conversation is long enough that re-delivering context in a delegation message is impractical

Use a fresh subagent when:

• The task is truly self-contained and needs none of the conversation history
• You want an unbiased perspective that is not anchored to the parent's reasoning
• The task involves a different domain where the conversation history is more noise than signal