Claude Prompt Caching: When Five Minutes Beats One Hour

TL;DR: Claude cache writes cost 1.25 times base input for five minutes or 2 times for one hour; reads cost 0.1 times on Sonnet 4.6 and 0.025 on Fable 5.1.^[1] In the Sonnet example below, five-minute caching becomes cheaper than uncached input on the second use, while one-hour caching needs a third use. These are calculated prefix costs, not measured application savings.

The real story isn't the discount on a cache hit. It is whether your application buys enough hits to repay the writes. A long prompt that changes before every request can turn an optimization into a surcharge.

Our Claude rivalry analysis explained why caching changes model economics. This guide takes the next step: calculate the purchase decision, choose a lifetime and inspect the bill. It uses Anthropic's documentation checked on September 20, 2026, not a claimed performance test.

Cover: generated editorial artwork using reusable printing plates as a metaphor. It does not depict Anthropic infrastructure or measured savings.

Price: Name the Model and Billing Route

Our worked example uses Claude Sonnet 4.6 on the direct Claude API, standard synchronous processing, global routing, and published USD rates. It excludes negotiated discounts, batch pricing, geographic premiums and paid tool charges.^[1]

Anthropic still lists Sonnet 4.6 as an available legacy model with the API ID claude-sonnet-4-6. This is an accounting example, not a recommendation to choose it over newer models.^[9]

Source: Anthropic pricing, checked September 20, 2026. These are vendor prices, not a cross-model performance comparison.

A write is its own billing category. Do not charge the same written token once at $3 and again at $3.75. Conversely, a cheap prefix read does not make fresh input or generated output cheap. Those remain separate costs.

The Fable/Mythos 5.1 exception makes a universal 0.1 multiplier wrong.^[1]

Break-Even: Count Successful Reuses After the Write

Assume an unchanged 6,000-token prefix, one initial write and successful reads thereafter. All requests use the same model and eligible cache, before expiration. The prefix costs $0.018 uncached, $0.0225 to write for five minutes, $0.036 to write for one hour, or $0.0018 to read.

For n total requests, let B be the uncached prefix cost, w the write multiplier and r the read multiplier. The calculated cost is:

Uncached: n × B
Cached:   B × [w + (n − 1) × r]
Caching is cheaper when n > (w − r) / (1 − r)

Hypothetical arithmetic using the published Sonnet 4.6 rates above. Each cached column assumes one write and all remaining uses are hits; no runtime measurements were performed.

At ten uses, prefix-only savings are 78.5% for five minutes and 71% for one hour. But add 1,000 uncached input tokens and 500 output tokens to each request: those add $0.105 across ten requests. Whole-request totals become $0.285 uncached, $0.1437 with five-minute caching and $0.1572 with one-hour caching. The prefix discount is not the invoice discount.

Sensitivity: The Price of Repeated Cold Starts

Keep the ten-request, 6,000-token example, but allow full-prefix rewrites. The following are hypothetical billing outcomes with no partial hits. Every request either writes the complete prefix or reads it.

Eight five-minute writes already erase the savings. The longer lifetime loses sooner: five one-hour writes and five reads cost $0.189. A larger hit discount cannot rescue repeated expensive writes indefinitely.

Compare candidates against the same accepted tasks, not merely the same request count. If a cheaper configuration needs another generation to repair its answer, include that attempt. Classify misses by expiry, changed content and deliberate model changes. Only the first category is directly addressed by buying more time.

Lifetime: Buy the Gap Your Workflow Actually Has

The cache clock starts when a request begins; generation consumes it. Hits refresh lifetime but remain billable.^[2]

Consider two requests starting eight minutes apart with no intervening reuse, assuming the five-minute entry has expired and the one-hour entry still hits. Five-minute caching costs two writes, $0.045. One-hour caching costs $0.0378. The longer lifetime wins that comparison, yet uncached input at $0.036 is cheaper than either.

That is the distinction most “use one hour” advice misses. The right comparison includes doing no caching. Use request-start gaps, not how long the user appears idle after an answer. Preserve a longer lifetime for reuse you reasonably expect, not for a theoretical future conversation.

