Measured Claude Code /compact Costs: $0.06 with Warm Cache, 9x Pricier Cold

How much does Claude Code's /compact actually cost? The official docs only say it "is itself a large request" without ever giving a concrete number. Someone ran a full measurement using 38 claude -p processes on a real 136k-token code session, breaking down the costs of three paths — cache hit, cache expired, and /clear — into clear figures. The conclusions are far more actionable than the documentation.

What the official docs say — and don't say

Claude Code's cost documentation acknowledges that /compact "reads the conversation it's summarizing, so compacting a large context is itself a large request," and that "/clear costs nothing when you want a fresh start rather than a continuation." Both statements are true, but neither gives numbers: how large is the request? Large in tokens or in dollars? And how much does the next turn cost after compacting?

The docs also link to the prompt caching page, adding two key mechanisms. When the cache is warm, the summarization request reads the entire prefix from cache, and "a /compact mid-session costs only a fraction of what the context size suggests"; after the cache expires, "the summarization request reprocesses the full history as uncached input." Meanwhile, after compaction Claude Code "re-reads up to five most recently modified files," and files over 5,000 tokens come back as path references only, without content. All of these rules were confirmed in the measurement.

Prompt caching is a mechanism in the Anthropic API: when multiple requests share the same prefix (system prompt, tool definitions, conversation history), the server can cache the computation of that prefix. If the next request hits the cache, those tokens are billed at a fraction of normal input price — for Opus 5.5, cache reads cost just 5% of input price, whereas normal input is $4/million tokens.

Two key cache properties shape the cost structure in this article. First, write cost: the first time tokens are written to the cache, the price is higher than normal input (about 1.25x), so the turn that just read in a large chunk of content is actually more expensive. Second, time-to-live (TTL): the cache lives about five minutes by default, and every hit refreshes the timer; once the TTL passes with no request, the cache expires and the next request must reprocess the entire history as uncached input. This is exactly the root of the "cold compaction is 9x pricier" finding here.

How the experiment was done

All test material was real code: 31–41 KB JavaScript files copied from open-source packages (Jest's transform build, Babel's scope tracker, argparse, browserslist, the Handlebars compiler, minimatch, picomatch). Each session first had Claude use the Read tool to read a set of files and describe each in ten words; reading one, four, or seven files corresponded to three scales: 34.2k, 84.7k, and 136.4k tokens.

The driver script used --input-format stream-json to write each message into the same claude -p process, waiting for the result event before sending the next message. All token data came from the request bodies themselves — with telemetry enabled, Claude Code writes each request and response to disk and marks via query_source which were compact (summarization requests) and which were sdk (main conversation). The --debug-file logs and response bodies matched for all 19 compactions, and the total_cost_usd deltas also agreed with calculations at Opus 5.5 list prices.

The /compact request with a warm cache

Context before compaction	Normal turn	Compaction cost	Relative to normal turn
34.2k	$0.0078	$0.037–$0.044	4.7–5.7x
84.7k	$0.019	$0.045–$0.046	2.3–2.4x
136.4k	$0.031	$0.056–$0.059	1.8–1.9x

At the token level it truly is a large request: it carries the entire conversation except the last short reply, plus about 2,000 tokens (the probing question, summarization instructions, a one-line token budget reminder), totaling 1.01 to 1.06x the summarized context. But in dollars with a warm cache it isn't large, because 136,275 of 138,344 input tokens were cache reads.

Breaking down the $0.0589 for the 136k compaction: $0.027 for cache reads, $0.023 for summarization output, $0.008 for 2,069 new tokens. Priced as uncached input, processing the same context would cost $0.545 — warm compaction is only 10% to 11% of that. At 34k the ratio rises to 27%–32%, because the instructions and summary themselves don't shrink with the session. Summary output also barely grows with scale: for compactions from 34k to 136k, postTokens landed between 1,549 and 1,977, and all six compactions fully listed every file read.

Cache breakpoints are the core concept for understanding compaction cost variance. The API lets you mark several positions in a request, and the server caches only content before the breakpoint. When building a summarization request, Claude Code places the breakpoint at "the last summarized assistant message."

