Claude Prompt Caching Cost: Your Break-Even Worksheet

Claude prompt caching cost is a write-premium versus reuse calculation, not a blanket discount. With an unchanged prefix and successful hits, the five-minute cache becomes cheaper than sending that prefix uncached on the second request; the one-hour cache on the third. Those thresholds concern the reusable prefix, not the whole API bill. New input, output and additional tool charges still need their own ledger.

Pricing checked 14 October 2026. The examples below are calculated scenarios using Anthropic’s direct Claude API documentation—not measured benchmarks, account invoices or promises of production savings. This worksheet supports our 198-listing API pricing research; it does not repeat the provider rate-card comparison.

Claude prompt caching cost: record the actual rates first

Anthropic’s current pricing table lists five-minute writes at 1.25 times ordinary input pricing and one-hour writes at twice that price. Reads are model-dependent. The table lists a 0.05 multiplier for Sonnet 5.5 and Opus 5.5, 0.025 for Fable 5.1 and Mythos 5.1, and 0.1 for other models. An older “cache reads always cost 10%” spreadsheet therefore needs updating before it is reused.

This article uses Sonnet 5.5 as one explicit arithmetic example. Anthropic lists it in its current model overview; that listing establishes availability in the documented catalog, not adoption, quality superiority or suitability for your task. We are not recommending a model from price alone.

• Ordinary input: $2 per million tokens.
• Five-minute cache write: $2.50 per million tokens.
• One-hour cache write: $4 per million tokens.
• Cache read: $0.10 per million tokens.
• Output: $10 per million tokens.

These are the direct API table’s listed USD rates on the check date, before applicable modifiers or other charges. Do not transfer them to a different provider, region, processing tier or account contract without checking that route’s terms. This is API usage accounting, not a claim that a Claude consumer subscription pays for API requests. For broader budgeting context, see our inference-cost guide.

The break-even equation: count writes and hits separately

Let P be reusable prefix tokens, B the ordinary input price per million, w the cache-write multiplier, r the read multiplier, and H successful reads following one write. Assume the prefix has the same length throughout and every later request hits that entry.

Uncached prefix cost = P × B × (1 + H) / 1,000,000
Cached prefix cost   = P × B × (w + H × r) / 1,000,000
Caching is cheaper when H > (w - 1) / (1 - r)

For the Sonnet example, w = 1.25 or 2 and r = 0.05. One successful read repays the five-minute write premium; two successful reads repay the one-hour premium. The first request is the write, so “two reads” means three total requests, not two. These integer thresholds also hold for the other read multipliers listed above, but the dollar savings differ.

Prefix size and base price cancel from this simplified threshold, not from the actual spend. A large reusable document can justify instrumentation more readily than a tiny prefix even when both have the same break-even request count. And if your requests never hit, repeated writes make the prefix more expensive—not less. A marker in the request is an intention to cache, not evidence that caching happened.

A ten-request worksheet: prefix savings versus total savings

Suppose ten requests share a 20,000-token prefix. Each also sends 1,000 new input tokens and generates 500 output tokens. These are scenario assumptions, not observations. Assume nine cache hits after the initial write, no extra tool fees, and identical suffix and output counts across all alternatives.

Without caching, each prefix costs $0.040 and ten prefixes cost $0.400. A five-minute write costs $0.050; nine reads at $0.002 each add $0.018, making cached prefix spend $0.068. A one-hour write costs $0.080; the same nine reads make prefix spend $0.098.

The changing input adds $0.020 across ten requests. Output adds $0.050. Add both before describing the total saving:

• No cache: $0.400 + $0.020 + $0.050 = $0.470.
• Five-minute cache: $0.068 + $0.020 + $0.050 = $0.138, approximately 70.6% less.
• One-hour cache: $0.098 + $0.020 + $0.050 = $0.168, approximately 64.3% less.

We calculated these values programmatically using decimal arithmetic. We did not send the ten requests to Claude or measure latency. The percentages describe this particular ledger; they are not a universal cache discount. Make output longer, shrink the reusable prefix or add billable tools, and the percentage reduction in the total bill changes. Our API-cost accounting guide covers that wider distinction.

For a spreadsheet, create columns for model, rate-check date, platform, prefix tokens, ordinary input rate, write multiplier, read multiplier, writes, successful reads, new input tokens and output tokens. Keep prices per million throughout. Store the actual rate alongside the model identifier so a future catalog update does not silently reprice an old experiment.

Choose retention from request timing, not session length

