Compaction kept all 64 planted values, across 24 compactions

Auto-compaction is the most complained-about thing in Claude Code. The complaint is specific and it is everywhere: compaction “discards raw detail”, loses “specific variable names, exact error messages”, leaves the agent working from “a lossy approximation of what it knew seconds before”.

This site has already measured when compaction fires and when it fails outright. What survives a successful one was the open half.

Eight arbitrary values were planted at spaced turns across a long chained session, the context was driven past the compaction threshold, and then every value was asked back with files explicitly off-limits.

64 of 64 came back. Across 24 compactions.

Arm	Runs	Compactions per run	Values recalled
Dense bulk	4	4	32 of 32
Sparse bulk	4	2	32 of 32

Why the values are nonsense

QUOKKA-7741. Port 62841. wisteria-vole. /etc/frobnitz/main.yaml.

A model can infer that a retry limit is 3. It cannot infer that it is 17. Every planted value is arbitrary enough that producing it exactly means it was retained, not guessed. That is the whole reason the test means anything, and it is the same control this site uses to prove a payload actually arrived.

The harder arm is the one that matters

The obvious objection to a clean result here is that the bulk filling the context was compressible. If the surrounding material is one sentence repeated a thousand times, a summariser can throw it away and keep the interesting bits, and eight short values are trivially the interesting bits.

So there are two arms with identical planted values and identical structure, differing only in what competes for room in the summary:

• Sparse: one sentence repeated. 35,840 bytes compresses to 284 under gzip -9, 0.79%.
• Dense: log lines each carrying distinct timestamps, component names, byte offsets, paths, error codes and durations. The same 35,840 bytes compresses to 8,971, 25.03% — 31.7 times less compressible, and all 257 lines were distinct.

The dense arm needed four compactions per run against the sparse arm’s two, so it was demonstrably working harder. It still returned every value.

The mechanism, from a round that is not one of the eight

Compaction summaries are written to the session file, so they can be read directly rather than inferred. In an earlier exploratory round on 2.1.227, one session compacted six times, and each successive summary carried every value planted so far, verbatim and in backticks: three of eight in the first, then four, five, six, seven, and all eight in the sixth. The value planted on turn zero was still there after all six.

That session is not one of the eight scored runs below, which compact four times in the dense arm and twice in the sparse. It is published separately in the corpus as mechanism_evidence_2_1_227, with the per-summary counts, precisely so this paragraph is checkable rather than taken on trust.

On that evidence, compaction is not throwing these values away. It is explicitly writing them down.

What this does NOT show, which is most of it

It does not show compaction is lossless. It shows that short, discrete, explicitly stated values survive. The complaint people actually make is usually about something subtler: the reasoning behind a decision, a constraint mentioned once in passing, the shape of an approach that was rejected and why. None of that is tested here, and none of it is the same kind of thing as port 62841.

The competing content is log-shaped, not conversational. Real sessions are full of code, argument and half-finished decisions, which is a different summarisation problem from a wall of structured log lines, however high-entropy.

The compaction window was forced to 100k using --autocompact, which 2.1.228 accepts as auto or 100k–1M. That deliberately separates what compaction does from when it fires, and it makes the mechanism cheap enough to run 24 times. It is not the default trigger point.

If your experience is that compaction loses things, this result does not call you wrong. It narrows where the loss can be: not in discrete stated facts, which survive, but somewhere else.

Controls

Positive control. A short session that never compacts recalls 8 of 8. Without that, a zero in the long arms would measure a broken harness rather than compaction. A strong result needs the pipeline proven on the easy case.

Compaction actually fired, and the detector was validated in both directions. It is read from the status event carrying compact_result, and checked against the compaction markers written into the session transcript: it reported none when the transcript held none, and reported compaction when the transcript held six (that being the same 2.1.227 session cited above, not one of the eight scored runs). A run where compaction never fired is recorded unscored rather than counted as “no loss”.

The disk confound was checked and cleared. If the model had written the values to a file it could have read them back, and the result would mean nothing. It wrote nothing: no files beyond the supplied bulk, and none of the planted values appear anywhere on disk. Recall came from the conversation.

Isolation on every run, --setting-sources project, asserted onto the command line rather than assumed.

Every scored run, the positive control, the bulk statistics and the 2.1.227 mechanism evidence are published in compaction-survival.json.