Claude Code Fork Agents: Full-Context Subagents That Do Real Work

Claude Code fork agents are subagents that start with your full session context and are allowed to act on it. That fixes the two problems that made delegation a compromise until now: the old subagents knew nothing about your session, and doing the work in the main window filled it up until the session got dumber. The result is one lean main agent that can build a whole app while its forks burn the tokens.

We run one internal call a month on movements in AI tooling: often enough to catch real changes, rare enough to avoid shiny object syndrome. The subagent rebuild, fork agents and teammates, was the last topic that cleared that bar.

What is a fork agent?

The old subagents were contextless. Each one got a prompt and a task, knew nothing about the conversation that produced it, and handed back a deliverable. That made them useful only for work you could specify completely in one message.

A fork agent inherits everything: the whole session up to the moment you spawn it. A read-only version of this existed before; the change is that forks can now act. You invoke one with /fork plus whatever you want done.

Two more pieces arrived with the rebuild. Teammates are persistent subagents. And subagents can now spawn subagents of their own, up to five levels deep, which can get crazy if you don't watch out, but it means the delegator keeps delegating while holding the main context.

The reason to care is context rot. A Claude session gets dumber as the window fills: the model pays attention to the beginning, loses the middle, and every added token makes the session more expensive. Kept lean, a single window works really well up to around 200k tokens. Kept polluted, it degrades long before that.

The nitpick pattern: fork every small fix

The situation comes up constantly. Claude finishes a task and reports: done, and here are four small things I would still implement. Nits.

The old move was "fix them all," which pulls four rounds of back and forth into the main window. The new move: fork nitpick one, fork nitpick two, fork nitpick three. Each fix happens in its own context, the main task continues in parallel, and the main window never carries any of it. That gets you much further inside one session, because the window only ever holds the main line of work.

The pitfall: a fork and the main agent doing the same work

Sometimes you fork a task and the main agent does not register that you did. It starts on the same work, and now the fork and the main agent are editing the same thing and conflicting.

The fix is blunt: tell the main agent explicitly that you dispatched these subagents and it must not touch their work. Hopefully Anthropic fixes this, but even with the manual instruction it beats a pile of merge conflicts.

Run Explore agents on Opus, not Haiku

This one is not specific to forks, but it belongs in the same conversation. Explore agents, the read-only ones that scout a codebase and report back, often default to a small model. Use Opus if you can, or at least Sonnet.

The reason is what an Explore agent returns: a summary of findings that the main agent then relies on. If that summary is off, the main agent makes decisions from a map that might not be 100% accurate, and the cost surfaces far downstream of the cheap model that saved you a few tokens.

The scratchpad file

Keeping the main context lean does not remove the need to track state; it relocates it. Create a file and let it become the session's scratchpad. The main agent and its forks write progress there instead of into the conversation, so the coordination survives without costing window space.

Why fork agents make agent loops work

The payoff of all of this: better decisions, cheaper autonomous runs, less babysitting. Each fork gets one small task, and a subagent with one small task comes back correct more often than a main agent juggling four, while piling up the context that makes everything after it worse.

That is also the shape of a working agent loop. The loop runs in the main context, slices the feature into small tasks, and delegates each slice to a fork. The inputs and the guardrails decide how long it runs unattended. Smaller tasks are better: less goes wrong inside each one.

For how we split the surrounding pipeline across two tools, see the Claude Code vs Codex split we ship production code with.