It was right there an hour ago.
You’re deep in a task. The context bar creeps toward full, compaction fires, and the session keeps going — but thinner. It re-asks a thing you settled forty minutes ago. It “remembers” a decision but not why you made it. The specific error text you were chasing is now a vague paraphrase. Nothing crashed; the thread just went slack.
It is a common enough experience that people file it in the same words. One developer watching a live session: “About 40 minutes in, compaction fired and the summary said ‘user provided DOM markup’ but the actual content was gone.” Another, on a long build: “Implementation work is nearly impossible due to constant compacting.” The tool is doing exactly what it was built to do. That is the problem.
A summary keeps the answer and drops the work.
A model is stateless: each turn, the whole conversation so far is sent back to it, because that transcript is the only memory it has. As the conversation grows, it approaches the fixed ceiling of the context window. Compaction is the release valve — the model condenses the conversation into a shorter recap, and the older turns are dropped from the working context to make room.
The recap is prose, and prose is lossy on purpose. A summary’s whole job is to keep conclusions and shed detail: exact error strings become paraphrases, variable names generalize, the branches you explored and abandoned disappear, and the reasoning that led to a decision is compressed to the decision itself. From then on the model reasons against that thinner version of where it was. The forgetting isn’t a bug in the summarizer — it is what summarizing is.
The obvious workarounds, and where each one stops.
Everyone tries the same three things first. They’re worth naming, because each helps a little and then hits a wall for the same underlying reason.
Compact less, or never. You can delay it, but the ceiling is the window; a long enough session reaches it regardless, and near the top compaction can deadlock because it needs context to run. Going the other way is worse: compacting more often re-summarizes more often, and on a cold cache one developer measured it “eat about 3-5x the cold cache cost.”
A bigger context window.It raises the ceiling inside one session, but the record is still per-session, and a long window attends to its middle less reliably than its ends. It moves the wall; it doesn’t remove it — the longer version is here.
Paste yesterday’s decisions back in.This works for a handful of facts and then doesn’t scale — it is you doing the model’s remembering by hand, every session, and the gap returns the moment you stop.
Write it down somewhere the transcript isn't.
The common thread in everything that works: get the record out of the conversation. Anything durable and external survives a compaction because it was never in the working context to lose.
The simplest version is a file — a CLAUDE.md, a decisions log, a design doc the next session reads first. This is good practice, not a trick, and the field arrived at it independently: one developer notes that “preserving information in markdown files has proven more effective than relying on the compaction mechanism.” Starting a fresh session deliberately helps for the same reason: a clean session that reads a good brief beats a bloated one limping past its third compaction.
These have a ceiling of their own. Flat notes drift out of date, contradict each other, and stop being loadable once a project runs long enough. They genuinely help; they just don’t scale on their own — which is the whole reason the layer below them exists.
What a session looks like when the record lives outside it.
One measurement, from our own production telemetry — a live workload, not a benchmark. A single Claude session ran 11,232 turns without the summarize-and-drop cycle. Each turn, it sent about 116 tokens of genuinely new input against roughly 445,000 tokensof already-computed context: 99.97% of what it reasoned against was served from cache. Growth didn’t tax the session, because the standing record was addressable and lived outside the transcript — so there was nothing to compact away.
| What was measured | The number |
|---|---|
| turns in one session | 11,232 |
| new input per turn | ≈ 116 tokens |
| served from cache | 99.97% |
| where it's from | Vinculum production telemetry, 2026-06-09 — one live session, measured, not a benchmark |
Move the record of record, and compaction becomes a checkpoint.
A file-based note isn’t the opposite of a substrate — it’s a view a substrate can produce. The difference is where the record of record lives. Compaction has to summarize and discard because the transcript is the memory. A substrate keeps decisions as typed, addressable records and treats the transcript as scratch. When a compaction — or a fresh session — clears the working context, the record is untouched, and re-orienting is a handful of reads rather than a lossy recap.
That makes the failure mode a non-event: post-compaction recovery becomes the same operation as a cold start, and a stateless model can boot into continuity by reading a briefing instead of replaying a history. The compaction still happens. It just stops costing you the thread.
Common questions.
Does /compact delete my conversation?
Not as a file. It summarizes the conversation so far into a shorter recap and drops the older turns from the working context. The recap is what continues; from that point on the model reasons against the summary, not the original. Your client may still keep the full transcript in its history, but the model no longer reads it — so any detail the summary didn’t carry is, for its purposes, gone.
Is compacting less often the fix?
It buys time, not escape. The ceiling is the context window: a long enough session reaches it no matter how you pace things, and near the top you can even deadlock — compaction itself needs room to run. Compacting more often costs more, not less, because each pass re-summarizes. The durable fix is putting the record somewhere the window isn’t.
Do bigger context windows solve it?
They raise the ceiling within a single session, not across sessions, and a long window still attends to detail in its middle less reliably than at its ends. A bigger window moves the wall further out; it doesn’t remove it. See vs. a bigger context window.