What does context compaction actually keep?

Measured over 43 real compactions: 77% of the decisions survived the summary and 0.2% of the commands that had been run. Reasoning is summarised; the exact invocations, error text and edited spans are dropped.

Can I recover what a compaction dropped?

Yes, if the full transcript is still on disk. Harnesses write the whole session to a log file; the compaction only shortens what is in the model context, not what was written.

How do I stop losing work to compaction?

Index the transcripts and let the agent search them, so the summary stops being the only copy. Indexing before compaction runs keeps the session searchable even after the window collapses.

What compaction drops, and how to get it back

the summary keeps the reasoning and drops the work

A long session compacts: the harness replaces earlier turns with a summary so the window keeps fitting. The session continues, the agent sounds like it remembers, and the specific thing you will need in twenty minutes is already gone.

What survives, measured

Over 43 real compactions taken from one machine's history, comparing each summary against the full transcript it replaced:

77% of the decisions survived — the conclusions, the "we went with X because Y".
0.2% of the commands that had actually been run survived.

The method, the corpus and the script are in the repository under benchmarks, and the ratio holds across harnesses because they all summarise prose the same way.

That split is the whole problem. A summary is written in the language of intent, and the things that cost you an afternoon are not intent: the invocation with the four flags that finally worked, the error text you pasted, the exact span an edit replaced, the path of the file that turned out to matter. Ask after a compaction and you get a confident paraphrase of the plan with none of the parts you would have copied.

What compaction does not touch

The transcript. Compaction shortens what is in the model's context; it does not go back and rewrite the log the harness has been appending to since the session opened. Every command, every tool result, every edit is still on disk — see where each agent keeps it.

So "lost to compaction" is a retrieval problem, not a data-loss problem. The work is there; nothing reads it back.

Getting it back

Two moments matter, and they are different.

During the session

Index before the window collapses. Claude Code exposes a PreCompact hook that fires just before summarising, which is exactly when the full transcript is still complete and still the current session's. deja install --auto wires that hook, so the session that is about to be summarised is searchable a moment later — including the parts the summary is about to drop.

Afterwards

Ask for the specific thing rather than the story:

deja how "go test"          # the invocation this project actually uses, with its flags
deja fix "pq: too many connections"   # what was run after this error, where it stayed fixed
deja blame internal/index/ingest.go   # which sessions discussed this file, and what they decided

Those three questions map onto exactly what a summary drops: commands, failures and file-level decisions. With recall wired in, the agent asks them itself — before it runs a command, after one fails, and when a prompt matches earlier work.

What this does not fix

Compaction is not a defect to be switched off. The window is finite, summarising is the right response, and a memory layer does not change that — it stops the summary from being the only copy. If the harness never wrote the session to disk, none of this applies, and the answer really is gone.

Why agents forget between sessions · Where the transcripts live · Getting started