Anthropic has once again tweaked the /fork command in Claude Code. It sounds like a cosmetic change. It isn’t. This is the second time in a few weeks that the same command has taken on a different meaning, and this time it’s resulted in something genuinely useful. /fork now launches a background agent that takes your entire context—the same system prompt, tools, history, model, and prompt cache—and, once finished, returns the result to your session. The original behavior—splitting the conversation into a separate session that you control yourself—has been moved to /branch.
And here’s my first reservation. Do you remember what /fork was called last month? I don’t entirely either, and that’s exactly the problem. The changelog is relentless: first, /fork was renamed to /branch (version 2.1.77), and now /fork has taken on a completely new meaning. Anyone who’s used to the old command will type /fork today and get different behavior than a few weeks ago. When I read questions under the announcement like “and how is this different from /btw?”, I also see a criticism of the speed at which Anthropic churns out features without having time to come up with names. One commenter summed it up perfectly: soon AGI will be needed just to remember what each slash command does this week.
So what’s really new here? Honestly, less than it seems. The inherited subagent already existed before, hidden behind the experimental switch CLAUDE_CODE_FORK_SUBAGENT=1. The difference from a regular subagent is simple: a regular subagent starts only with the prompt you give it, whereas the forked one carries your entire conversation. It’s essentially a clone of the previous prompt. So the announcement mainly takes the old flag and makes it the default behavior. It adds a second, more subtle feature: the “return path.” The community had been asking for this since March: the old /fork could split a conversation, but the conclusions from the winning branch couldn’t be brought back. Now they can be brought back. That’s a real improvement, and I’m all the more pleased that it’s a response to a specific request from people who use the tool daily.
What’s the practical use of this
I’ll draw from real-world experience, not the documentation. /fork is the only one of the three that can do this: it carries your entire accumulated context—that is, the architecture, conventions, types, and the bug you’re currently working on—runs in the background, and returns the result to the main session. This gives me a simple decision rule. When a task needs everything we’ve discovered and discussed in the session, I want to keep working on it, and I want the answer back, I’ll use /fork. When the task is standalone and my history is useless to it, I’ll send a regular subagent—it’s cheaper and cleaner. And when I want to explore a single path on my own and control it manually, I’ll take /branch and set off on foot. A fork sends out a scout and collects reports. A branch is a trip that you lead.
Now, specifically, on a TypeScript web application. Imagine you’ve been in a session for an hour, building a data layer on top of TanStack Query. You’ve established an API client pattern, error handling, naming conventions, and shared types. You’re about to wire up another component when you realize you want tests for the hook you just finished writing. This is where a fork comes in handy. You write /fork write Vitest tests for the useCart hook, stick to the conventions from src/features/auth. The agent inherits exactly the conventions we discussed in the session, runs in the background, you keep building, and in a moment a finished test file drops into your session. No context switching, no re-explaining your style.
The second case is a risky refactor. You’re debating with yourself whether to switch from Redux to Zustand. I don’t want to clutter up the main thread with this, so /fork, try migrating the cart store to Zustand, and return the diff and any type conflicts. The fork will attempt this with full knowledge of your store’s structure and your types, return a verdict and a diff, and you decide. The main session stays clean.
The third case is my favorite: branching out to investigate an unclear error. For example, your build fails due to an unclear type error, and you have three suspects: a misconfigured strict in tsconfig, a type version conflict, or a generic that’s gone haywire somewhere (to name the one that threw me off yesterday). You fork three agents, each chasing one hypothesis, all with the full context of your build setup. You collect three reports and save yourself the trouble of serially testing one thing after another.
And this is exactly where that subtle new feature, prompt cache inheritance, pays off. A forked agent doesn’t pay for “activating” the cache again, so every additional parallel branch is cheaper. Without this, sending the full context three times would be prohibitively expensive, and you’d likely stick obediently to a single linear thread. And it’s precisely the cost that determines whether you’ll actually branch out your thinking. For agent-based development, where the real currency is a coherent working horizon, this is far more important than simply running in the background.
Brainstorming and its catch
In brainstorming, forking is smarter than it seems at first glance. Here’s how it works. In a session, you build a rich framing of the problem—that is, the goals, constraints, and ideas you’ve already rejected. Then you send out several forks, each in a different direction. “Advocate for a boring, tried-and-true architecture.” “Advocate for an aggressive, novel variant.” “What will this break in production under load?” Each starts from your full context, so they don’t rehash the basics, and they return with a developed opinion. You then synthesize. The bonus is that the forks can’t see each other, so they don’t anchor themselves to one another, and you get three independent perspectives.
And now for the catch, which I have to spell out for you right away before I forget. All forks inherit your framing—and with it, your biases. If the initial reasoning is flawed or biased, you’ll get three flawed answers. If I really want to challenge my own framework, I’ll send a fresh subagent with no history instead—precisely because it isn’t tainted by how I think about the problem. So I use the fork to explore my framework more deeply, and the clean subagent to challenge and validate it.
What the announcement leaves out and how I view the whole thing
There remain questions that the announcement leaves out, and they are all purely practical. First: does the fork share the prompt cache read-only, or can it overwrite the cache that the main session relies on? We don’t know. In parallel runs, this is a textbook way to shoot yourself in the foot. Second: “the result is returned”—fine, but in what form? As a summary? As a diff? For merging back in, especially for people without a programming background, I need a detailed overview. What changed, what passed tests, what the agent based its work on. Without that, the fork is a black box I’m supposed to trust blindly. Third: the smooth interface from the video (Agent View) doesn’t render the terminal next to the main agent as snappily as the clip promises, and third-party tools are currently patching that gap. And I’ll add a fourth: how many forks can run at once, and what will that do to rate limits? Even that announcement leaves that open, and in a branching investigation, that’s the first thing you’ll run into.
I like the direction without reservation. Delegating a task with full context and getting the result back is more practical for most work than sending a subagent from scratch. However, the value of this feature stands or falls with the prompt cache and how transparently the result can be verified before I merge it into the main branch.
And don’t forget one thing: when it comes to code, I never trust what the fork writes in the summary. “Done, tested” is just a phrase. The proof is in the diff. Until Anthropic clarifies how cache coherence works and in what form the result is returned, I’m treating /fork as a well-targeted prototype running in production. Useful? Yes. Finished? Not yet.