Claude Code Compact: What Survives, With Counts From My Sessions
What /compact and auto-compaction keep, what they drop, and how often it happened across my own sessions on one Mac.
If an instruction you gave Claude Code an hour ago has stopped being followed, Claude Code compact may be the reason: the session was replaced by a summary, and the summary may not have kept it. You can trigger it with /compact, or it runs by itself near the limit. Across my own session transcripts on one Mac, 372 of 4,121 contain a compaction marker. The docs list what comes back afterwards and what does not.
Updated 2026-10-26. Docs quoted: what survives compaction and how Claude Code works, both fetched 2026-10-26.
What Claude Code compact does
Per the docs, Claude Code "compacts the conversation into a summary. The summary keeps your requests and key code snippets, but detailed instructions from early in the conversation may be lost." The same page says to "Put persistent rules in CLAUDE.md rather than relying on conversation history."
Two ways to steer it, both from the docs: run /compact with a focus, such as /compact focus on the API changes, or add a "Compact Instructions" section to CLAUDE.md. If one file or tool output is so large that context refills right after each summary, Claude Code "stops auto-compacting after a few attempts and shows an error instead of looping".
What survives compaction
Everything the docs list as reloaded comes from disk, and conversation detail is not on the list. Excerpt of the docs' table:
| Content | After compaction |
|---|---|
| Project-root CLAUDE.md and unscoped rules | Re-injected from disk |
| Auto memory | Re-injected from disk |
Rules with paths: frontmatter, nested CLAUDE.md | Reloaded on demand |
| Files Claude read or edited | Up to five re-read, most recently modified first; a file over 5,000 tokens comes back as a path reference |
| Invoked skill bodies | Re-injected, capped at 5,000 tokens per skill and 25,000 total; oldest dropped first |
| Background commands and background subagents | Keep running |
| Context that hooks added earlier | Summarized with the rest of the conversation |
The gap in that table is anything that lived only in the conversation. The memory docs say it directly: if an instruction disappeared after compaction, "it was given only in conversation" (or sits in a nested CLAUDE.md or path-scoped rule that has not reloaded). Their fix is to add conversation-only instructions to CLAUDE.md.
How often it happened to me
I counted compaction markers (the line a transcript file records when a session is summarized) in the main session transcripts on my Mac, excluding subagent transcripts. The table shows that most transcripts have no marker and a few have many; the numbers come from the files only, and I did not read their content.
| Measure | Count |
|---|---|
| Main session transcripts | 4,121 |
| Transcripts containing at least one compaction marker | 372 |
| Transcripts containing none | 3,749 |
| Transcripts containing five or more | 121 |
| Compaction marker lines | 4,920 |
| Distinct marker lines | 4,700 |
Most transcripts contain no marker. A small share compacted a lot: those 121 transcripts hold 4,512 of the 4,920 marker lines. Some marker lines are identical copies, so I would not read the total as 4,920 separate compactions. I did not check why they repeat. I did not break the counts down by task type, so I cannot say what makes a session compact repeatedly. My guess is long orchestration sessions, and it is only a guess.
The rule I follow because of it
I treat a session's context as something that can be lost, not as storage. I keep a rule in my global CLAUDE.md that reads: "Anything held only in an agent's context is lost at compaction, so treat it that way." In practice, in-flight work, decisions and known problems go into a document in the repository during the same turn they appear, with a pointer from the first place the next session will look. After a compaction I re-read that document before acting, not only the summary.
This follows the docs' own advice: content reloaded from disk comes back, conversation detail may not. The table also shows a limit: at most five files are re-read after compaction, so I keep the state in one short document and point to it from CLAUDE.md. I have not compared that against any other layout.
The docs also let you set when the automatic pass runs, with a window from 100K to 1M tokens. I use 200,000 and have no measurement that it changed how often I compact.
What I did not measure
I did not measure whether compaction made any answer worse, or how many instructions I lost to it. I have no per-session comparison of compacting early versus late, and no cost or speed numbers. The counts above describe how often it happens in my setup, which is long multi-session work. Yours may differ. For what else belongs in the file that survives, see what goes in CLAUDE.md; for running a command when a session is compacted, that is a hook: Claude Code hooks; and for showing context used all the time, Claude Code statusline.
Related: Claude Code Pricing: What Each Plan Includes and What It Costs and Claude Code Subagents: When One Beats Doing It Inline.
Keep reading
- Gemini CLI vs Claude Code: What I Can and Cannot Say From My LogsA correction first: none of my logged runs used Gemini CLI. Here is what the Gemini rows are, what the two tools' docs say, and a dated tally with its limits.
- Using Codex as the Read-Only Reviewer for Claude CodeNot a benchmark: Claude Code writes and orchestrates, Codex reviews. The split, the verdict contract, and one case where the gate said no.
- CLAUDE.md File: What to Put In It and What to Leave OutWhat a CLAUDE.md file costs, what the docs say belongs in it, and the size history of mine: 3,639 words, then 512, then 9,555.