Claude Code auto memory tokens, measured on one real machine.

Most of the writing on this so far repeats the line that auto memory's load cost is negligible, a few hundred tokens. That is true on day one. It is not true on month nine, when Claude has been saving entries to your global MEMORY.md every time you correct it and the file has crossed the 200-line cap without you noticing.

What follows is one measurement on one real machine, in the order we did it. The point is the shape, not the specific numbers: your MEMORY.md is smaller or larger, your truncation tail is shorter or deeper, but the cost structure is the same and the questions worth asking are the same.

1. Where the auto memory lives on disk

Claude Code stores per-project auto memory under ~/.claude/projects/<slugified-absolute-path>/memory/. The slug is just the absolute path with slashes replaced by dashes. There is one global directory whose slug is just the user home (-Users-matthewdi on this machine); every other project gets its own.

That is 1,135 lines in the index and 83 topic files in the same directory. The index is what gets injected into the system prompt at session start. The topic files are bodies Claude reads on demand when the index entry looks relevant to the task.

2. Shape of one memory entry

Two files. The index entry (one line, in MEMORY.md) and the body (a separate .md with frontmatter). The body lives next to the index but only loads if Claude decides to follow the link.

The body file referenced from the first index line:

On every turn the index loads, capped at 200 lines. The body loads on the turn Claude judges the entry relevant, costs its full file size in tokens (the frontmatter, the prose, the [[name]] back-links), and stays in context for the rest of the session.

3. The 200-line truncation, in numbers

The 200-line cap is documented; the implicit contract is that MEMORY.md is an index, not the memory itself. One line per entry, roughly 150 characters per line, even a few hundred entries fit in a few thousand tokens. The contract breaks the moment the index crosses 200 lines, because new save-memory calls keep appending to the file and old entries below line 200 stop being visible to Claude on session start.

The 935 lines below the cut on this machine are not a hypothetical tail. They are entries Claude wrote months ago, that Claude can no longer see, and that the next save-memory call will sit beneath. From an outcomes standpoint the index has silently rotted: the model is making decisions based on the top 200 lines, and the rotation order is purely chronological (newest at top, in this case), so the lines past the cut are the oldest reference material rather than the least relevant.

4. Per-turn token math

The same chars/4 heuristic Claude's CLI uses internally, applied to the head-200 byte count we measured. The formula is the same one our CLAUDE.md analyzer uses; the inputs are the only thing different.

Read the second-to-last line first. The same prompt-cache logic that flattens CLAUDE.md cost applies here: MEMORY.md sits in the same cached prefix, so a stable index drops the recurring per-turn cost by roughly 10x. The fastest way to bust the cache for both files at once is an ISO date or a "today is" string in the first 20 lines of either, which is the highest-impact finding our CLAUDE.md analyzer catches and the one the context-burn audit page walks through end-to-end.

5. How this differs from CLAUDE.md

The two files share a session, a cache prefix, and a turn count, but they are not equivalent. Here is the shape, side by side:

The practical upshot: if you have been auditing only CLAUDE.md you have been counting roughly half of your recurring per-turn config cost. The half you missed is the one Claude wrote for itself, and the one that grows without you doing anything.

6. A two-rule pruning pass

What we do on our own machines, manually. Neither rule is automated yet.

1. MEMORY.md never goes past 150 lines. A 50-line buffer below the 200 cut so the next save-memory call does not silently drop entries beneath the cut. When the index crosses 150, the lowest-signal entries (anything not touched in 60 days, anything Claude has not followed via [[name]] in the same window) get demoted from the index, or deleted outright if the body file is also unreferenced.
2. Global memory stays small; project memory carries the load. Anything that only matters in one repo lives in the per-project memory directory (~/.claude/projects/<slug>/memory/), where it only fires on turns inside that repo. The global index (~/.claude/projects/-Users-<you>/memory/) holds only entries that are genuinely cross-project: keychain patterns, default cards, account identities, things you actually want re-injected on every turn of every session.

Both rules are pruning rules, not size targets. The point is not to shrink the index for its own sake; it is to keep every line in the loaded 200 doing work, and to keep stale entries from sitting beneath the cut where the file keeps growing but Claude cannot see what is there.

7. Caveats on the measurement

A few things this analysis is not.

• It is not a tokenizer-accurate count. The chars/4 heuristic is the same one the CLI uses for the on-screen estimate; the tokenizer-exact count is a few percent off either direction. For decisions about a 5,420-token line item that is fine.
• It is not a cache-aware count. The per-turn 5,420 figure assumes a clean cache. In steady-state usage the cached prefix drops the effective per-turn cost by roughly 10x. The figure is the worst-case ceiling, not the typical bill.
• It is not a measurement of the per-topic follow-read cost. That is a session-level cost that depends on which entries the model judges relevant, which is task-specific. We measured 83 files; in practice Claude reads two to five of them on a typical task and zero on many.
• It is one machine. Your global MEMORY.md may be 40 lines or 2,000. The shape of the truncation behavior is the same; the specific dollar number is not.