Claude Certification Guides
CCAR-F/Domain 59 min read

Lesson 5.3

Compaction, Summarisation and Long Conversations

The techniques for keeping a long-running conversation or agent inside its context window, what each one loses, and how to design for that loss.

Every long conversation eventually meets the context window. The choices are to stop, to forget selectively, or to compress. Compaction (summarising older content into a shorter form) and context editing (removing stale content outright) are the two compression families, available both inside Claude Code and at the API. Each is lossy in a different way, and the exam tests which to apply when and how to protect the information that must survive.

Compaction in Claude Code

Claude Code compacts automatically when a session approaches the window limit: it summarises the conversation so far, replaces the history with the summary, and continues. You can trigger it manually with /compact, optionally with focus instructions (/compact keep the list of files changed and the failing tests), and start fresh with /clear when the previous work is no longer relevant. /context shows how close you are.

Two hooks matter here. PreCompact fires before either automatic or manual compaction and can record the full transcript elsewhere or inject instructions about what to preserve. SessionStart with the compaction source lets you re-inject essential context after a compaction, such as the current task description or the branch name.

Design consequence: anything the agent must know precisely after compaction belongs in a file, not in the conversation. Writing a progress note or a plan to disk before long operations is cheap insurance; the summary may drop a detail, but the file will not.

Compaction at the API

Server-side compaction (currently a beta feature with a context-management edit type and a beta header) performs the same operation for your own applications: when the conversation nears a threshold the API summarises earlier context into a compaction block in the response. The critical rule is to append the entire response.content to your message history on every turn, not just the text, because the compaction block is what replaces the old history on the next request. Extract only the text and the state is silently lost.

The do-it-yourself version is a summarisation step in your code: when count_tokens crosses a threshold, send the older turns to the model with a summarisation prompt tuned to your domain, replace them with a single message containing the summary, and keep the most recent turns verbatim. Doing it yourself costs an extra request but gives you control over what the summary preserves.

Context editing

Context editing removes rather than summarises. The API's context-management edits (beta) can clear old tool results, optionally the tool inputs too, and old thinking blocks once the conversation exceeds configurable thresholds. The transcript stays intact in structure; only the bulky payloads are replaced with short placeholders. This suits agent loops where tool results dominate the window and are rarely needed again after the model has acted on them. It is cheaper than compaction (no summarisation call) and more predictable (nothing is paraphrased), but it discards rather than condenses, so it should not be used on content the model may need to reconsult.

TechniqueWhat it keepsWhat it losesBest for
CompactionA summary of everythingDetail and exact wordingLong conversations with evolving goals
Context editingRecent content verbatim, structure of the restOld tool results and thinkingTool-heavy agent loops
Sliding windowThe last N turns verbatimEverything olderChat where old turns rarely matter
Memory tool or filesFacts the model chose to storeNothing, but only what was storedCross-session persistence

Many long-running agents use several at once: editing to keep tool output in check, compaction when the limit nears, and memory or files for anything that must survive both.

Designing for loss

  • Externalise state early. Plans, decisions, file lists, test results: write them down where a resumed or compacted agent can read them.
  • Isolate noisy work in subagents. A subagent that reads fifty files returns a short report; its context is thrown away, and the parent never fills up.
  • Keep the stable prefix stable. Compaction and editing operate on messages; a system prompt that tries to carry conversation state will both grow and break caching.
  • Compact before you must. Quality degrades before the limit; a threshold around three quarters of the window is a common choice.
  • Test the summary. Review what your compaction keeps on real transcripts and tune the focus instructions; a summary that drops the user's constraints causes confident mistakes afterwards.

Exam focus

  • Claude Code auto-compacts near the limit; /compact [instructions] compacts manually; /clear discards; PreCompact can save the transcript or steer the summary.
  • API compaction returns a compaction block that must be passed back by appending the full response.content.
  • Context editing clears old tool results and thinking without summarising; compaction summarises; a sliding window drops.
  • Facts that must survive compaction belong in files or the memory tool, not in the conversation.
  • Subagents isolate context-heavy work so the parent stays small.
  • Trigger compression well before the hard limit, because long-context quality degrades first.

Check yourself

5 questions

  1. 1.What does Claude Code do when a session's context approaches its limit?

  2. 2.A team enables server-side compaction on the Messages API but appends only the text of each assistant reply to the history. Soon after a compaction occurs, the context size balloons again and behaviour degrades. Why?

  3. 3.What is the difference between context editing and compaction on the Messages API?

  4. 4.An application summarises older turns client-side, but after summarisation the agent forgets key decisions (for example the database schema it chose) and contradicts itself. Which design addresses this?

  5. 5.A chat product built directly on the Messages API lets conversations grow indefinitely. Which statement about managing that history is correct?