- In short
- Session management scenario analysis is the capstone skill of Task Statement 1.7: reading a realistic prompt, extracting the signals that decide the approach, whether files changed, whether you need a divergent branch, and whether context has degraded, and justifying a choice of resume, fork, or a fresh start with summary injection. It is evaluation, not recall: the same goal can map to all three depending on the state of the work.
What session management scenario analysis asks of you
Session management scenario analysis is the capstone of Task Statement 1.7, and it is pitched at the evaluate Bloom level because it asks for judgment rather than recall. You are handed a realistic situation, an engineer mid-task, a session that has drifted, a need to compare approaches, and asked to choose the best move and defend it. The options, resume, fork, and a fresh start with summary injection, are already familiar from session management options. The difficulty is that the right answer is not written on the surface of the prompt; it is encoded in the details about the state of the work.
This is the most demanding knowledge point in the task statement, with the highest difficulty rating, precisely because it composes everything before it. You need the vocabulary of the three options, the decision framework for choosing among them, a working understanding of the stale context problem, and the constructive skill of summary injection. Scenario analysis is where those pieces are tested together under exam conditions.
- Decision signal
- A concrete detail in a scenario that determines the right session strategy, such as whether files have changed, whether the original thread must be preserved, or whether the context window has degraded. Identifying the signals, not the goal, is what scenario analysis rewards.
The three signals to extract from any prompt
Every session scenario can be cracked with the same three questions, applied in order.
Has the context gone stale? This is the first and most powerful signal, because a yes vetoes the easy answers. Look for any mention that files were edited, rewritten, committed, or that a colleague changed code, after the agent last read them. If the context is stale, both a blind resume and a fork are wrong, because both replay the outdated tool results. The honest options narrow to targeted re-analysis or a fresh start with a summary.
Do you need the original thread preserved? This signal separates fork from resume when the context is still valid. Look for language about comparing approaches, keeping a fallback, or exploring a risky idea without abandoning a safe one. If preservation matters, fork; if it does not, resume.
How degraded is the conversation? Even without changed files, a session can rot through sheer length, a context window so full of old output that the decisions you care about are buried. Heavy degradation tips a valid-but-bloated session toward a fresh start with a curated summary, trading a lossless resume for a cleaner footing.
Why the goal alone never decides it
The defining trap of this knowledge point is that the goal in a scenario is almost always the same: the engineer wants to keep making progress. If you map "keep working" straight to "resume," you will get a predictable share of questions wrong, because the exam constructs scenarios where the surrounding state quietly demands fork or a fresh start. The same intention, continue the work, resolves to resume when nothing changed, to fork when a comparison is needed, and to a fresh start when the files moved or the context bloated.
This is why evaluation beats pattern-matching here. A weaker test-taker scans for the verb and answers reflexively; a stronger one scans for the state and reasons. The Claude Code documentation reinforces the underlying mechanics, the session picker, named sessions, and forking with --fork-session, but the exam is testing whether you can connect those mechanics to a messy situation, not whether you can list them.
A rubric you can run in your head
Under time pressure, a fixed routine beats improvisation. Run these four steps on any session prompt. First, scan for change: did any file get edited, rewritten, or committed after the agent last read it? If yes, mark the context stale and strike resume and fork from the list. Second, scan for preservation: does the scenario need the original thread kept for comparison or fallback? If yes, and the context is still valid, fork. Third, scan for degradation: even with no file changes, is the window described as bloated, sprawling, or full of old output? If yes, lean toward a fresh start. Fourth, default deliberately: only if none of the first three fired do you resume, because a clean continuation is genuinely the best move when nothing has changed. Running the rubric in that exact order is what keeps you from answering on instinct.
More mini-cases to calibrate on
A few extra cases sharpen the eye. A nightly CI job needs the context of yesterday's analysis run, but each CI run is a fresh container with no session file on disk; the answer is not resume, which would fail to find the session, but a fresh start with an injected brief built from saved application state. A multi-user support tool keeps one session per customer; when a returning customer messages again, the right move is to resume by that customer's captured session ID, not continue, which would grab whichever session was most recent in the directory. A long generation run died with a turn-limit error and nothing in the repository changed; the right move is a plain resume with a higher limit, since the context is perfectly valid and only the run was cut short. Different surfaces, the same discipline of reading the state.
Distractor archetypes the exam plants
Knowing how wrong answers are built is half the battle. Watch for the sampling fix, lowering temperature or raising max_tokens to "stop contradictions," which mistakes a freshness problem for a generation problem. Watch for fork-as-cleanup, an option that offers a fork as a way to get a clean slate when forking actually copies the stale history. Watch for the blind resume, the choice that continues the session while conspicuously ignoring a sentence about changed files. And watch for over-correction, a full re-read of the whole codebase when a targeted re-analysis would do. Each archetype is plausible because it solves a problem; it just is not the problem the scenario actually poses. Naming the archetype as you read is the fastest way to eliminate it.
What "evaluate" really demands here
It is worth naming why this knowledge point is graded as evaluation rather than application. Application would be executing a known procedure; evaluation is weighing competing options against criteria and defending the pick. A session scenario gives you no procedure to run, only a situation to judge, and frequently more than one option is defensible until you weigh it against the signals. That is by design: the exam is probing whether you can hold three options in mind, test each against staleness, preservation, and degradation, and articulate why the survivor wins. If you can say not just "fresh start" but "fresh start, because the files changed and the window is bloated, which rules the others out," you are operating at the level this capstone is built to measure. Practising that one-sentence justification, naming the chosen option and the signals that eliminated the others, is the single most effective way to prepare, because it forces exactly the structured reasoning the question format is designed to reward.
How this knowledge point is tested
Scenario analysis questions live mainly in Scenario 4, Developer Productivity with Claude, the scenario where Domain 1 meets day-to-day engineering. A prompt will sketch a concrete moment, hours into a session, several files rewritten, advice starting to contradict the code, and offer four next steps. Three will be plausible, and each plausible distractor typically ignores exactly one signal: a resume that overlooks changed files, a fork that pretends to deliver a clean slate, a temperature tweak that mistakes a context problem for a sampling problem. The correct answer is the one that honours every signal at once.
Because this is an evaluate-level capstone, it also models the shape of other scenario-analysis knowledge points across the exam, such as workflow enforcement scenario analysis. The transferable habit is the same everywhere: extract the deciding signals, rank the options against them, and justify the pick.
Worked example
An exam-style prompt bundles three sub-situations that each demand a different session strategy.
A developer is deep into a Claude Code session improving a data pipeline, and the prompt presents three moments to evaluate.
In the first moment, they step away for coffee, change nothing, and return to keep tuning the same query. No staleness, no need for a branch, no bloat: every signal says resume, and resuming restores the full analysis for free.
In the second moment, the analysis is solid and they want to trial an aggressive caching strategy while keeping the current, working plan intact to fall back on. Context is valid and the original must be preserved: the signals say fork, branching a divergent copy so both strategies can be compared.
In the third moment, they realise that two teammates rewrote the pipeline's core modules an hour ago, and the agent has begun recommending changes to code that no longer exists, all while the context window groans with stale reads. Staleness vetoes resume and fork, and the degradation tips the balance past targeted re-analysis. The signals say fresh start with an injected summary of the findings and decisions that still hold.
The same developer, the same broad goal of improving the pipeline, and three different correct answers, decided entirely by reading the state rather than the intent. That is session management scenario analysis in one exercise.
Common misreadings to avoid
Misconception
Resume is the default best choice, so when a scenario is ambiguous, resuming is the safe pick.
What's actually true
Misconception
The right session strategy depends mainly on what the developer is trying to do, not on what changed on disk.
What's actually true
In an exam scenario, a developer has worked in one Claude Code session for hours. The context window is bloated with old tool output, several files have since been rewritten, and the agent's recent advice has started to contradict the current code. What is the most reliable next step?
People also ask
How do I choose between resume, fork, and a fresh start?
Which session approach fixes stale context?
How is session management tested on the Claude exam?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Claude Code Session Management & 1M Context: The Official Guide (Full Breakdown)
Why watch: Full breakdown of resume, fork, and fresh-start tradeoffs, directly mapping production situations to the right session-management choice.
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.