The prompt-caching documentation says the default lifetime is five minutes, refreshed when cached content is used without a separate refresh charge. The read itself remains billable. Crucially, the lifetime runs from the start of the request that writes or reads the entry, not from the end of its response. Long generation time consumes part of the interval available for reuse.

Consider three requests starting at minute zero, minute ten and minute twenty, all sharing the same prefix. In a modeled expiry case where the five-minute entries are no longer available at each later request, three five-minute writes cost $0.150 for the prefix. One one-hour write plus two reads costs $0.084. Three uncached prefixes cost $0.120. Here the longer window wins; the five-minute configuration loses. These are arithmetic cases, not a timing guarantee or a measurement of cache eviction.

Conversely, frequent successful reads can keep the shorter-lived entry refreshed. A conversation lasting an hour does not automatically require an hour-long cache. Examine gaps between request starts for each reusable prefix, not just how long a user keeps a browser tab open. Group by workspace, model and prefix identity rather than counting unrelated requests as reuse.

Do not send artificial keep-alive requests simply because refresh sounds free. A request can incur read, new-input, output or other charges. Compare the complete keep-alive policy against paying for a later write; include idle traffic in the same worksheet.

Build a stable prefix, then prove that it hits

Anthropic documents exact matching for the cached prompt segment. Put reusable instructions, relevant stable context and tool definitions before changing request content. For explicit caching, mark the last stable content block—not a block containing a fresh timestamp or arbitrary question. The boundary is an implementation decision, not merely a billing flag.

The documentation’s minimum-length rules currently specify 512 tokens for Sonnet 5.5. Other models have different thresholds. A below-threshold prompt can be processed without caching and without an error. Never interpret a successful HTTP response as a successful cache write. Do not pad a short prompt solely to chase a discount without accounting for the extra tokens and whether the added context is useful.

For parallel traffic, the same documentation says an entry becomes available after the first response begins. Launching many identical requests simultaneously does not establish that all but one will read the cache. The writer must have made the entry available before a later request can reuse it. Similar ordering uncertainty applies to asynchronous batches; this worksheet assumes ordinary requests, not guaranteed batch hits.

Stable prompt construction also matters independently of caching. Our prompt-engineering analysis explains why structure remains part of the system, rather than something a cheaper token rate replaces.

Account for misses, retries and mixed retention windows

Read the response’s usage record. Anthropic’s Messages API reference and cache-performance section separate ordinary input, cache creation and cache reads. Ordinary input_tokens is not the entire prompt when caching is used. Total input is ordinary input plus cache-creation input plus cache-read input.

Request USD = (ordinary_input_tokens × base_input_rate
+ five_minute_write_tokens × five_minute_write_rate
+ one_hour_write_tokens × one_hour_write_rate
+ cache_read_tokens × read_rate
+ output_tokens × output_rate) / 1,000,000
+ applicable separately billed charges

When both retention windows are used, use cache_creation.ephemeral_5m_input_tokens and cache_creation.ephemeral_1h_input_tokens to separate the write counts. The aggregate cache_creation_input_tokens equals their sum: do not charge the aggregate again. For growing conversations, a response can read an older prefix and write a newer segment, so a binary “hit/miss” label loses useful information.

As a simpler planning model, suppose every request either reads the entire fixed prefix with probability p or writes it again. Expected prefix cost relative to uncached input is p × r + (1 − p) × w. For Sonnet 5.5 it falls below one when p exceeds approximately 20.8% for five-minute writes or 51.3% for one-hour writes. These are calculated steady-state thresholds; they exclude cold-start effects, partial hits, growing prefixes and uncached fallback. Use token-weighted observed charges for the real decision.

Log every attempted call that produces billable usage, not only the final accepted answer. Retries and agent loops can change both the number of writes and output spend. Record request identifiers and returned usage, then reconcile with provider billing. Where a failed request leaves charges unknown, label that gap rather than silently treating it as zero.

A rollout checklist before changing production traffic

1. Choose one genuinely repeated workflow and document its stable prefix.
2. Copy the exact platform/model rates, currency and check date into the worksheet.
3. Estimate request-start gaps and select a retention policy to test.
4. Check the model’s minimum token length and explicit cache boundary.
5. Run a controlled trial with the same task and output constraints; retain all usage records.
6. Calculate total cost per completed task, including retries, output and tools. Check answer quality separately.
7. Compare predicted writes and reads with actual token counts before expanding the rollout.

The decision: use the write/read worksheet to identify a plausible saving, then use the usage ledger to establish whether your workload realizes it. Start with one stable prefix and a dated rate card. Do not turn a prefix-level discount into a whole-bill promise, and do not select a longer retention window without showing which otherwise-expired reads justify its premium.