Fork or subagent: full context or clean slate

You are ninety minutes into a session. Three theories about the bug were raised and two were killed; you agreed on a fix shape; there is a convention you talked Claude out of applying. Now you want tests drafted for the change so far, without stopping the implementation to write them.

Lesson 8.2 said what happens if you delegate that: the subagent sees none of it. So you either write a brief that re-explains ninety minutes, or you do the work yourself. There is a third option, and it is a different kind of subagent.

A fork is a subagent that already knows everything

A fork is a subagent that inherits the entire conversation so far instead of starting fresh. This drops the input isolation that subagents otherwise provide. — Subagents

That is a trade stated in one sentence. You gain the history — "a fork sees the same system prompt, tools, model, and message history as the main session, so you can hand it a side task without re-explaining the situation". You lose the property Lesson 8.2 spent its length on: your slate is now its slate. What you do not lose is the half of the boundary that protects your window:

The fork's own tool calls still stay out of your conversation and only its final result comes back, so your main context window stays clean. — Subagents

Isolation has two directions and a fork keeps exactly one. Input isolation — what the delegate cannot see — is gone. Output isolation — what its work does to your window — is intact. Lesson 8.1's case for delegating rested entirely on the second, which is why a fork is still a context move and not a convenience.

What a fork keeps and what it drops

The documentation compares them line by line (Subagents):

Two rows deserve more than a glance.

Tools. A non-fork subagent's pool is the main conversation's narrowed by two filters — one that strips a short list from every subagent, one that cuts the built-in set further for background runs, which are the default. "Forks skip both filters and receive the main conversation's exact tool pool" (Subagents). A fork can do what you can do, which is convenient and is also why a fork is the wrong shape for anything you wanted tool-scoped: it has no definition file, so there is no tools field narrowing its pool. Your permission rules still apply — a fork's prompts surface in your terminal — but the tool list it starts from is yours.

Model. A fork runs your model. Lesson 8.2 established that a subagent's window is sized by its own model; a fork's model is the parent's, so the window is the same size — and it starts with your entire conversation already in it. A fork spawned late in a long session is not a fresh window, it is a copy of a tired one.

Same system prompt has one more consequence: your output style does shape a fork. The docs scope their whole list of main-conversation state that gets left behind — output style, auto memory, context-window sizing — to the non-fork subagent, and state the carve-out explicitly on the first entry: your output style "doesn't shape its responses, except in a fork". And a fork cannot spawn further forks (Subagents).

Why a fork is the cheaper option

A fork obviously carries more tokens than a fresh subagent, and is nonetheless described as cheaper.

Because a fork's system prompt and tool definitions are identical to the parent, its first request reuses the parent's prompt cache. This makes forking cheaper than spawning a fresh subagent for tasks that need the same context. — Subagents

The caching page states the contrast from the other side: a plain subagent's first request "doesn't read the parent's cache, because the two prefixes differ", while a fork "inherits the parent's system prompt, tools, and conversation history exactly, so its first request reads the parent's cache" (Prompt caching).

There is a second cost a fork does not pay, and it is the one you feel:

Latency matters. A subagent that isn't a fork starts fresh and may need time to gather context. — Subagents

A fresh subagent spends its opening turns rediscovering what you already know. A fork skips that phase because it never lost it.

Where the copy runs, and where the answer lands

/subtask, /fork and /branch all make a copy of your conversation. They differ in where the copy runs and where its result lands. One of the names moved, though, so start there.

The table names each command as it behaves with agent view on; read the first column as a behaviour label, not as something to type blind.

The command reference says it in one line, from the /branch entry:

To run a copy as a separate background session instead of switching into it, use /fork; to hand a side task to a subagent that reports back into this conversation, use /subtask. — Commands

And agent view draws the same line between the two ways work leaves the session you are in: "/background sends the current conversation there and frees your terminal, and /fork sends a copy while you keep working where you are" (Agent view).

Wherever the two commands are distinct, the trap is reaching for /fork when you meant /subtask. It runs. It reports a session ID and a row in agent view. Nothing is broken — and the answer you were waiting for is being written somewhere you are not looking, because "after the fork, the two conversations are independent: nothing the copy does enters the original conversation on its own" (Agent view). You now have a second session to attach to, prompt and manage, which is not what you asked for. On v2.1.161 through v2.1.211 that mistake was not available: there was one command, and it gave you the forked subagent.

Choosing between them

Every row is one question asked twice: does the delegate need what you know, and do you need to be there? Lesson 3.5 met /branch from the other end, as the move for trying a different direction without losing the one you have. What is new here is that a branch takes you with it and the two fork-shaped options do not.

When inheriting the conversation is wrong

There is one job where a fork's advantage is precisely the defect. "A fresh context improves code review since Claude won't be biased toward code it just wrote", because a reviewer in one:

sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms. — Best practices

Lesson 5.5 named what buys independence: not the reviewer's mood, but what you withhold from it. A fork withholds nothing. It has the reasoning, the argument you won, the theory you both settled on — which is precisely the bias the docs say a fresh context removes, restored in full. Expect an hour-old conviction handed back to you faster. Lesson 8.5 builds the reviewer properly. The rule is short: for "help me finish this", inherit; for "tell me if this is right", do not.

Checkpoint

1. A fork and a plain subagent both do fifty file reads. Which of those reads land in your main conversation, and why is the answer the same for both?

   ›Show answerAnswer

   None of them, in either case. Only the delegate's final result comes back: a fork's own tool calls stay out of your conversation exactly as a plain subagent's do, so your main context window stays clean.

   The answer is the same because a fork drops only one of the two directions of isolation. Input isolation — what the delegate cannot see — is gone, since it inherits the entire conversation. Output isolation — what its work does to your window — is intact, and that is the half Lesson 8.1's case for delegating rested on. What you pay for in both cases is the size of the report, never the fifty reads.

2. You have argued Claude out of a caching approach over the last hour and settled on a simpler one. You now want a second read of the diff. Fork, plain subagent, or branch — and what specifically goes wrong with each of the two you rejected?

   ›Show answerAnswer

   A plain subagent. You want the reader that sees only the diff and the criteria you give it, not the reasoning that produced the change, and a fresh context is the thing that buys that.

   A fork withholds nothing: it carries the caching argument you won and the approach you settled on, which is precisely the bias a fresh context removes, restored in full — expect an hour-old conviction handed back to you faster. /branch fails differently. It copies the conversation and takes you into the copy, so you are the one doing the review, in a window that still holds the whole history, and the result lands wherever you now are rather than back in the session you left. The rule is short: for "help me finish this", inherit; for "tell me if this is right", do not.

3. You type /fork draft the migration notes and go back to work. Nothing comes back. Name two different things that could have happened, and say what you would check to tell them apart.

   ›Show answerAnswer

   Either you got a session copy, or you got a forked subagent that has not finished. With agent view on, from v2.1.212, /fork makes a copy of the session as a new background session: it runs, reports a session ID and a row in agent view, and nothing returns on its own, because after the fork the two conversations are independent. The notes are being written somewhere you are not looking, and you now have a second session to attach to, prompt and manage. What you wanted was /subtask.

   Where agent view is off — and on v2.1.161 through v2.1.211, where /subtask did not exist — /fork keeps the forked-subagent behaviour, which does report back into this conversation, so silence means it is still working rather than that the answer went elsewhere. Tell the two apart by checking which behaviour the session you are actually in has: /help for the commands it offers, and agent view for a new session row and ID.