实测Claude Code上下文窗口：61天数据揭示记忆注入与压缩真相

I run several projects alone with Claude Code, often with two or more sessions open at once. Each session starts with nothing from the previous one, and compaction replaces the history with a summary the product writes. Over the last two months I built a set of pieces around that, which I call Hipocampo, to decide what goes into the window of each session, at what moment, and how to check that it got in.

What it is

Everything uses native features: hook events, settings, the MEMORY.md index, CLAUDE.md, skills, subagents and compaction. Nothing installed, no MCP. The commit guards run in the git pre-commit hook.

The organizing idea is that each thing lives in one of three regimes:

• Resident: always arrives, before the first decision (a map loaded by hook, the memory index, a state file).
• Paged: only arrives if something opens it (CLAUDE.md in subfolders, docs, the memory files themselves).
• Interrupt: arrives when the command or the file touched matches a registered source, on that event and only on it.

What I measured

61 days of transcripts from this installation (190 main sessions, 918 subagent files), with a positive and a negative control and the population declared for every number.

0 injected recalls in 190 conversations. A memory only got in when the agent opened its file. 209 of 432 memories were opened at least once (a lower bound).

Compaction is aggressive. In one event in August, 96.6% of the context was removed (607,378 → 20,766 tokens), and 8 of my 36 messages from before the summary left no trace in it.

Three green instruments, 11% delivered. On Aug 13, the hook that loads my project map emitted 18,057 bytes and about 11% reached the model. The runtime said hook success, the script log said complete, the script's selftest passed 9 of 9. Hook output above 10,000 units per command goes to a file, and only a preview of about 2 KB reaches the model. The only check that caught it was comparing, byte by byte, what the script emitted with what the transcript recorded. The map now goes in 5 slices, each under the ceiling.

The compaction ceiling setting changed the shape of sessions. Until Sep 18, conversations went up to almost 1M tokens before the summary. Since Sep 21, 64 of 65 compactions happened at or below 365K.

A guard only counts after it has rejected a defect planted on purpose. On Sep 25, 52 of 74 guards had that proof. The rest are declared as debt.

How to build it

The article ends with the order I would follow, in 7 steps, each with the native feature it relies on and the red that proves it works. Every step ends by breaking the piece on purpose and waiting for the failure.

Limits

One operator, one installation. The study does not say whether the memory that arrives is correct or whether it was useful.

Links

• Full article (architecture piece by piece, the measurement bench, 33 figures, limitations): https://ksmit.com.br/en/blog/hipocampo
• Code (hooks as a settings example, the memory guards with their failing fixtures, the measuring scripts, memory and map templates; MIT): https://github.com/JhouCode/hipocampo

Written and tested on Linux with bash and python3. If you run the measuring scripts on your own transcripts, I'd like to know what number you get for injected recalls.