# Claude Prompt Caching: When Five Minutes Beats One Hour
**Plutonous** | September 20, 2026 | 10 min read
> Calculate Claude prompt caching's break-even point, choose a TTL from actual reuse, and diagnose misses without confusing API savings with subscription limits.
Tags: Claude, Anthropic, Prompt Caching, AI Pricing, API Economics, AI Agents, Developer Tools, Cost Optimization
---
**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](/news/claude-opus-51-rumors-astra-competition) 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.
### Why This Matters Now
A cache is an investment in future reuse. Budget its first write, likely expiration and changing context before treating the advertised read price as your average input price.
*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]
| Billing category | Published Sonnet 4.6 price per million tokens |
| --- | ---: |
| Uncached input | $3.00 |
| Five-minute cache write | $3.75 |
| One-hour cache write | $6.00 |
| Cache read | $0.30 |
| Output | $15.00 |
*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:
```text
Uncached: n × B
Cached: B × [w + (n − 1) × r]
Caching is cheaper when n > (w − r) / (1 − r)
```
| Total uses of the same prefix | No cache | Five-minute: one write | One-hour: one write |
| --- | ---: | ---: | ---: |
| 1 | $0.0180 | $0.0225 | $0.0360 |
| 2 | $0.0360 | $0.0243 | $0.0378 |
| 3 | $0.0540 | $0.0261 | $0.0396 |
| 10 | $0.1800 | $0.0387 | $0.0522 |
*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.
| Writes / reads across ten requests | Five-minute prefix cost | One-hour prefix cost | Uncached baseline |
| --- | ---: | ---: | ---: |
| 1 / 9 | $0.0387 | $0.0522 | $0.1800 |
| 4 / 6 | $0.1008 | $0.1548 | $0.1800 |
| 8 / 2 | $0.1836 | $0.2916 | $0.1800 |
| 10 / 0 | $0.2250 | $0.3600 | $0.1800 |
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.
| Expected pattern | Starting policy | What could reverse it |
| --- | --- | --- |
| One isolated request | Leave the reusable-prefix cache off | A second real use becomes likely |
| Stable rapid exchanges | Five-minute caching | Long generation or tool work separates request starts |
| Repeated work with longer pauses | Calculate one-hour versus repeated five-minute writes | Too few actual returns to repay the premium |
| Frequently changing instructions | Repair prefix layout first | A genuinely stable segment can be isolated |
| Unpredictable overnight returns | Budget a fresh write | A separate active workload actually reuses the entry |
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]
| Observed problem | Check before changing TTL |
| --- | --- |
| Repeated writes on every request | Compare the prefix and breakpoint placement |
| Both cache counters remain zero | Check model minimum and cache configuration |
| Misses after editing tools | Compare definitions, ordering and tool settings |
| Misses after long generation | Measure time between request starts |
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.
| Request | Cache read / write tokens | Calculated input cost |
| --- | --- | ---: |
| 1 | 0 / 6,000 | $0.0225 |
| 2 | 6,000 / 2,000 | $0.0093 |
| 3 | 8,000 / 2,000 | $0.0099 |
| 4 | 10,000 / 2,000 | $0.0105 |
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.
```json
{
"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 Key Insight
A high cache-hit percentage can coexist with an expensive application. Count output, fresh context, rewrites and failed work. Optimize the cost of an accepted result, not one favorable token category.
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.
## Sources
1. [Claude model and feature pricing](https://platform.claude.com/docs/en/about-claude/pricing)
2. [Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
3. [Token counting](https://platform.claude.com/docs/en/build-with-claude/token-counting)
4. [Cache diagnostics beta](https://platform.claude.com/docs/en/build-with-claude/cache-diagnostics)
5. [Tool use with prompt caching](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-use-with-prompt-caching)
6. [Usage and Cost Admin API](https://platform.claude.com/docs/en/manage-claude/usage-cost-api)
7. [Batch processing](https://platform.claude.com/docs/en/build-with-claude/batch-processing)
8. [How Claude Code uses prompt caching](https://code.claude.com/docs/en/prompt-caching)
9. [Sonnet 4.6 model reference](https://platform.claude.com/docs/en/models/sonnet-4-6/overview)
*Last updated: September 20, 2026*
---
*Source: [LLM Rumors](https://www.llmrumors.com/news/claude-prompt-caching-cost-break-even)*