Subagents in Claude Code have a failure mode nobody warns you about: they are confidently wrong about your own session. Not because the model is weak — because of what the subagent is allowed to see. A normal subagent does not inherit your conversation; it inherits a compressed briefing of it, and compression is lossy by definition. For code work, where the load-bearing detail is always specific, that loss is not a rounding error. It is the whole risk.
I learned this at 1:47 AM, roughly 180k tokens into a long session wiring a payment flow for a client SaaS. I spawned a subagent to review a controller and confirm my validation actually enforced what I believed. It came back confident: the guard prevents the race condition, all good. Except the guard it needed to evaluate was not in the controller — it was in a custom middleware, and the subagent had never seen it, because the compression step had flattened that middleware into something like "project uses standard Laravel middleware stack." The nuance that mattered was exactly the nuance the summary discarded. I debugged the wrong problem for four hours on the strength of that answer.
Forked subagents exist to close that gap, and after rebuilding my delegation habits around them, my position is: forks and normal subagents are both essential — for opposite jobs — and the skill is knowing which job you are holding.
The compression tax, stated precisely
Here is the mechanism. When Claude Code spawns a standard subagent, the child starts effectively fresh: it gets its task prompt plus whatever context the parent chooses to summarize into the brief. The summary captures the shape of your session and loses the specifics — and the specifics are where code lives. Which middleware. Which flag. The decision you reversed an hour ago. A one-page executive summary of a three-hour meeting, handed to a colleague who must now weigh in on a detail from minute 47.
This is not a niche complaint. The Claude Code issue tracker carries long-running requests for exactly this control — a fork_context option on the Task tool for full conversation inheritance and subagent inheritance of the parent conversation — because developers kept discovering that default context passing is either too little or too much depending on the task.
The underlying tension is real, not a design mistake. Long sessions degrade: past a couple hundred thousand tokens, decision quality drifts, which is why context hygiene matters at all (I keep separate notes on managing large context windows and token limits and context hygiene). The main session wants to stay lean; the subagent starved of context makes bad calls; summarization is the compromise between them. And compromises always bill somebody. In my middleware incident, the bill was four hours.
What a fork actually is
A forked subagent inherits the parent conversation — the full history, not a summary — and runs as its own session from that point. Three properties follow, and each one matters:
Full recall. The fork knows about the custom middleware because it was there when we discussed the custom middleware. No briefing step, no lossy hop. Questions that hinge on session nuance get answered from the record, not from a reconstruction.
Isolation on the way back. The fork's own tool calls and intermediate churn stay in the fork. Only its result returns, so your main window stays clean while the child does its heavy reading.
Cache-priced inheritance. Because the inherited history is shared with the parent, the fork rides the prompt cache rather than paying full freight on a couple hundred thousand tokens of re-read. Full context inheritance would be economically silly otherwise; with caching, it is routine.
One inheritance nobody advertises: forks also inherit your session's rot. Every abandoned hypothesis, contradictory instruction, and noisy tool dump in your history arrives in the fork unfiltered. A fork of a messy session is a messy agent. Forks reward the context hygiene you were hopefully practicing anyway.
Where forks earn their keep
From real use, the four cases where I now fork by default:
Mid-session verification. The middleware case, done right. "Given everything we have discussed, is this validation actually airtight?" is a question whose value is the accumulated context. Forking it costs little and answers from the full record.
Consolidation and recap. Late in a long session: fork a child to write the handoff document — decisions made, paths rejected, open threads. The fork remembers the whole journey; the parent stays focused on finishing.
Tangent containment. A rabbit hole worth exploring but not worth polluting the main line: fork it. If the tangent pays off, the result comes back; if not, the mess dies with the fork. This one quietly changed how willing I am to investigate hunches at all.
Parallel variations on shared context. Three design directions for the same component, each needing the full background: three forks beat three briefings, and beat serializing the exploration in the main session.
Where forks are the wrong move
Just as load-bearing. Do not fork when:
You want a fresh perspective. A fork inherits your assumptions along with your facts. For adversarial review — "tell me what I am missing" — a clean-context agent with a deliberate brief is more valuable precisely because it was not marinating in your reasoning. Sunk-cost bias transfers with the history.
The task is self-contained. Here is the counterexample from my own infrastructure: the SEO remediation pipeline running on this very blog uses dozens of worker agents, and none of them are forks. Each rewrite worker gets a fresh context and an explicit written brief — assignment, evidence, constraints — because the task was designed to be self-contained. When the contract is complete, inheritance is pure waste: you would pay (even cache-discounted) for history the worker does not need and, worse, expose it to rot it should never see.
You are parallelizing independent work. Ten workers on ten separate tasks want ten clean contexts. Forking belongs to shared-context problems only.
That gives you the decision rule I wish someone had handed me: fork when the task depends on conversation nuance; brief-and-spawn when the task can be fully specified in writing. And notice the trap hiding in that rule — the middleware failure happened because I used a summary-briefed agent for a nuance-dependent task. The summary looked like a full specification. If writing the complete brief would require reciting half your session, that is the tell: fork instead.
How this fits your delegation stack
Forks slot into a spectrum rather than replacing it: inline work in the main session, forked children for nuance-dependent side work, fresh subagents for specified independent tasks, and coordinated teams when workers must negotiate with each other — that last tier is its own discipline, covered in my agent teams guide. Skills interact with the same machinery: heavyweight skills increasingly run in forked contexts so their bulk data never touches your session, a pattern I detail in the advanced agent skills playbook.
The test I would run tonight if I were you: next long session, past the point where it has real history, spawn one normal subagent and one fork on the same nuance-dependent question. Compare which one knows what actually happened in your session. The difference is not subtle, and after you see it once, you will route delegation differently without thinking about it.
The compression tax was costing me hours before I could name it. Now it costs a decision.
Long-session agent workflows — delegation structure, context budgets, verification loops — are something I build for client teams as paid engagements; if your sessions degrade before your work is done, my services page covers how that engagement works.
