The summary kept the shape of it. Not the content.
“About 40 minutes in, compaction fired and the summary said ‘user provided DOM markup’ but the actual content was gone.” That is the pattern, verbatim, from someone watching it happen live. Not “the AI got confused” — the record of what was actually pasted, gone, replaced by a five-word description of the fact that it once existed.
The same shape repeats at every grain size. The exact wording of an error message becomes “an error occurred with the config.” A specific variable name generalizes into “a variable.” A dead end you spent twenty minutes ruling out — and the reason you ruled it out — collapses to nothing, so the next version of you is free to try it again. The summary isn’t wrong. It’s just a different, thinner document than the one it replaced.
Most of what's in the window is tool output — and it's the first thing cut.
A conversation’s context isn’t mostly chat. One technical breakdown of a real Claude Code session measured the split directly: tool results — file reads, grep output, and the like — made up 68% of everything filling the window, tool-use inputs another 23%, user messages 6%, assistant replies just 3% (external source, faafospecialist). Compaction is aimed at the biggest slice by construction — and today it deletes that slice outright rather than keeping a pointer back to where it came from, even though most of it (a file, a log, an index) is still sitting right there, re-fetchable.
- 68%tool resultsfile reads, grep output, command stdout
- 23%tool-use inputsthe calls that produced them
- 6%your messageswhat you typed
- 3%model replieswhat it said back
The other half of the mechanism is what compaction costs, not just what it drops. The pre-compact conversation was — ideally — a cached prefix, cheap to re-send turn after turn. The moment it’s replaced, that cache entry is dead. The new post-compact summary is a fresh prefix that hasn’t been cached by anything yet either. Both sides of the swap are cold. One developer who measured this directly: “calling compaction will eat about 3-5x the cold cache cost in usage ive found.” You don’t just lose detail. You pay full price, twice, for the privilege.
The three instincts, and where each one stops.
Assume the re-fetchable stuff doesn’t matter.Most tool results genuinely can be regenerated — reread the file, rerun the grep. The ceiling: current /compact keeps no reference to what it deleted, so nothing tells you which fifteen tool calls out of two hundred you’d need to redo, or that you need to at all, until the model confidently answers from a summary that no longer has the receipt.
Compact less often.Delays the problem without solving it — the ceiling is still the context window, a long enough session hits it regardless, and waiting longer between passes doesn’t change what gets dropped when it finally runs, only when.
Re-paste the important bits back in after compaction.Works for the one thing you remember losing. It doesn’t work for the thing you didn’t notice was gone — the dead end nobody thought to re-explain, the reasoning behind a decision three compactions back — because you can’t re-paste what you’ve also forgotten to miss.
Keep a pointer, not a copy — outside the transcript.
The pattern that actually holds up is writing the load-bearing content somewhere compaction doesn’t reach, and keeping only a reference to it in the conversation. The simplest version is a running notes file or CLAUDE.md: exact error text, the decision and why, pasted once, read back deliberately instead of carried as conversational weight.
One external prototype takes this further and automates it: instead of letting large tool results sit in the live context waiting to be summarized away, it writes them to disk immediately and leaves a reference in their place. Its own numbers, on real sessions: a 4.6MB / 277k-token session cut to ~46k tokens (an 83% reduction), a smaller 900KB / 47k-token session cut to ~9.6k (79%) — without discarding the original content, only where it lives (external source, faafospecialist).
It’s a single author’s prototype, not a shipped product, and it still ties the record to that one session’s lifecycle — you built and maintain the harness yourself. But it proves the direction: the fix isn’t summarizing better, it’s moving the record off the thing that gets summarized.
What a session looks like when there's nothing left to compact.
One measurement, from our own production telemetry — a live workload, not a benchmark. A single Claude session ran 11,232 turns without ever hitting the summarize-and-drop cycle. Each turn sent about 116 tokens of genuinely new input against roughly 445,621 tokens of already-computed context: 99.97% served from cache, not re-derived from a shrinking recap. There was nothing to compact because the record it would have compacted away was never held in the conversation to begin with.
| What was measured | The number |
|---|---|
| turns in one session | 11,232 |
| new input per turn | ≈ 116 tokens |
| already-computed context | ≈ 445,621 tokens |
| served from cache | 99.97% |
| where it's from | Vinculum production telemetry, 2026-06-09 — one live session, measured, not a benchmark |
If the record never lived in the transcript, there's nothing to drop.
Everything above is a workaround for one fact: the conversation is currently the only place the record lives, so compaction has to choose what to keep. A substrate moves decisions, errors, and reasoning into typed, addressable entries outside the transcript, and treats the conversation itself as disposable scratch space. Tool results can be dropped freely, because they were never the thing doing the remembering.
Compaction still happens under the hood when it needs to. It just stops being an event that costs you anything, because there’s nothing load-bearing left in the window for it to summarize away.
Common questions.
What exactly does /compact delete?
Mostly tool results. One breakdown of a real session found tool results (file reads, grep output, and similar) making up 68% of everything filling the context window — tool-use inputs another 23%, user messages 6%, assistant replies 3%. Compaction targets that biggest slice first, and today it deletes it outright rather than keeping a reference to fetch it back from.
Why does compacting cost more than it saves?
Because it produces two cache misses instead of zero. The pre-compact conversation was (hopefully) a cached prefix; once it’s replaced, that cache entry is dead. The new post-compact summary is a brand-new prefix that hasn’t been cached yet either. One developer measured it directly: “calling compaction will eat about 3-5x the cold cache cost in usage ive found.” You pay full price twice to get a shorter conversation.
Can I get the dropped content back?
Only what’s re-fetchable, and only if you know to re-fetch it. A file read can be re-read; a grep can be re-run. But /compact keeps no pointer back to any of it, so recovering means recognizing something is missing and repeating the original tool call — assuming the underlying state (a log, a diff, a search index) hasn’t already moved on.