Structurally the request is split into two parts: before the breakpoint is the cached prefix, billed at cache read price; after the breakpoint is new content, billed at normal input price. In a normal compaction, the last summarized assistant message is Claude's description of the files, so the file contents are before the breakpoint and enjoy cache pricing. But if you compact immediately after reading files, the summarized message becomes the one that called the Read tool, and the file contents fall after the breakpoint, billed at $4/million — that's the direct source of the $0.31 vs. $0.045 difference.

Cold cache: directly 9x pricier

After the cache expires (the test forced five-minute cache writes and went silent for 6.5 minutes), the situation is completely different.

Context before compaction	Warm compaction	Cold compaction	Cold uncached input	Cold/Warm
84.8k	$0.045	$0.326–$0.333	75,336	7.0–7.4x
136.5k	$0.056	$0.529–$0.542	127,019	9.0–9.8x

Only 10,466 to 11,447 shared system prompt and tool definition tokens still came from cache; everything else was billed at $4/million normal input. Cold compaction costs 96% to 99% of reading the entire context once at base input price.

An interesting comparison: after the same 6.5-minute wait, if you don't compact but just continue the conversation, at 136k the probe request rewrites 125,158 tokens into cache, costing $0.629; whereas cold compaction plus the next turn costs only $0.53–$0.54 plus $0.021–$0.023. In other words, after a long interruption, compaction is actually cheaper than pushing on — and subsequent turns read only ~15k instead of 136k.

The most expensive warm compaction: immediately after reading files

Here's a pitfall the docs never mention. If you send /compact right after a file-reading turn without any normal Q&A in between, the compaction cost jumps to $0.303–$0.315 even with a warm cache — 6.5 to 7.0x a same-scale warm compaction. Auto-compact (--autocompact) produces an identical request, $0.305–$0.307.

The reason lies in the request structure: in 18 of 19 compactions, the most recent assistant reply wasn't in the summarization request but was preserved via preservedMessages after the summary. The request's cache breakpoint lands on "the last summarized assistant message." In a normal compaction that message is Claude's description of the files, so everything including file contents hits the cache; on immediate compaction, what gets preserved is the file description, and the last summarized assistant message becomes the one that called Read, so ~68,000 file-content tokens sit after the breakpoint and are billed as uncached.

This distills into a positional rule, independent of manual or automatic: the uncached portion of a summarization request is everything after the last summarized assistant message. In a real session, that's the last step's tool result — which might be small (a test summary) or large (a big file read or long log).

What the turn after compaction costs

First request occurs	Token count	Cost	Probe answer
Fresh session	15,180	$0.034 (new prefix) or $0.003 (cache hit)	NONE
After /clear	15,303	Same as fresh session	NONE
Warm compaction, large files	14,254–14,923	$0.026–$0.032	File list
Warm compaction, small files	28,316–29,287	$0.143–$0.151	File list
Read handoff notes after /clear	15,301+	$0.044–$0.046 for two requests	File list

A request after warm compaction is even smaller than a fresh session, because two things aren't reinjected: the skill inventory (~6,805 characters) is no longer sent, and files over 5,000 tokens come back as a single-line note ("transform.js was read before the summary, but its contents were too large to include"). The system prompt and tools total 11,322 tokens read from cache, and the remaining 2,930–3,599 tokens must be written to cache, so the first turn after compaction costs a fixed $0.026–$0.032.

Small files are the opposite. When tested with 24 files all under 5,000 tokens (~90k tokens), after compaction Claude Code fully re-read the five most recently modified files, postTokens rose to 9,817 and 10,438, the next-turn request reached 28,316–29,287 tokens, wrote 17,000–18,000 tokens to cache, and cost $0.143 and $0.151 — more than twice the compaction itself ($0.054 and $0.072). The compaction bill may largely land after the compaction.

Auto-compact is the compaction Claude Code triggers automatically when context approaches the model's window limit, with a default threshold around 967K tokens. It invokes the same summarization logic as typing /compact manually, so its cost structure is identical; the only difference is that the trigger timing is decided by the system, not the user.

