Context Compaction solves a very concrete nuisance: once a session has run for a while, message history, tool output, and files read in keep piling up, and sooner or later they fill the context window and the task can't continue.
The approach is to pause as the window fills, have the model summarize what has happened so far, replace that whole pile of messages with the summary, and let the session continue carrying only the summary. The "compacting context" message you see in AI coding tools is exactly this.
Grab It in One Sentence First
Context Compaction swaps verbose history for a summary as a session fills up, so the task can keep going.
An everyday analogy is minutes from a long meeting. After three hours, nobody carries a verbatim transcript into the next session; someone writes up "decisions made, open items, owners, next steps," and the next meeting runs off that. Compaction does the same thing: keep conclusions and state, drop the process and the raw material.
Why This Term Emerged
Agent applications magnified the problem. Ordinary chat ends after a few dozen turns, but an Agent running a batch job may process dozens of items in sequence, each producing several tool calls and large return values. Input tokens grow linearly with turns and quickly hit the ceiling.
Anthropic's official example includes numbers that convey the scale: the same workflow processing five support tickets consumed roughly 209k tokens with 73 messages accumulated in context when compaction was off; with compaction on, it consumed roughly 86k tokens — close to a sixty percent reduction — triggering compaction twice, with the message count collapsing back to one after each.
flowchart LR
Turn["Ongoing conversation<br/>history keeps growing"] --> Check{"Tokens above<br/>threshold?"}
Check -->|no| Turn
Check -->|yes| Sum["Ask the model to summarize progress"]
Sum --> Replace["Replace history with the summary"]
Replace --> Cont["Continue with compressed context"]
Cont --> TurnWhat It Usually Includes
Taking automatic compaction in the Claude Agent SDK as the example, the flow runs roughly like this: monitor token usage per turn; when cumulative usage crosses a configured threshold, inject a message asking for a progress summary; have the model produce a summary wrapped in <summary> tags; clear the existing history and keep only that summary; then continue with the compressed context.
The summary typically preserves completed items and their outcomes, assigned categories and priorities, progress (how much is done, how much remains), key patterns discovered, and what to do next. What gets discarded is typically full knowledge-base search results, complete tool outputs, the detailed reasoning behind classifications, full drafted text, and assorted intermediate processing details.
The threshold is adjustable. The official guidance: a low threshold (a few thousand to twenty thousand tokens) suits pipelines processing entities one at a time — frequent compaction, little accumulation; a medium one (fifty to a hundred thousand) suits multi-phase workflows with clear checkpoints; a high one (above a hundred thousand) suits tasks that need substantial historical context. You can also customize the model used for summarizing and the summary prompt itself, specifying what must be kept.
The Difference from Context Windows and RAG
The context window is the capacity ceiling, and compaction is the response when you hit it — problem and countermeasure. RAG also deals with "the information doesn't fit," but in the opposite direction: RAG brings in what's needed from a large external corpus, while compaction shrinks what's already in the window. One manages intake, the other manages cleanup.
Among the four strategy buckets of context engineering, compaction belongs to "compress"; RAG belongs to "select"; writing intermediate conclusions to a file belongs to "write"; splitting work to subagents belongs to "isolate." Real systems usually use all four together.
Its Relationship to the Long-Session Experience
Users feel compaction directly: after an AI coding tool has run for a while, it "forgets" some detail mentioned earlier, often because that passage was judged unimportant during compaction and dropped. A summary preserves conclusions, not the original text, so any follow-up that depends on the raw detail may come up empty.
This is also why many tools let you intervene before compaction happens — deliberately compacting at a clean checkpoint works better than being compacted when the window is nearly full. The first makes the trade-off while the information is still clear; the second asks the model to squeeze an almost-full window into a paragraph at the worst possible moment.
Where It's Easy to Misunderstand
The first misconception is treating compaction as lossless. It's lossy by definition, and the official documentation lists that as a limitation. Scenarios needing a complete audit trail — compliance records, incident reviews, debugging that requires stepping back through every move — shouldn't rely on compaction; the process should be persisted separately.
The second is "compaction equals savings." Generating the summary costs tokens too, and compacting too often adds overhead. What you save is the history that would otherwise be carried again on every subsequent turn, so it only pays off when the session is long enough.
The third is assuming compaction protects everything. Implementations differ: some compact only conversation history, re-injecting rule files that were loaded from disk at startup, while files read mid-session vanish until something reads them again. It's worth confirming what your particular tool actually preserves before relying on it.
How to Decide Whether to Use It
Look at the shape of the task. Processing independent entities one at a time (tickets, products, files, issues), multi-step workflows with clear phase boundaries, extended batch analysis, and chunked data processing all suit compaction well — what they share is that earlier details stop mattering once the step is done and only the conclusion needs to survive.
Conversely, be careful with tasks that need a complete record, tasks that depend heavily on the verbatim original context, and call patterns where a server-side sampling loop doesn't play well with the compaction mechanism. A reasonable middle ground: leave compaction on, but also write key intermediate artifacts to an external file or board — let the summary handle "keep running" and let external storage handle "look it back up."