One session, eighteen compactions, forty three days
This is a real session on this machine, session 786f192e. Each bar is one
compaction event: the moment the window filled and the model wrote a summary of everything so far.
Bar height is the size of the summary it produced. Click any bar.
Measure your own machine
If you use Claude Code, your transcripts are already on disk, one file per session. This counts how many times a context window filled up, got summarised, and was dropped. It reads local files and sends nothing anywhere.
grep -rho '"isCompactSummary":true' ~/.claude/projects | wc -l
Three failures that get treated as one
They have different causes and different fixes, and confusing them is why people reach for the wrong tool.
Long before the window is anywhere near full, the model gets worse at finding a specific fact inside a large context. The information is present. Retrieval over it degrades. This is why "just use a bigger context window" is not a complete answer, and why a 200k window does not behave like 200k of reliable working memory.
The fix is not compression. It is putting less in, and putting the right thing where the model will actually look.
The window fills. The model writes a summary of everything so far and drops the rest. That summary is written by the thing that is about to forget, and nobody reviews it before it becomes the only surviving record.
On the session above it happened eighteen times. Each new summary is written against a context that already contained a previous summary, so what survives to the end has been through compression more than once.
After a compaction, ask for a number from earlier in the session. You will get one, stated with full confidence, drawn from a summary that no longer contains it. The model is not lying. It is doing what it was built to do.
A degraded answer announces itself. A confident wrong one does not, and it gets repeated into reports, commits and posts before anyone checks.
The limit hits. Or the account switches, the tool changes, the machine changes. Nothing degrades gradually. It all goes at once, and none of it was broken.
The repo survives that. The code is in git, the commits are in git. What does not survive is the working memory: what was decided, what was already tried and failed, what is deliberately not being done and why. None of that is in the code, and all of it is expensive to rebuild.
What survives is not what you would want to survive
I expected a summary to hold on to the checkable detail and let the prose go, because prose is the part a model can regenerate and a file path is not. It does the opposite. This is every compaction event on this machine, paired with the context it replaced, matched on the set of distinct anchors so a path repeated forty times still counts once.
Worth saying plainly: summarisers dropping named entities is not a new discovery. It is documented in the abstractive summarisation literature back to at least 2021 (arXiv 2102.09130 on entity level factual consistency, 2307.02570 on named entity omission, and 2503.19114 on information preservation in prompt compression, all three opened and checked). What I could not find published is that effect measured on agent context compaction, on a live corpus, against an ordinary prose baseline. The effect is old. The setting is the part I am adding.
Paths are matched exactly, so one that survived in shortened form is counted as lost. 8% is a lower bound on the path information surviving, not an upper one.
Every approach worth knowing, and how good the evidence actually is
Compiled from an eight lens research sweep across papers, primary vendor documentation and shipping tools, with an adversarial verification pass over the load bearing claims. Ranked by evidence strength against usefulness to one developer on one machine, not by novelty. Click a row.
The mechanism, end to end
Three skills, because a fast save and a permanent record are different artifacts and one tool doing both would do neither. The loop runs continuously; the handover runs once, when you are leaving for good.
The design rests on one measured result. Bhabra 2007 found a durable written artifact retains 99% of information across five serial handovers, against 2.5% for re-narration. That is the whole argument for never building a snapshot from a previous snapshot, and the miner already rebuilds from source transcripts every time.
What a complete handover should carry
Derived by reading the formal protocols that had to specify this properly, A2A task objects, LangGraph checkpoints and the Letta agent file, alongside the clinical handoff literature. Then checked, field by field, against what my own skills actually emit. Click a row.
What the research changed, and what is now live
Five changes, all applied and verified. Each one is here because something was measured or opened, not because it sounded right.
One of these nearly did not happen. Editing the skill source did not make the hook live: the harness invokes a promoted copy elsewhere, so the edit verified clean and fired nothing. The system doctor caught it as a drift failure. Verifying that a write landed is not the same as verifying that the thing which runs is the thing you wrote.
What I built on top of it
Three skills, because the jobs are genuinely different. A fast save and a permanent record are not the same artifact, and one tool doing both would do neither well.
snapshot
Writes the working memory to disk as a deterministic manifest plus seven cards, and mines every transcript that touched the repo for the model's own compaction summaries. Cheap, runs constantly.
recall
Loads it on the other side and computes exactly what drifted while you were gone: commits since, branch changes, dirty files, services down. The arriving agent is told what changed rather than trusting a stale card.
handover
The slow one, for leaving an account for good. Strictly chronological, no skim, plus eleven mandatory sweeps over everything a session walk cannot see.
Live on this machine: 1,679 snapshots across 21 repos, 7,438 of them captured automatically at session end without being asked, and 758 kept forever as daily anchors.
The honest limits
This carries working memory, not judgment. A snapshot is only as good as the card written on top of it, and that card is written by a model that is also about to forget.
It does nothing about context rot inside a live session. It makes the loss at the boundary survivable. It does not make the window bigger.