The practical implication: you can't avoid that expensive request by "not compacting proactively" — you just push the bill to the moment the system triggers it for you. The --autocompact requests tested here produced exactly the same cost at the same position as manual compaction ($0.305–$0.307). So proactively choosing when to compact — at a natural pause rather than right after pulling in a large tool result — is where real savings lie.

/clear really is free, and handoff notes don't pay off

All 13 /clear runs sent no API requests at all, took 0.05 to 0.34 seconds, and produced a conversation_reset event, a new session id, and total_cost_usd: 0. The documentation's claim holds precisely. The cost is continuity: all six probes after /clear answered NONE.

The common alternative is to have Claude first write a short handoff note, then read it back after clearing. Measured, this approach is more expensive than compaction at every scale:

Context before compaction	Compact + next turn	Write note + clear + read note
34.2k	$0.063–$0.072	$0.074–$0.075
84.7k	$0.075–$0.076	$0.097
136.4k	$0.087–$0.091	$0.119–$0.120

Handoff notes' advantage is that they barely depend on session cache. Reading the note into a new session stably costs $0.044–$0.046 per turn, whereas compacting a 136k session after a disconnect costs $0.53–$0.54. Writing the note produces 486 to 599 output tokens, fewer than a summary.

When compaction is worth it

Compaction's value comes from subsequent requests being smaller. Each subsequent turn reads the compacted context from cache instead of the full context, billed at $0.20/million for cache reads, so the savings per turn aren't huge. At 136k it saves about $0.024 per turn, while compaction plus the subsequent cache write costs about $0.058, so it pays back in two or three turns; 85k takes about four turns; 34k takes about fifteen. A turn with tool calls produces multiple requests, so in real work a large context pays back within one or two turns.

Based on this data, a few operational rules emerge:

• Use /clear when switching to unrelated work — it sends no request, and the next turn is at fresh-session scale.
• To continue the same work in a large session, compact at a natural pause — after a short reply, not right after a turn that pulled in a large tool result. At the same scale that's the difference between $0.045 and $0.31.
• If you're about to step away longer than the cache lifetime, compact or write notes before you leave. Compacting the same session after disconnecting is 9x pricier; continuing it is even pricier.
• Watch the size of recently read files. Files under 5,000 tokens come back in full after compaction, and five such files can make the first post-compaction turn cost more than twice the compaction itself.
• In small sessions, compaction barely pays back. At 34k, subsequent turns only drop from 34k to 14k, saving $0.004 per turn.

Payback period here refers to how long compaction's one-time expense takes to amortize through per-turn cache-read savings. The formula is: compaction cost ÷ per-turn savings. After compaction, each turn reads the compacted context (~15k tokens) from cache instead of the full context (136k); the ~121k-token difference at $0.20/million cache read saves about $0.024 per turn, while compaction plus the subsequent cache write costs about $0.058 — dividing gives 2–3 turns.

Note that "turn" here means API requests, not user-visible conversation exchanges. One exchange with tool calls may trigger multiple requests, so in real work large contexts often pay back within one or two turns. The smaller the context, the smaller the absolute savings after compaction, and the more turns needed to pay back — at 34k, only $0.004 per turn, requiring about fifteen turns.

Limits of what was measured

All tests ran on the same machine, same account, same model (Opus 5.5), and same version (2.1.289), in headless mode with stream-json input. Sessions were all short — one large read plus one or two probes; real sessions have more turns, edits, and tool calls, and summaries may be longer. Near the 967K default auto-compact threshold, /compact with focus instructions, and background pre-generated summaries were not tested.

One more thing worth noting: Opus 5.5's cache-read discount is 5% of input price, steeper than the 10% of most other models, so warm compaction here looks cheaper than it would on other models. Cold runs forced five-minute cache writes; the one-hour case is a calculated value, not measured. All dollar figures are list-price estimates; under a subscription plan what actually constrains you is your plan quota, which wasn't measured.