Frequently Confused Concepts — Context Management & Reliability (CCA-F Domain 5)

These three answer 'what happens to the context I've already built up?' Resume/continue reopens a prior session and appends to it — prior context is restored intact. Compact stays in the same session but replaces older turns with a summary, freeing token budget while continuing. New session starts clean — no prior context at all. The tell in a scenario is what the user wants to keep: everything (resume), the gist but with room to keep going (compact), or nothing (new).

In Claude Code, claude --continue reopens the most recent session in the current directory; claude --resume targets a specific session by ID. Both reopen the same session and append. /compact summarizes older messages in place. Exact flags can change across versions — confirm in current docs — but the three behaviors are the stable, testable idea.

Resume and fork both start from an existing session, but they differ on identity. Resume continues the same thread — new messages extend the original, one timeline. Fork branches the session into an independent copy: the fork gets its own session ID seeded with the history so far, and the original is left untouched. Fork is for exploring an alternative — a different approach, a risky refactor, a what-if — without polluting the thread you might want to return to.

In the Claude Agent SDK, forking is expressed by resuming a session and asking for a branch: pass the original session id to resume and set forkSession: true in the query() options, which produces a new session id seeded with a copy of the prior history. Without the fork flag, resuming simply continues the same session in place. Treat the exact option names as version-specific and confirm them in the current Agent SDK docs; the concept — branch a copy vs continue the original — is the durable, testable part.

Both re-establish prior context for a new stretch of work, but they trade fidelity against compactness. Resume restores the actual transcript — every prior turn, verbatim, high fidelity, high token cost. Summary injection means you (or a tool) hand-write a condensed brief of the prior findings and drop it in as fresh context — low token cost, but only as good and as complete as the summary. Resume can't lose a detail it kept; a summary can only carry what its author thought to include.

This is the same fidelity/compactness axis as compaction, but with different authorship and timing: /compact is the tool summarizing to survive the window mid-session; summary injection is a deliberate handoff you craft — often to seed a brand-new session or a subagent with just the distilled conclusions.

The context window is the finite, per-request token budget the model actually attends to — everything in this call: system prompt, history, tool results, the current input. It is bounded and volatile: exceed it and something must be dropped or summarized, and nothing in it persists on its own. Memory is anything deliberately persisted outside the window — files, a scratchpad, a database, an external store — that outlives any single request and can be selectively read back in later.

The relationship is the whole point: memory is durable but the model can't 'think' with it directly; the window is what the model thinks with but it's small and temporary. Useful memory is memory you can retrieve a relevant slice of back into the window when needed — persisting is only half the job.

Easy to blur because a long session feels like one continuous mind. It isn't. A context window is the token budget of a single request. A session is a conversation thread that spans many requests. The bridge between them is the stateless Messages API: the model stores nothing between calls, so a session only continues because the client resends (and persists) the accumulated history on every request. The session is a client-side construct; the window is what one request actually carries.

This is why a session can outgrow the window. Turn after turn, the replayed history gets longer until it no longer fits one request's budget — which is exactly when compaction or summarization has to step in. The session (the full logical thread) and the window (what fits in one call) drift apart, and managing that gap is context management.

When something fails, reliable systems ask one question first: is this failure recoverable by trying again? Retry re-attempts an operation that failed for a transient reason — a timeout, a rate limit, a brief network blip — usually with backoff, because the same call may well succeed a moment later. Escalation hands the problem off — typically to a human — when retrying won't help: the error is non-recoverable, the situation is out of policy, or a human decision is explicitly required. Retrying a non-retryable error just burns time and money and can make things worse.

The distinction rests on an error taxonomy. Retryable vs non-retryable: transient/infrastructure failures (timeouts, 429 rate limits, 503) are retryable; deterministic ones (malformed request, 401 auth, 404) are not — they'll fail identically every time. Validation vs business errors: a validation error means the input is malformed or missing required fields (fix the input, don't retry the same payload); a business error means the input is well-formed but violates a rule (insufficient funds, item out of stock) — a policy decision, not a glitch, and often an escalation rather than a retry. Retrying either unchanged is pointless; the fix is correction or handoff.