When writes recur, replace the optimistic formula with B × (writes × w + reads × r). For a growing agent history, calculate each prefix segment separately. New content is not retroactively free because an earlier segment hit.

Decision Table: Choose Before Warming

This is an application policy proposal, not an Anthropic service guarantee.

Do not manufacture requests just to keep a cache alive. A maintenance read spends money and can create output or tool charges. Compare its full cost against the rewrite it might prevent, including the possibility that the user never returns. Our calculations exclude such warming traffic; add it explicitly if your application creates it.

Cache Misses: Inspect Structure Before Buying More Time

Sonnet 4.6's caching minimum is 1,024 tokens. Below it, marked prefixes run uncached without errors.^[2]

Use the token-counting endpoint for supported request shapes before assuming a document meets the minimum. Its estimate is not a billing receipt, and some server-tool inputs are unsupported.^[3]

Anthropic's beta cache diagnostics compares a request with a previous response ID to locate divergence. It is more useful than assuming every miss means expiry.^[4] Its tool-caching guide separately describes where to place tool breakpoints and which tool changes invalidate reuse.^[5]

Our recommendation: keep reusable instructions stable, place an explicit breakpoint before a changing suffix when appropriate, then verify the actual counters. Do not pad a weak prompt solely to make a dashboard's cache rate look impressive.

Accounting: Reconcile Reads, Writes and Everything Else

Total input equals cache_creation_input_tokens plus cache_read_input_tokens plus input_tokens. The nested cache_creation breakdown splits writes by lifetime.^[2]

For organizations, Anthropic's Usage and Cost Admin API provides billing reconciliation; individual accounts cannot use that Admin API. Preserve model, timestamp, request ID, token categories and billing settings alongside your own task identifier.^[6]

Batch processing offers a separate 50% pricing reduction, but asynchronous ordering means shared-prefix cache hits are best-effort. Recalculate with batch rates and observed writes rather than importing the synchronous table unchanged.^[7]

Claude Code also distinguishes included subscription usage from metered usage: its main conversation defaults to one hour within a subscription's allowance and five minutes for API-key or usage-credit billing. Other request categories can differ. Those defaults do not establish a conversion from API dollars to a subscription's remaining percentage.^[8]

Growing History: Charge Each New Segment Once

A second hypothetical workload sends four prefixes of 6,000, 8,000, 10,000 and 12,000 tokens. Assume five-minute caching, unchanged prior content, valid breakpoints, no expiry and full reuse of the preceding prefix. The first call writes 6,000 tokens; each later call reads the old segment and writes 2,000 new tokens.

The cached total is $0.0522 versus $0.108 for 36,000 uncached input tokens. Outputs and any additional uncached suffix remain excluded. Previously generated text entering a later prompt is now input; its earlier generation charge does not pay for this later processing.

A dashboard that assigns the read price to the entire latest 12,000-token prompt would undercount the new segment. Conversely, charging a complete rewrite on every turn would miss the benefit. Read the categories the API actually reports before concluding that a growing history is either free or prohibitively expensive.

Logging Pattern: Enough Evidence to Recompute

For a simple text-only response under our stated rates, this illustrative usage record yields $0.0258: $0.0018 reads, $0.0075 writes, $0.0015 fresh input and $0.015 output. It is fabricated for arithmetic, not captured from an API call.

{
  "model": "claude-sonnet-4-6",
  "usage": {
    "cache_read_input_tokens": 6000,
    "cache_creation_input_tokens": 2000,
    "cache_creation": {
      "ephemeral_5m_input_tokens": 2000,
      "ephemeral_1h_input_tokens": 0
    },
    "input_tokens": 500,
    "output_tokens": 1000
  }
}

Wrap such accounting in your own request record: start time, previous response ID, application prompt revision, billing route, completion status and accepted-task ID. Do not log credentials or raw customer prompts just to investigate cost. Missing counters should be marked unknown, not silently replaced with zero. Reconcile mismatches before turning a dashboard estimate into a savings claim.

The uncomfortable truth is that the biggest savings often come from predictable application behavior. Keep a useful prefix stable, choose lifetime from real reuse and reconcile the bill. Caching becomes a business advantage when its savings survive the whole workflow.

Last updated: September 20, 2026