Published 30 October 2026. Prices are Anthropic's list prices, read from the Claude pricing page on 30 October 2026. Claude Code, Claude API and OpenAI behaviour comes from each vendor's documentation, read the same day.
Compaction is cheap when the prompt cache is still warm and expensive when it has expired, and retrieving from the full session record beats it whenever the next step depends on an exact error message, file path or number. Alexander Yue, founder of Mainplane, measured both on a real session of roughly 400,000 tokens on Claude Opus 5.5 and posted the results on X on 29 October 2026: compaction took 38 seconds and $1.99 with an expired cache and 29 seconds and $0.17 with a warm one, while a new session told to retrieve from the old session's file took 15 seconds and $0.10 "to get back to work". At Opus 5.5 list prices as of today, reading 400,000 tokens from cache costs $0.08 and processing them uncached costs $1.60 to $2.00, so the input cost of the same summary request swings by twenty to twenty-five times depending on one thing: whether the cache survived the pause.
We agree with the part of his argument that matters most. The raw session record should never be thrown away, and an exact line beats a paraphrase of it. Where we part ways is scope. Retrieving from one session file solves one session; once there are fifty session files, the agent can find every line that ever mentioned the database URL and still not know which one is current, or which decision replaced which.
Compaction vs retrieval at a glance
| Compaction (summarise and restart) | Retrieval from the session record | |
|---|---|---|
| What happens when context fills | The model re-reads the whole session and writes a summary; a new context starts from the summary | A new context starts at once; the agent searches the old session and copies the lines it needs |
| Cost driver | Re-reading the full history: cheap from a warm cache, full price from a cold one | The tool calls the agent makes to search, plus whatever it pulls back |
| What survives | What the summariser chose to keep, in its own words | Everything, verbatim, if the agent thinks to look for it |
| Typical failure | The exact error string, path or number is gone | The agent does not know a constraint exists, so never searches for it |
| Best fit | A natural break between tasks, cache warm, discarded work genuinely finished | A cold cache, a resumed session, or work that depends on exact strings |
| Across many sessions | Each summary stands alone; no record of what changed | Every line is findable; nothing says which line superseded which |
What compaction actually does in Claude Code and the APIs
Compaction replaces the message history with a summary. In Claude Code, the summary comes from a separate request carrying "the same system prompt, tools, and history as your conversation, plus a summarization instruction appended as a final user message". Because that request shares the conversation's prefix, it reads the prompt cache when the cache is warm, which is why the documentation says a mid-session /compact "costs a fraction of what the context size suggests and spends most of its time generating the summary". After a break longer than the cache lifetime, "the summarization request reprocesses the full history as uncached input", and the docs name resuming an old session as the case where /compact costs the most.
What comes back after compaction is a reconstruction, not the old context. Claude Code's context window guide lists it: the system prompt, project-root CLAUDE.md, auto memory and any plan written in plan mode are re-injected from disk; up to five recently modified files that Claude read or edited are re-read, and a file over 5,000 tokens comes back only as a path reference; invoked skills return capped at 5,000 tokens each and 25,000 in total; path-scoped rules and nested CLAUDE.md files are "summarized away with everything else" until their trigger file is touched again. Everything else in the conversation, every tool result and every error message, exists afterwards only as far as the summary mentions it.
The Claude API now does the same on the server. On-demand compaction (beta header compact-2026-09-04) returns a summary block you send back in place of the messages it summarises; threshold compaction runs when input tokens reach a trigger you set, and "the API drops what came before the block", while the most recent turns stay word for word. OpenAI's Responses API offers server-side compaction through compact_threshold and a stateless /responses/compact endpoint, and its compaction item is, in OpenAI's words, "opaque and not intended to be human-interpretable". On OpenAI you cannot even read what was kept, which is the strongest argument there is for keeping your own copy of the record.
Compaction costs a fraction of the context when the cache is warm
The arithmetic below uses Claude Opus 5.5 list prices as of 30 October 2026: $4 per million input tokens, $5 for a five-minute cache write, $8 for a one-hour cache write, $0.20 for a cache read (Opus 5.5 and Sonnet 5.5 read at 0.05 times the input price, against 0.1 times on other models) and $20 per million output tokens.
| The summary request reads 400,000 tokens of history as | Price per million | Input cost |
|---|---|---|
| Cache reads (cache still warm) | $0.20 | $0.08 |
| Uncached input, no cache write | $4.00 | $1.60 |
| Uncached input written to a five-minute cache | $5.00 | $2.00 |
| Uncached input written to a one-hour cache | $8.00 | $3.20 |
The summary's output tokens come on top at $20 per million; a 5,000-token summary, for example, adds $0.10. Yue's post does not break his figures down, but his warm $0.17 and cold $1.99 sit inside these brackets, and the $1.82 gap between them is close to the $1.52 to $1.92 difference between reading 400,000 tokens at $0.20 per million and paying $4 to $5 per million for them. On Sonnet 5.5, at $2 input and $0.10 cache read, the same 400,000 tokens cost $0.04 warm and $0.80 to $1.00 cold.
Whether the cache is warm depends on how long you paused and on which time-to-live (TTL) the session uses. Claude Code gives the main conversation a one-hour cache on a Claude subscription within plan usage and five minutes on an API key or a cloud provider, and puts compaction requests in its "everything else" bucket, which defaults to five minutes. A pause of more than five minutes on an API key is enough to turn a $0.08 compaction into a $2.00 one. Our guide to prompt caching in coding agents works through the TTL choice and shows how Claude Code and OpenCode build their compaction requests on the parent's prefix so the summary reads the cache before the history is replaced.
Where the summary loses, and why exact lines win
A summary keeps what the summariser judged important at the moment it wrote it. Yue's complaint is the precise one: "The exact error message, the file path, the one number you needed is often gone." Coding work is unusually exposed to this, because so much of what matters is a literal string, such as a stack trace, a flag that has to be passed, a migration name or the port a service actually bound to.
Failure records are the other casualty. A summary tends to keep the goal and the progress and drop what was tried and did not work, so after compaction an agent can retry a write that already failed with a permission error, redo a step that already ran, or forget a constraint it learned halfway through the task. None of these show up as an obvious error; they show up as wasted turns and, occasionally, as a change applied twice.
Mainplane's answer is structural. Its Show HN post describes a Go agent harness in which each session is one append-only state file, and /continue starts a new session that greps the previous state file instead of summarising it. The README puts it as agents that "manage their own context by retrieving key information from other sessions", and the repository is MIT-licensed. Yue calls it "the bitter lesson applied to agent memory": give the model the full record and good tools, and let it decide what to bring back.
Where retrieval from the old session costs you
Retrieval moves the cost from one large summary request to many small tool calls, and the number of those calls is not fixed. A study posted to arXiv in August 2026, What Does Context Compression Cost an Agent? by Shuyu Liu, ran a tool-using agent in a deterministic planning environment with a 24-turn limit, across three models and two task regimes, and split tool calls into retrieval and execution. Compressing the agent's context raised retrieval calls in all six model-regime comparisons while task completion did not change significantly at 5x compression; for GPT-5.5, completion went from 80% to 85% while retrieval calls rose from 21.0 to 63.9. The effect was environment-dependent (ALFWorld showed no surge), but the lesson carries over: an agent that has lost state goes back to fetch it, and completion rates alone will not tell you what that cost.
The harder limit is that retrieval only finds what the agent thinks to look for. A summary at least puts the shape of the previous work in front of the model; a fresh session with "retrieve key context as you go" has to know that a constraint exists before it can search for it. The worst case for retrieval is the negative fact, such as "do not touch the staging database, it is shared with another team", which nobody greps for because nothing in the new task mentions it.
Dex Horthy, who is building HumanLayer, replying on X to a separate post about answering from primary sources, stated the condition for keeping any summary at all: it is worth having only "if it increases speed without reducing quality", and unless you are building evals specific to your codebase, the "simpler answer is live with a little speed hit and just go from source every time". That is the right default for code, where the source is always available and always current.
When to compact and when to continue and retrieve
Each approach wins at a different moment in a session, and the cost table and failure modes above decide which moment you are in.
- Compact when the cache is warm and the work is done. Run
/compactat a natural break between tasks, within the TTL, with a focus instruction such as/compact focus on the auth bug fix, and only when the context you are discarding is genuinely finished. Claude Code's own advice is the same: pick the moment yourself, before auto-compaction fires mid-task. - Rewind when you are abandoning a path.
/rewindtruncates back to a prefix that is already cached, so it costs a cache read and no new summary. - Start fresh and retrieve when the cache is cold. After a long break or when resuming an old session, a compaction pays full price to re-read history you may not need; a new session that searches the old transcript pays only for what it pulls back.
- Retrieve when the next step depends on literal strings. Debugging, migrations and anything involving exact configuration values should come from the record, not the summary.
- Check the cache before you choose. Claude Code's
/usageshows whether the main conversation's cache is warm right now, which tells you which row of the cost table you are about to pay. - Keep the transcript either way. Claude Code already writes every session to JSONL at
~/.claude/projects/<project>/<session-id>.jsonland keeps it after compaction, but it deletes transcripts after 30 days by default; raisecleanupPeriodDaysif the record has to outlive that. On OpenAI, where the compaction item is opaque, log the raw turns yourself.
What neither does across fifty sessions
Both approaches are answers to one question: how does an agent keep working once this session's context is full? A different question appears after a month of sessions, and neither answers it. Suppose the record holds fifty session files. Grep for the staging database URL and you may get several values, one from before a migration, one from a test, one that a teammate later changed. Every line is exact and none of them says which is current. Retrieval returns matches, not the order in which facts replaced each other, and a compaction summary is worse here, because each summary stands alone with no link to the one before it.
What the agent needs across sessions is a record of change: this value replaced that one on this date, for this reason, and the old one is still there if you need to know what it used to be. Vectorize made a similar point on 29 October in a Hindsight post on agent memory, arguing that when facts live in a memory store and not in the thread, "compaction costs you the turns and not the knowledge"; the same post cites an OpenBot tracker report that counted 177 memories across 17 agents, 15 of them contradicted and 31 stale. Keeping facts outside the thread is the easy half. Deciding which of two conflicting facts wins, and recording that decision, is the hard half.
Project files cover part of this today. Claude Code's CLAUDE.md and auto memory survive compaction because Claude Code re-injects them from disk, and our comparison of Claude Code, Codex and Cursor memory covers what each one keeps between sessions. A memory layer is the other option. Maximem Synap stores memories as discrete statements rather than transcript chunks, so it can notice when a new statement contradicts an old one, keep the old one linked to its replacement, and show where each memory came from, what it replaced and what it used to say. Whichever you use, the store needs regular maintenance, which is what our piece on agent memory consolidation covers: merging duplicates, superseding replaced facts and checking that the job did not break anything.
Keep the full record, retrieve exact lines within a session, and compact only when the cache makes it cheap. Then add the one thing a pile of perfect transcripts cannot give you, a record of which fact replaced which, because an agent on its fiftieth session needs that far more than an agent on its first.
Frequently asked questions
Is context compaction a mistake?
Not always. Compaction is cheap and reasonable when the cache is warm and the discarded work is finished: on a roughly 400,000-token Opus 5.5 session, Mainplane measured 29 seconds and $0.17 warm against 38 seconds and $1.99 cold. It is a poor choice when the cache has expired or when the next step depends on exact strings, because the summary paraphrases and drops literal error messages, paths and numbers. In those cases, starting a new session that retrieves from the old record was faster and cheaper in the same measurement (15 seconds and $0.10).
What does /compact cost in Claude Code?
The summary request re-sends the whole conversation. With a warm cache, Claude Code's docs say it "costs a fraction of what the context size suggests"; at Opus 5.5 prices as of 30 October 2026, 400,000 tokens read from cache cost $0.08. With a cold cache it reprocesses the full history as uncached input, $1.60 at the $4 input price or $2.00 if written to a five-minute cache. Output for the summary adds $20 per million tokens.
Does Claude Code delete the conversation when it compacts?
No. Claude Code stores each session as a JSONL transcript under ~/.claude/projects/ and keeps writing to it as you work. Compaction changes what the model sees; when you resume a compacted session, Claude continues from the last summary and the messages the summary covered are not loaded again. Transcripts are deleted after 30 days by default, which cleanupPeriodDays changes.
Is retrieval from the old session always cheaper than compaction?
No. Retrieval is cheaper when it replaces a cold compaction, but its cost scales with how many searches the agent makes, and a study on context compression found retrieval calls rose sharply (21.0 to 63.9 for GPT-5.5 in one setting) once state was lost. It can also miss constraints the agent does not know to look for. With a warm cache, compaction and retrieval cost about the same, and the decision comes down to whether you need exact lines.
Can you read what OpenAI's compaction kept?
No. OpenAI's documentation describes the compaction item as "opaque and not intended to be human-interpretable". It carries prior state forward in fewer tokens, but you cannot inspect or correct it, so keep your own log of the raw turns if you need an audit trail or exact retrieval later.
What is the difference between compaction, retrieval and memory?
Compaction shrinks one session by summarising it. Retrieval keeps the session record intact and pulls exact lines back when they are needed. Memory works across sessions: it keeps facts after the session ends and records when one fact replaces another, which neither compaction nor single-session retrieval does.
Sources
All retrieved 30 October 2026.
- Alexander Yue, post on X, 29 October 2026 (compaction and retrieval timings and costs on a ~400,000-token Opus 5.5 session).
- Mainplane, GitHub repository and README (MIT licence) and Show HN post.
- Dex Horthy, post on X, 30 October 2026.
- Anthropic, Claude pricing, Claude API compaction.
- Claude Code docs: prompt caching, context window, sessions.
- OpenAI, compaction guide.
- Shuyu Liu, What Does Context Compression Cost an Agent?, arXiv 2608.16370, August 2026.
- Vectorize, Your OpenBot Agents Forget Between Threads, 29 October 2026.
