Branch with /fork, Delegate with /subtask — Two Commands That Traded Jobs

I typed /fork out of habit. There was a small thing I wanted to try, and I expected the conversation to branch right where I was sitting.

What came back was not the in-session reply I was used to. A new row had appeared in claude agents. My cloned conversation had started running somewhere else entirely.

Claude Code 2.1.212 changed what /fork does. It now clones your conversation into a fresh background session, and the in-session subagent behavior that /fork used to trigger has moved to /subtask. Same names, swapped jobs.

The switch threw me at first. After running both a few times, though, I came around to it. Here is the split I settled on, working as an indie developer where every branch competes with the one pair of hands I have.

What each command handles now

Here is the division of labor, side by side.

Put simply: /fork is for branching, /subtask is for delegation. Branches leave your desk. Delegation stays on it.

If a session has no title, the clone gets named from the prompt you typed. Whether you can later look at that list and remember what a branch was for depends almost entirely on how well that auto-naming lands. So I have started treating the first line of a branch as a label. Not "keep refactoring the way we discussed," but "try moving auth from session cookies to JWT." It reads back cleanly a week later.

Branches stop taking over your desk

The old /fork had one persistent annoyance: the moment you branched, the branch owned your screen. What I wanted was a second possibility explored, not an interruption to the implementation already in flight. But until the reply came back, my desk was occupied.

The new /fork inverts that. The clone runs as an independent background session while your conversation continues untouched. The branch grows on its own, and you go look at it through claude agents when you feel like checking in. Control stays where you are.

When branching gets cheap, decisions change shape. Instead of comparing two designs entirely in my head, I now push one to /fork at the moment of hesitation and keep working the other locally. Thirty minutes later I have both outcomes side by side and can pick. I prefer working this way. When I try to finish a comparison in my head, I usually end up favoring whichever idea arrived first.

One related note: typing /resume in the agents view opens a picker of past sessions, including ones you removed from the list, and the one you pick resumes as a background session. So leaving a branch running and forgetting about it is recoverable.

When to reach for /subtask

So when is /subtask the right call? For me it comes down to a single question: does the result need to come back into this conversation?

If yes, use /subtask. Investigate why a test is failing, then write the fix informed by that conclusion. Build a dependency list, then decide migration order while looking at it. Work like this only means something once the result is folded back into the parent context. Push it to a separate session and the cost of carrying the answer home exceeds whatever you saved.

If no, use /fork. "Try it this way as well." "See what it looks like written against the other library." These can be judged on their own, so they can leave your desk.

One behavior around /subtask did change. The Task tool's mode parameter is deprecated and now ignored. Subagents inherit the parent session's permission mode by default.

That sounds small, and it isn't. If your parent session runs in a loose mode, every subagent you carve out of it runs equally loose. Tightening only the subagent side via mode no longer works. Permissions get decided at the parent. I read that as the responsibility being consolidated into one place, which seems like the honest design.

# Permission mode is decided when the parent session starts.
# Subagents inherit whatever you choose here.
claude --permission-mode acceptEdits
 
# Branches work the same way: they carry the settings from the clone
# point and then run independently. To check on them:
claude agents

Set your budget before you start branching

The same 2.1.212 release added two per-session caps.

Both budgets reset with /clear. The intent is to stop runaway search and delegation loops.

This is the change I sat with longest. Someone decided a ceiling was necessary, and behind that decision there was almost certainly a log of something that ran away. I have my own version of that: jobs running overnight, and a morning spent staring at the transcript wondering what it had been searching for all that time. What the log actually held was the same query, asked slightly differently, over and over.

Building something that stops is more honest than building something that never needed to. That is where I have landed.

In practice, scoping the budget per use case beats leaving 200 everywhere.

# Unattended nightly job: state the budget explicitly
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=20
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=10
claude -p "Summarize today's release notes and write them into docs/"
 
# Interactive research: the default 200 is almost always plenty

There is nothing principled about 20. My daily summary job actually uses three to five searches, so 20 is the line past which I can say "something is wrong here" with confidence. Being able to draw that line from your own measurements is what setting a cap really amounts to. The default of 200 is best treated as a placeholder until you have drawn yours.

One more change touches responsiveness. MCP tool calls that run longer than two minutes now move to the background automatically. The threshold lives in CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS, and you can raise it or turn the behavior off.

# Loosen the threshold to five minutes (default is 120000 ms = 2 minutes)
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=300000

Branching, delegation, and long calls all moved in the same direction this release: none of them should hold your session hostage.

Turning it into settings

Written out as a decision flow:

1. Does the result need to return to the parent conversation? Yes means /subtask, no means /fork.
2. Do you want to keep working meanwhile? If yes, /fork.
3. Where do permissions get decided? At parent session startup — mode is ignored now.
4. What is the budget? Roughly three to five times your measured usage. Treat 200 as provisional.

Worth noting alongside this: cross-session chatter got cheaper. SendMessage bodies no longer get duplicated into both the replay history and tool results, which cuts token spend on agent-to-agent messages. The more you branch and delegate, the more that shows up.

For session switching and context hygiene, /clear vs /compact in Claude Code: Choosing the Right Reset for Long Sessions is the foundation. Subagent implementation patterns themselves live in Claude Code Multi-Agent Parallel Execution — Task Tool and SubAgent Patterns That Hold Up in Practice, and keeping an eye on background sessions once they are running is covered in My background session sat at running all night — adding heartbeats to the agents view.

Closing thoughts

The /fork and /subtask split is less a renaming than a recognition that branching and delegating are different activities that deserve different places to live.

The thing to try first is your next moment of hesitation between two designs. Don't finish the comparison in your head. Push one to /fork, keep working the other, and lay them side by side afterward. One round of that and the value of cheap branching stops being theoretical.

I'm still finding my footing with this myself, and I'd be glad to keep learning alongside you.