Research-backed calculator guide

Claude Compaction API Cost: Reconcile Summary Calls, Cache Writes, and Context Savings

Calculate Claude compaction API cost by reconciling the summary iteration, prompt-cache writes and reads, and the future turns needed to reach break-even.

What counts as Claude compaction cost?

Anthropic’s compaction overview describes compaction as replacing older conversation turns with a server-written summary. On-demand compaction is a separate request: the application sends the conversation with a compaction parameter, receives a compaction block, removes the summarized messages, and sends the signed block at the start of subsequent requests ^{[1] [2]}. The block is a state representation, not a free local string manipulation.

The first accounting trap is the response shape. For on-demand compaction, the API can return stop_reason: "compaction" and report the work in an iterations array. Anthropic’s example shows a compaction iteration with input_tokens: 144 and output_tokens: 276, while the top-level input and output fields are zero ^[2]. Your ledger must therefore sum the billable iterations instead of reading only the top-level fields. A native compaction call that is missing from that ledger will make the post-compaction period look artificially cheap.

The second trap is treating the summary as the only new prompt. Once the old turns are replaced, the prefix that you choose to cache changes. Anthropic says prompt caching can cache the full prefix through a cache breakpoint, including tools, system instructions, and messages ^[3]. If a compaction block is used as a cache breakpoint, the next request may create a new cached prefix. That write has a different price from a later cache hit. A cache read is cheaper than ordinary input, but it is still a billable token class.

The third trap is confusing compaction with history truncation. A custom client-side summarizer, a server-side on-demand compaction block, threshold compaction, and context editing can have different request shapes and preserved content. This article’s calculation is for a Claude native compaction flow where the API returns a compaction iteration. If your application discards history locally without calling Claude, remove the summary-call term and model only the new input and cache behavior.

A practical break-even formula

Start with a ledger for one compaction boundary. Use tokens as integers and rates in USD per million tokens (MTok). Let:

• S be input tokens read by the compaction iteration.
• O be output tokens generated for the summary iteration.
• R be the cached prefix tokens retained after compaction.
• N be the number of future turns in the comparison window.
• A be new, uncached input tokens added per future turn.
• Y be output tokens generated per future turn.
• pB, pW, pR, and pO be base-input, cache-write, cache-read, and output prices per MTok.

For a conservative simplified comparison, assume the compaction input is ordinary base input, the summary prefix is written once to a 5-minute cache, and the remaining N - 1 post-compaction turns read that prefix from cache. Assume the un-compacted alternative can read the old S-token history from cache on each future turn. Then:

Cost(compact) = S × pB + O × pO + R × pW + (N - 1) × R × pR + N × A × pB + N × Y × pO

Cost(no compact) = N × S × pR + N × A × pB + N × Y × pO

The new input and generated output terms cancel when both paths produce the same future work. The estimated break-even turn count is therefore:

N = (S × pB + O × pO + R × (pW - pR)) ÷ ((S - R) × pR)

Round up to the next whole turn. This equation is deliberately narrower than a total-session forecast. It asks when the avoided repeated read of the old context pays back the compaction and new cache write. Add separate terms for retries, model changes, cache expiry, longer future messages, or rework caused by information lost in the summary.

Worked example: Sonnet 5.5 at a compaction boundary

The following example uses the published Sonnet 5.5 rates visible on November 2, 2026. Prices are USD per MTok. The model, token counts, and future-turn count are assumptions for illustration, not a quote for your account. Vendor pricing can change, and the API response should replace every estimate in production reconciliation ^[4].

The compaction setup cost before future turns is 0.3600 + 0.0300 + 0.0125 = $0.4025. The old history contains 175,000 more tokens than the retained prefix, so each future turn avoids approximately 0.175 × $0.10 = $0.0175 of cache-read cost. The formula gives:

N = (0.180 × 2.00 + 0.003 × 10.00 + 0.005 × (2.50 - 0.10)) ÷ ((0.180 - 0.005) × 0.10)

N = 0.4025 ÷ 0.0175 = 23.0, so use 23 future turns as the modeled break-even point.

At 10 future turns, the avoided old-history read is about $0.1800, while the compaction setup and new-prefix economics are about $0.4070 after the nine later summary-prefix reads. The simplified compact path is still roughly $0.227 more expensive before considering quality or latency. At 30 future turns, the avoided old-history read is about $0.5400, while the compact path’s setup plus 29 later prefix reads is about $0.4170. The simplified saving is about $0.123.

That is a deliberately modest result. It does not claim compaction is always cheaper at 23 turns. It assumes the old context would have remained a cache hit, the new summary prefix would remain readable, and both alternatives would do the same productive work. If the old prefix loses its cache hit because the application changes an earlier system or tool prefix, the no-compaction path can cost more. If compaction causes a missing detail and several repair turns, those repair terms can erase the token saving.

Sensitivity checks

Use a range rather than presenting 23 as a universal answer. With the same 180,000-token history and 5,000-token retained prefix, a 6,000-token summary increases output cost by $0.030 compared with the 3,000-token assumption and pushes the break-even estimate to about 25 turns. If the retained prefix is 20,000 tokens rather than 5,000, fewer old tokens are eliminated on each future turn, so the saving per turn is smaller and the break-even takes longer. If the application uses Anthropic’s 1-hour cache write for Sonnet 5.5 at the documented $4 per MTok rather than the $2.50 5-minute write, the new-prefix write is $0.020 rather than $0.0125 and the illustrative break-even rounds to about 24 turns ^{[3] [4]}.

A cache expiry is another boundary. Anthropic documents different 5-minute and 1-hour cache durations and notes that a longer-lived write has an additional cost ^[3]. If a future turn arrives after the selected TTL, add a new write to the compact path. If the un-compacted path also misses, add that write to the comparison path too. Do not silently treat every input token as a cache hit merely because a previous request had the same conversation.

