Hypermile

Context

Claude Code compact (2026): what it does and what it costs you

Mechanics accurate as of August 2026.

Compaction is what keeps a long session alive after the context window fills. It is useful, and it is not free.

TLDR: Compacting replaces accumulated conversation history with a shorter summary so a session can continue past a full context window. You keep working, but you lose specifics — and the agent often re-reads files afterwards because the details went with the history. Frequent compaction is a symptom worth reading: something is filling the window faster than the work justifies.

Short answer: compaction is how a Claude Code session survives a full context window. It replaces accumulated history with a shorter summary so work can continue. That is genuinely useful, and it has a cost that is easy to miss: you lose specifics, and the agent frequently re-reads files afterwards to recover what the summary dropped.

What compacting actually does

When the context window is full or close to it, the session cannot keep appending. Compaction resolves that by condensing what has happened so far into a summary, freeing room for the work ahead.

Recent turns generally survive in more detail than older ones, on the reasonable assumption that the near past matters more than the beginning of a long session. The result is a session that continues, with a compressed memory of how it got there.

What you lose

A summary preserves shape and discards specifics. In practice the casualties are predictable:

The visible symptom is a session that suddenly asks about something you already covered, or re-opens a file it had clearly read twenty minutes ago. That is not the agent being careless — the detail is genuinely gone.

The cost nobody counts

Compaction is often described as a token-saving feature. It is more accurate to call it a token-shifting one.

Producing the summary costs tokens. Subsequent requests are smaller, which saves tokens. And then the agent re-reads files to recover dropped specifics, which spends them again — sometimes more than the compaction saved.

That does not make compacting a bad idea. Being unable to continue is worse. But it does mean that frequent compaction is a symptom, not a solution. If a session compacts repeatedly, something is filling the window faster than the work justifies, and that something is being metered against your 5-hour window and weekly cap the whole time.

When to compact deliberately

The best time is a natural boundary — you have finished one task and are moving to something unrelated.

At a clean break, the detail being dropped is genuinely finished with, so the summary costs you nothing you needed. Mid-task is the opposite: you lose specifics you are about to need, and pay to re-read them almost immediately.

The related habit is to start a fresh session at those boundaries rather than compacting a very long one repeatedly. A session that has compacted several times is carrying a summary of a summary, and quality degrades in ways that are hard to notice from inside.

Reducing how often you need it

Everything that fills the window faster also makes you compact sooner. The main contributors are consistent across setups:

Practical mitigations: scope sessions to one task, do not route enormous build or test output through the agent when you can read it yourself, and break at task boundaries.

Past that, the leverage is in what reaches the model at all. The free hypermile-audit CLI reads your local transcripts and shows which files and commands are consuming the window — usually a short list doing most of the damage. Hypermile trims that noise reversibly before it is sent, so the window holds more of your actual work and compaction arrives later.

For the wider picture, see the context window explained and what Claude Code costs you, or download Hypermile.

Frequently asked questions

What does compact do in Claude Code?

It condenses the accumulated conversation into a shorter summary so the session can continue when the context window is full or close to it. Recent turns are generally preserved in more detail; older ones are compressed into a summary of what happened.

Does compacting lose information?

Yes, by design — that is the mechanism. A summary keeps the shape of what happened and drops specifics. Exact file contents, precise error text, and the details of earlier decisions are the usual casualties, which is why the agent often re-reads files shortly after a compaction.

Does compacting save tokens?

It reduces the size of subsequent requests, which helps. But the compaction itself costs tokens to produce, and the re-reading it triggers costs more. Compacting frequently is cheaper than being unable to continue, and considerably more expensive than not filling the window so fast.

When should I compact manually?

At natural boundaries — when you finish one task and move to an unrelated one. Compacting at a clean break costs you little, because the detail being dropped is genuinely finished with. Compacting mid-task is where the losses hurt.

How do I avoid compacting so often?

Reduce what enters the window. Keep sessions scoped to a single task rather than a whole day, avoid routing very verbose command output through the agent, and start fresh at task boundaries. If it still fills fast, measure what is actually consuming it — it is usually a small number of repeated reads and noisy commands.