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

deja install --auto wires the pre-compaction hook wherever the host has a compaction event: Claude Code, Codex, TRAE CLI, CodeBuddy, WorkBuddy, Muse Code, opencode, Kilo CLI, Cline CLI, Copilot CLI, VS Code Copilot Chat, Qwen Code, Kimi Code, Grok Build, Cursor CLI, pi, omp, Senpi, gajae-code, prime-agent, OpenClaw and DeepSeek Harness, Hermes through its memory provider, and Gemini CLI on the next prompt. The session is read by the same parser that indexes it, found by the id and the transcript the host names. When the host supplies them, deja reads it as the compaction starts and keeps what the summary is about to drop: the task, the conclusions, the files, the commands — each marked [passed] or [failed] from the harness's own exit status or the output recorded after it — and what a turn said was still open, recognised by the label a line opens with in either language. The next hook for that same session and workspace hands it back once, inside 4 KB. A last line says whether the repository moved: unchanged, with the branch, or changed since the commit it was captured at, which is the difference between a conclusion you can still act on and one that needs re-checking. The agent does not need to write a checkpoint.

deja stats reports the raw tool calls before the first edit after compaction, with incomplete observations kept separate. See the compaction reference for capture limits and privacy controls.

Afterwards

Ask for the specific thing rather than the story:

deja wip                    # what the last session here was doing: task, files, last command
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 questions map onto exactly what a summary drops: the task in flight, 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

Found this useful? Star deja-vu on GitHub.