What you’ll be able to do
- Explain what compaction preserves and what it’s willing to lose
- Decide between compacting and re-architecting a session’s information flow
- Recognize when relying on compaction masks a design problem elsewhere
What you need to know
What compaction actually does
Compaction summarizes a session's earlier conversation to reclaim context budget, replacing a long history of turns with a condensed account of what happened and what still matters. It can run automatically as a session approaches its context limit, or be triggered directly. Either way, the trade is the same: length for fidelity.
What survives compaction tends to be the gist — decisions made, files touched, the current state of the task. What doesn't reliably survive is exact wording, precise file:line references from early in the session, and the kind of specific detail a re-invoked skill's full report would have carried. Compaction is a lossy summary by design, not a lossless archive.
The right problem for compaction, and the wrong one
Compaction is the right tool when a session has genuinely run long doing varied, legitimate work — many files touched, many decisions made — and simply needs room to keep going. That's length from real breadth, and summarizing the tail to make room for the head is a reasonable trade.
It's the wrong tool when the bloat has one specific, identifiable source — the same skill re-appending its full output every time it's invoked, for instance. Compacting there treats the symptom repeatedly instead of fixing the source once. The previous lesson's fix — isolating that skill's execution and shrinking what it reports — removes the bloat at its origin; compaction just summarizes it away after the fact, and it'll be back next time the skill runs.
- Long session, varied real work → compaction is a reasonable, expected part of the workflow.
- Long session, one noisy repeated source → fix the source (isolate it, shrink its output); relying on repeated compaction just re-treats the same problem.
What an architect designs around this
A system relying on very long-running sessions should assume compaction will happen and design so that the things it can't afford to lose — exact identifiers, hard constraints, decisions that must not be re-litigated — are re-stated somewhere durable (like a CLAUDE.md or a structured task file) rather than trusted to survive purely in conversational history.
Key concept
Compaction trades length for fidelity by summarizing the past. It’s the right fix for a session long from real breadth, and the wrong fix for one bloated by a single noisy repeated source.
When a scenario shows a team repeatedly compacting the same session to work around the same recurring bloat, the exam wants you to name the actual source and fix that, not just endorse compacting again.
Practice scenario
Work it through, then open this
A recurring bloat point at roughly the same interval suggests one identifiable, repeated source — likely a skill or step re-appending a large amount of output each time it runs — not simply a long session doing varied work. Compaction treats the symptom each time; the actual fix is finding and isolating that source (for example, adding context: fork to the responsible skill) so it stops accumulating in the first place.
Build exercise — Distinguish “long from breadth” versus “long from one source”
Beginner · 15 min
What you’ll learn
- Reading a session’s growth pattern to identify its cause
- Deciding when compaction is the appropriate response
- Spotting a recurring bloat source compaction keeps papering over
-
Look at where a long session’s context is actually going — many different files and decisions, or the same source repeating.
- Why: The two causes call for different fixes, and treating a repeated-source problem with compaction alone won’t resolve it.
- You should see: Either genuinely varied work, or one identifiable repeat offender.
-
For a session compacted more than once, check whether the same kind of content reappears and grows back between compactions.
- Why: If the same bloat regrows after each compaction, the source was never fixed — only summarized away temporarily.
- You should see: A pattern worth fixing at the source, or confirmation that compaction is doing its intended job.
Exam traps
Reaching for /compact as the fix for every long-session problem
It’s the right tool for length from real breadth, and the wrong tool for length from one repeated, identifiable source.
Assuming compaction preserves exact quotes and file:line references
It’s a lossy summary. Exact detail from early in the session is not guaranteed to survive.
Compacting repeatedly instead of fixing a single noisy source of context bloat
Repeated compaction around the same recurring cause treats the symptom every time instead of the source once.
Not knowing what a session loses across a compaction boundary
Assume gist survives and precise wording or references may not — design so that anything you can’t afford to lose is stated somewhere durable, not just in conversation history.