- In short
- Choosing between resume, fork, and a fresh start comes down to three questions: is the prior context still valid, do you need to preserve the original thread, and has the conversation degraded or gone stale. Resume when context holds, fork to explore a divergent approach from a valid baseline, and start fresh with a summary when tool results no longer match your files.
Resume vs fork vs fresh start: the deciding questions
Resume vs fork vs fresh start is the judgment that separates an architect who merely knows the three session options from one who can apply them. Once you can name the options, the interesting work is choosing correctly under pressure, and the choice is not a matter of taste. It falls out of three diagnostic questions about the current state of your session.
Ask, in order: Is the prior context still valid? Do I need the original thread preserved? Has the conversation degraded or gone stale? Resume answers the first question with a yes and the others with a no. Fork answers "the baseline is valid, and yes, keep the original." A fresh start answers "the context can no longer be trusted." Memorising commands is the remember tier from session management options; this knowledge point is the analyse tier, where you read the situation and map it to the right move.
- Context validity
- Whether the tool results and analysis saved in a session still describe the current state of your files. When files change after the agent read them, the saved results become stale and the context is no longer valid, which is the single most important input to the resume-fork-fresh decision.
When to resume
Resume is correct when the work in the session is still trustworthy. Concretely, that means the files the agent read have not changed in any way that matters, the goal you are pursuing is the same one the session was built around, and you simply want to carry on from where you stopped. Picking up a paused investigation the next morning, continuing a refactor after a short break, or following up on an analysis the agent already completed are textbook resume situations. Because the saved transcript still mirrors reality, resuming restores everything, the reads, the reasoning, the half-finished plan, with no wasted effort.
Resume has a second, narrower use the docs call out: recovering from a limit. If a run ended because it hit a turn cap or a budget cap, resuming with a higher limit continues exactly where it stopped. The common thread is that nothing about the underlying world changed; only the conversation paused.
When to fork
Fork is correct when the baseline is still valid but you want to take two directions from it. The defining signal is the word and: you want to try an alternative approach and keep the original available. Comparing a JWT implementation against an OAuth2 one from the same analysis, exploring a risky refactor without abandoning a safe plan, or letting two lines of reasoning run from a shared starting point are all fork situations. Forking copies the validated history into a new session ID and lets it diverge, so neither branch contaminates the other.
The trap here is reaching for fork as an escape from a bad session. Forking branches from the existing history, which means a fork inherits whatever is already in that history, including stale tool results. Fork is for divergence from a good baseline, not for cleaning up a polluted one. When the baseline itself is suspect, forking just clones the problem, a point developed fully in the stale context problem.
When to start fresh
A fresh start is correct when the session can no longer be trusted. Three signals point here: the files have changed significantly since the agent last read them, the context window has filled with old tool output that buries the decisions you care about, or the agent's recent advice has started to contradict the current code. In each case, reopening the transcript reintroduces the exact data that is leading the model astray. The reliable move is to open a clean session and inject a short, structured summary of the findings and decisions that still hold, a technique covered in summary injection for fresh sessions.
This is the option people under-use, because resuming feels free and starting over feels wasteful. The exam deliberately rewards architects who notice that a stale resume is more expensive than a clean restart, because contradictory advice costs more to untangle than a two-minute brief costs to write.
Why the order of the questions matters
The questions are deliberately sequenced, and the sequence is the lesson. Validity comes first because it can veto everything else. If the context is stale, it does not matter that you would like to resume or that forking is convenient; both reopen untrustworthy data. Only once you have confirmed the context still holds does the second question, preservation, decide between fork and resume. Getting the order wrong is how careful-sounding answers go astray: a learner who jumps straight to "do I want a branch" can fork a polluted session and feel productive while inheriting the very problem they should have escaped.
This sequencing is also why the analysis is more than pattern-matching keywords in a prompt. Two scenarios can both say "I want to keep working," yet one resumes and the other restarts, purely because one mentions that files changed and the other does not. Train yourself to hunt for the validity signal first.
Two narrower cases: limits and interruptions
Beyond the three headline situations, resume quietly covers a pair of recovery cases worth recognising. If a run stopped because it hit a ceiling, a maximum number of turns or a budget cap that surfaced as error_max_turns or error_max_budget_usd, resuming with a higher limit continues precisely where it halted, because nothing about the files changed; only the run was cut short. The same applies after a process crash or a deliberate shutdown: if you captured the session ID, resuming restores the thread intact. These cases reinforce the core rule rather than complicate it, since in each one the prior context is still entirely valid and the only thing interrupted was the conversation itself.
How forks behave once you have them
Forking has practical texture that scenario questions sometimes probe. In the session picker, forked sessions created with /branch, /rewind, or --fork-session are grouped under their root session, so a branch is visibly a child of the thread it came from rather than a stray entry. One easy-to-miss detail: permissions you approved with "allow for this session" do not carry over to a new branch, so a fork starts with a clean permission slate. And because the original is never written to again once you fork, you can always return to it later by name or ID. These mechanics are exactly why fork is the safe way to explore: the original thread is genuinely insulated from whatever the branch does to the conversation.
The cost calculus behind a "wasteful" restart
The instinct that resuming is free while restarting is wasteful deserves to be challenged head-on, because it is the root of most wrong answers. Resuming a stale session is not free; it spends tokens replaying outdated tool results and then spends your time untangling the contradictory advice those results produce. A fresh start built on a two-minute brief often costs less in total, in both tokens and human effort, than chasing a confused agent around a polluted transcript. So when a scenario nudges you toward resume in order to "save context," pause and ask whether the context being saved is actually worth keeping, or whether it is the very thing leading the agent astray. The exam rarely rewards the lazy resume, and recognising that a clean restart can be the cheaper path overall is often the difference between a merely plausible answer and the correct one.
How this knowledge point is tested
Within Task Statement 1.7, this is the hinge between recall and applied judgment, and it most often appears in Scenario 4, Developer Productivity with Claude. Expect prompts that hand you a working situation, a paused task, a desire to compare approaches, a session that has grown contradictory, and ask for the best next step. The wrong options are usually plausible commands that ignore one of the three questions: a resume that overlooks changed files, a fork that pretends to give a clean slate, or a fresh start where resuming would have been simpler and lossless. Reason through validity, preservation, and degradation in that order and the distractors fall away.
Worked example
Three engineers each return to a session, and identical-sounding goals lead to three different correct choices.
Engineer A paused a session last night to sleep. No files changed, no commits landed, and the task is the same. The context is valid, there is no need for a second thread, and nothing has degraded, so the answer is resume: continue the named session and the full analysis returns intact.
Engineer B has a solid plan in a session and wants to prototype a second, riskier approach while keeping the safe plan available to fall back on. The baseline is valid and the original must be preserved, so the answer is fork: branch a copy, let it diverge, and compare the two later.
Engineer C has been in one session for hours; teammates rewrote three of the files the agent analysed, and the agent has begun referencing code that no longer exists. The context is no longer valid, which vetoes both resume and fork. The answer is a fresh start with a short summary of the decisions that still hold.
The instructive part is how little the stated goals differ, "keep working," "try another way," "carry on", and how completely the right answer is determined by the state questions rather than the goal.
Common misreadings to avoid
Misconception
When I am not sure, resuming is always the safe default because it preserves the most context.
What's actually true
Misconception
Forking gives me a clean baseline that is free of the previous session's stale results.
What's actually true
An engineer pauses a debugging session overnight. No files changed, no commits landed, and they want to pick up the exact same investigation in the morning. Which approach is the best fit?
People also ask
When should I fork instead of resume a Claude Code session?
Should I resume a long Claude Code session?
When should I start a fresh Claude Code session?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
3 Claude Code Features You'll Wish You Knew Sooner
Why watch: Explains when to branch/fork a conversation versus continuing it, giving learners the decision framing between forking for divergent exploration and resuming when prior context is still valid.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.