I wrote two pieces about this problem. The first was about surviving the token limit — stop treating the chat as the unit of work, keep the real memory outside the session, and a reset becomes a resumption. The second was about what that actually looks like across weeks: a project needs its own architecture, stable knowledge in one layer, volatile state in another, and the handoff trimmed to a signpost rather than a journal.
Both were right. Both assumed something I hadn’t examined: that a session ends, you write the handoff, and the next session begins fresh.
That assumption held for a long time. Then a feature landed that made me reconsider it.
What the fork command actually does
Claude Code shipped /fork in early 2026 as a native command. The description is simple: it creates a new session that inherits the full conversation history of the current one. The original session stays intact. The fork develops independently.
This is not the same as continuing a session. A continuation picks up in the same thread — same token accumulation, same growing window. A fork creates a branch. The cost counter resets. The context is copied once. From that point, two separate conversations exist, neither dependent on the other.
It sounds like a technical detail. It turns out to be a different way of thinking about what a session is for.
The problem the handoff file was solving
To understand why forking matters, it helps to be precise about what the handoff file was actually doing.
The handoff was a bridge across a hard discontinuity. Session ends — by your choice, by token limit, by a provider timeout — and the next session has no memory of what happened. The handoff file existed to carry signal across that gap. You wrote it before closing, you loaded it after opening, and the model had enough orientation to keep working.
That is a good solution to the problem it solves. But the problem it solves is not the only continuity problem you encounter on a real project.
Sometimes the session does not need to end. Sometimes you are mid-thread, the work is going well, and you want to try a different approach — not instead of the current one, but alongside it. You want to explore the alternative without abandoning the main path, and without paying the full cost of re-explaining context from files.
For that problem, the handoff is the wrong tool. You are not trying to bridge a gap. You are trying to create a branch.
Forking is not a replacement for the handoff. It’s a different move.
This is the distinction worth holding clearly, because conflating them leads to the wrong habits.
A handoff is for discontinuity you own. You decide the session is done. You capture what matters. You start fresh with structured context loaded from files. The cost of re-loading is low because the files are lean and well-shaped. The tradeoff is deliberate: you lose the raw thread in exchange for a cleaner start.
A fork is for exploration without abandonment. You are still in the work. The thread is live and dense and useful. You want to ask “what if we approached this differently?” — without erasing the version that is already working, and without rebuilding context from scratch to pose the question.
One other scenario: a session that has run long enough to grow expensive. Not dangerous — not incoherent, not bloated with dead history — just long. Each turn is re-sending a transcript that has grown over the course of real, useful work. You are not ready to checkpoint and start clean, but you can feel the window accumulating weight. A fork there lets you shed the cost without losing the live context. You continue from the full picture, but the new session’s counter starts at zero.
What changes in practice
If you have been working with the file structure from the previous piece — STATUS.md, HANDOFF.md, DECISIONS.md, the skills directory — nothing about that needs to change. The fork is not a replacement for those files. It is a complement.
Here is how the mental model shifts.
Before: a session ends → you write the handoff → the next session loads it.
After: a session ends → you write the handoff → the next session loads it. Or: the session is still live → you fork → the new branch inherits the full thread and you explore freely → you bring conclusions back to DECISIONS.md once something settles.
The files remain the source of truth across hard resets. The fork handles the soft ones — the ones where you don’t actually want to start over, you just want to step sideways without losing your footing.
The one thing forking does not solve
Forking copies the thread. It does not copy the judgment about what in that thread matters.
A handoff file is compressed by a human who understands what is stable and what is noise. It carries the decisions that settled, the constraints that held, the one next step — and nothing else. The fork carries everything, including the wrong turns, the abandoned ideas, and the three messages where you were working out loud and hadn’t landed anywhere yet.
In a short session, that is fine. The thread is dense with signal. In a session that has been running for hours across a complex problem, the full thread can carry the same ghosts that made the handoff file bloat in the first place — old assumptions still present, ideas you killed but didn’t formally close, constraints you restated four different ways because you were still figuring them out.
This is not a reason to avoid forking. It is a reason to still write the handoff when you close a long branch, even a forked one. The fork gives you full context for free. The handoff gives you clean context on purpose. Both are useful. Neither replaces the other.
Three moves, not one
The model that has emerged from all of this is cleaner than it looks at first.
You have three continuity moves, each for a different situation.
Continue when the session is still in good shape — context is focused, the thread is useful, and you are not hitting either a cost ceiling or a coherence problem. No action needed. Keep working.
Fork when the session is worth preserving but you want to branch — exploration, alternative approaches, or a session that has grown expensive without becoming incoherent. The full thread carries forward. You explore cleanly. The original path stays intact.
Checkpoint and restart when the session has done its work and needs to close. Write the handoff. Update decisions. Trim status. The next session loads clean context from files, and the cost resets deliberately.
These are not competing strategies. They are different tools for different moments in the same project. Knowing which moment you are in is the judgment call that matters.
The project still persists
The core argument from both earlier pieces holds. A session is a workspace. The project is what persists between workspaces.
Forking adds a third kind of workspace: not a continuation and not a fresh start, but a branch off something that is still live. The project’s architecture — the files with clear responsibilities, the handoff trimmed to a signpost, the decisions captured once and not re-litigated — remains the backbone. The fork is a move within that architecture, not a replacement for it.
What I keep arriving at, from different directions, is that the interesting problems in AI-assisted work are not technical ones. They are structuring problems. How do you keep the work coherent across time? How do you decide what survives a transition, in what form, at what granularity? How do you know which move to make — continue, branch, or close — and when?
Those are judgment calls. The tools that support them keep improving. The judgment does not automate.
Sessions will still end. Handoffs will still matter. But now there is a move between “keep going” and “start over,” and that move has a name. Use it when the moment calls for it. Keep writing the handoff when the moment calls for that. Know the difference.
The project takes care of itself only if you design it to. A fork does not change that. It just adds one more way to keep the work alive.