For an operational estimate, run three cases: low, base, and high. Vary the compaction input tokens from recent usage records, summary output from usage.iterations, retained-prefix size from the actual request, future turns from observed session behavior, and cache-hit rates from response usage. The LLM cost calculator can hold the scenario-level arithmetic, while the AI token cost calculator is useful for checking input, output, and cached-token unit conversions.

How to reconcile the API response with an invoice

Capture the compaction response and the subsequent ordinary responses as one boundary-aware ledger. Store request ID, model, timestamp, whether the request was a compaction iteration, input tokens, output tokens, cache-creation input tokens, cache-read input tokens, and any service or geography multiplier that applies to your deployment. Preserve the raw response because field names and beta behavior can change.

For native compaction, sum the usage.iterations entries. Do not add the top-level fields a second time if those fields are already represented by iteration records. For later messages, separate ordinary input from cache-read and cache-creation fields. Anthropic’s prompt-caching documentation shows a response with input_tokens, cache_read_input_tokens, cache_creation_input_tokens, and a nested breakdown of 5-minute and 1-hour cache creation ^[3]. Those fields let you replace the example’s assumed R and rates with actual quantities.

Then join the usage ledger to the provider invoice by the same model and billing period. A good reconciliation has a row for the summary call, rows for continuation calls, and a variance column for rate changes, rounding, credits, or marketplace invoicing. The AI API invoice reconciliation calculator is the appropriate companion when the invoice total does not match a simple token multiplication.

Keep provider facts and business values separate. Anthropic’s USD rates are vendor pricing observations. The value of avoiding a restart, preserving a user’s task state, or reducing an engineer’s repair time is an internal estimate. A break-even in token dollars does not prove a break-even in engineering dollars, and it says nothing about quality unless you separately measure lost-detail incidents and rework.

When compaction is likely to pay back

Compaction is more likely to pay back when many turns remain after the boundary, when the summary is small relative to the old history, and when the post-compaction prefix is cacheable. It is also useful for staying within a context limit, even when pure token savings are not the goal. Anthropic’s documentation positions on-demand compaction as a way for an application to control when a conversation is summarized and then continue from the returned block ^{[1] [2]}.

It is less likely to pay back before a short session ends. It is also risky when exact old strings, documents, images, tool results, or citations are needed later. Anthropic notes that images, documents, uploaded content, and fetched URLs inside summarized messages are gone once the block replaces them ^[2]. If the next step needs one of those artifacts, preserve or re-upload it and include that cost in the comparison.

Prompt caching and compaction are complementary, not interchangeable. Caching lowers the price of carrying a stable prefix; compaction changes the prefix and can require a write before subsequent reads. That is why the calculation must show both. For a broader comparison of provider denominators and rate-card assumptions, see the model pricing comparison guide.

FAQ

Is Claude compaction free?

No. Native compaction is a billable summarization call. Anthropic says the summarization call is billed and rate-limited like another request, and its usage is reported in the compaction entry of usage.iterations ^[2]. A local history deletion without a summary call is a different operation and should be modeled separately.

How do I calculate Claude conversation compaction cost from the response?

Read the usage.iterations array and sum the input and output tokens for entries whose type is compaction. Multiply those token classes by the applicable model rates, then add cache creation and cache-read charges from the continuation requests. Do not rely only on top-level input_tokens and output_tokens, because the native compaction example reports zero in those top-level fields ^[2].

Does prompt caching make compaction unnecessary?

Not necessarily. Prompt caching can make repeatedly carrying a stable history cheaper, but every cache-read token still has a price. Compaction replaces the old prefix with a summary, which can reduce the number of tokens read on future turns but introduces a summary call and a new cache-write event. Compare both paths over the number of turns you actually expect.

What is the Claude context summarization break-even threshold?

There is no defensible universal token threshold. In the worked assumptions here, the token-only break-even is about 23 future turns after a 180,000-token compaction boundary. A different model, cache TTL, summary size, prefix, future-turn count, cache-hit rate, or rework rate changes the result. Treat the number as a scenario output, not a product rule.

Is history truncation cheaper than native compaction?

It can be, because client-side truncation may avoid a billable summary call. It can also lose more state. Compare the retained-history input and cache behavior with the native summary path, and assign a separate estimate to any re-reading or recovery work. Do not label a truncation path “free” if it causes extra model turns afterward.

Which token fields should finance keep for reconciliation?

Keep request ID, model, timestamp, iteration type, ordinary input, output, cache-creation input, cache-read input, and the cache TTL or breakpoint policy when available. Preserve the raw response and the rate-card version used for the estimate. This makes it possible to explain why a compaction event, a cache rebuild, or a later cache miss changed the invoice.

Limitations and assumptions

This article uses rates and product behavior observed in the approved Anthropic documentation on November 2, 2026. Rates are in USD per MTok and may change. The worked example excludes taxes, credits, marketplace-specific units, regional multipliers, retries, latency value, and the cost of quality regressions. It assumes successful requests, a stable model, a cacheable prefix, and identical future work in both paths.

The SERP benchmark was a fresh English, United States web search for Claude context compaction cost and variants on 2026-11-02. The search interface did not provide a reliable sponsored-result label or a reproducible country selector, so the benchmark records the observed ten distinct HTTPS result pages and states that limitation. The inspected pages commonly explain mechanics, context growth, or workflow advice. The article’s contribution is narrower: an auditable billing denominator and a sensitivity-based break-even calculation. That observed opportunity is not a claim that any competitor is absent, that the query is easy to rank, or that publication will produce traffic.