Anthropic prompt caching pricing: write, read and TTL math

Anthropic prompt caching pricing comes down to three numbers: a 1.25x or 2x premium on cache writes depending on the TTL you pick, a 0.1x rate on cache reads, and the plain base input rate for everything after your last breakpoint. Those three multipliers, combined with per-model minimum cacheable token counts and a refresh rule that most teams misread, decide whether caching cuts your Claude bill by 80% or quietly makes it larger. Every number below was verified against the official Anthropic pricing and prompt caching documentation on 31 August 2026. If you want the broader picture of how caching compares across providers, start with our comparison of caching across Anthropic, OpenAI and Azure; this article stays narrow and goes deep on the Anthropic mechanics only.

The three multipliers behind every caching invoice

Anthropic bills cached prompts in three token categories, and your response usage object reports each one separately:

• Cache writes (cache_creation_input_tokens): 1.25x the base input price for the default 5-minute TTL, 2x for the 1-hour TTL. Charged when content is first stored.
• Cache reads (cache_read_input_tokens): 0.1x the base input price. Charged every time a later request is served from the cache, a 90% discount against uncached input.
• Uncached input (input_tokens): everything after your last breakpoint, billed at the standard 1x rate.

Total prompt size is always the sum of the three fields. A common misreading is treating input_tokens as the whole prompt; it is only the uncached remainder, so a long-running agent can legitimately show 4,000 input tokens on a 200,000-token context.

Per-model prices, per million tokens

One pricing note that lands today of all days: Sonnet 5's $2/$10 rates were announced as introductory pricing through 31 August 2026. Anthropic's pricing page now states that this is the standard price and the scheduled increase to $3/$15 on 1 September will not occur. If you budgeted for a 50% Sonnet price jump tomorrow, you can delete that line from the forecast.

5-minute vs 1-hour TTL: break-even and the refresh rule

The default cache_control: {"type": "ephemeral"} gives you a 5-minute lifetime; adding "ttl": "1h" extends it to an hour at the doubled write rate. Anthropic's own framing of the break-even is exact: 5-minute caching pays for itself after one cache read (1.25x write plus 0.1x read is 1.35x, versus 2x for two uncached passes), while 1-hour caching needs at least two reads (2x plus 0.2x is 2.2x, versus 3x uncached).

Two mechanics decide which TTL fits your traffic:

• Reads refresh the lifetime at the read price. The pricing table's column is literally named "Cache Hits & Refreshes": every hit renews the entry for the same duration as the preceding write, billed at 0.1x. Steady traffic therefore pays the write premium once and keeps the cache alive indefinitely on cheap reads.
• The clock starts at the request, not the response. Lifetime is measured from the start of the request that writes or reads the entry. If a response takes 4 minutes to stream, a follow-up reusing the same 5-minute cached prefix must arrive within roughly 1 minute of that response completing. Long-streaming agent turns eat their own TTL.

The decision rule: if requests reliably arrive less than 5 minutes apart, the default TTL is strictly cheaper. If gaps regularly exceed 5 minutes but stay under an hour, the 1-hour TTL wins by a wide margin, because the alternative is paying the 1.25x write on every request and never reading. The worked example below puts numbers on that failure mode.

Minimum cacheable token counts per model

A prefix shorter than the model's minimum silently does not cache. There is no error; you just see cache_creation_input_tokens: 0 and keep paying full price. The minimums are not monotonic across generations, which trips people up:

• 512 tokens: Claude Opus 5, Claude Fable 5, Claude Mythos 5
• 1,024 tokens: Claude Opus 4.8, Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5
• 2,048 tokens: Claude Opus 4.7
• 4,096 tokens: Claude Opus 4.6, Claude Opus 4.5, Claude Haiku 4.5

A 3,000-token system prompt caches on Opus 5 and Sonnet 5 but not on Haiku 4.5. That matters for the classic cost-tiering pattern where cheap classification traffic runs on Haiku: your shared prefix needs to clear 4,096 tokens there, four times the Opus 5 bar. When Opus 5 halved the Opus 4.8 minimum from 1,024 to 512, prompts previously written off as uncacheable started caching with no code change, so it is worth re-checking old assumptions after every model migration.

How breakpoints turn into line items

Caching is a strict prefix match over the rendered request, in the order tools, then system, then messages. You may place up to 4 explicit cache_control breakpoints per request; each one says "bill everything up to here as a write the first time, and as a read on later matching requests". A breakpoint on the last system block therefore caches the tool definitions and the system prompt together as one entry. Alternatively, a single top-level cache_control field enables automatic caching and lets the API manage breakpoints as the conversation grows, which is Anthropic's recommended starting point.

Two billing-relevant subtleties. First, hits require byte-identical prefixes, so a timestamp interpolated into the system prompt converts every would-be read back into a full-price write. Second, each breakpoint looks back at most 20 content blocks for a prior cache entry; agent turns that append more than 20 tool-use and tool-result blocks in one go can silently miss the previous turn's cache and re-pay the write. Both failure modes show up in the usage fields, which makes them cheap to detect: zero reads across repeated requests means an invalidator, and unexpected write charges on every turn of a long conversation suggests the lookback window.

Worked example 1: steady RAG traffic on Opus 5

An internal assistant on Claude Opus 5 carries a 40,000-token stable prefix (system prompt, tool definitions, policy excerpts) and a 500-token variable question, at 100 requests per hour with requests never more than a couple of minutes apart.

Uncached input per hour:
  100 x 40,500 tokens x $5/MTok            = $20.25

With a 5-minute-TTL breakpoint on the prefix:
  1 write:   40,000 x $6.25/MTok           = $0.25
  99 reads:  99 x 40,000 x $0.50/MTok      = $1.98
  questions: 100 x 500 x $5/MTok           = $0.25
  Total input per hour                     = $2.48

An 88% reduction on the input side, and because reads refresh the TTL, the write premium is paid once at the top of the hour rather than repeatedly. Output tokens are unaffected by caching, so output-heavy workloads see proportionally smaller total savings.

Worked example 2: sporadic traffic, where 5-minute caching loses money

Same 40,000-token prefix on Opus 5, but a back-office workflow that fires once every 20 minutes, 3 requests per hour. The 5-minute entry is always expired by the next request, so every request pays the write premium and nothing ever reads:

No caching:        3 x 40,000 x $5/MTok    = $0.60/hour
5-min TTL (all misses):
                   3 x 40,000 x $6.25/MTok = $0.75/hour  (25% WORSE)
1-hour TTL:
  first hour:      1 write  x $10/MTok x 40,000 = $0.40
                 + 2 reads  x $0.50/MTok x 40,000 = $0.04
  steady state:    3 reads/hour                  = $0.06/hour

Because each read refreshes the 1-hour lifetime, the entry never expires while the workflow runs, and steady-state input cost lands at a tenth of the uncached figure. This is the single most common Anthropic caching mistake we see in cost reviews: a correctly placed breakpoint with the wrong TTL for the traffic pattern, faithfully paying 1.25x forever.

Caching plus batch pricing: the discounts stack

The Message Batches API halves both input and output prices, and Anthropic's pricing page states explicitly that the caching multipliers stack with the batch discount. On Opus 5, batch input is $2.50/MTok, and a cache read inside a batch is billed at 0.1x of that. Three caveats from the batch documentation:

• Hits are best-effort in batches. Requests process concurrently, so observed cache hit rates range from roughly 30% to 98% depending on traffic shape. Include identical cache_control blocks in every request in the batch to maximize sharing.
• Prefer the 1-hour TTL for batch work. Batches can take longer than 5 minutes to process, so the docs recommend the 1-hour duration for shared-context batches.
• No pre-warming in batches. The max_tokens: 0 cache pre-warm request is rejected inside a batch, since an ephemeral entry written during batch processing would likely expire before any follow-up runs.

Claude on Azure: how Microsoft Foundry bills cached tokens

For the many Swedish and EU enterprises that consume Claude through Microsoft Foundry rather than the first-party API, the caching math above carries over unchanged; only the invoicing layer differs. Foundry bills through the Azure Marketplace in Claude Consumption Units (CCUs). Anthropic rates your token usage in USD at the standard per-model, per-feature rates, including the exact cache write and read multipliers in this article, applies any negotiated discount, converts the result at $0.01 per CCU (100 CCU per $1.00), and meters the CCU quantity to the Azure Marketplace hourly. Your Azure bill shows a single CCU line item, payment is in arrears with monthly invoices, and Azure Cost Management shows the aggregated CCU figure.

Three practical consequences for Azure-based teams:

• Caching savings are invisible in Azure Cost Management. Because everything collapses into one CCU meter, you cannot see write versus read token spend there. Instrument cache_read_input_tokens and cache_creation_input_tokens in your own telemetry if you want to prove the optimization to finance.
• US Data Zone deployments pay 1.1x on cached tokens too. Foundry's US Data Zone Standard deployment type is equivalent to inference_geo: "us" and applies a 1.1x multiplier across all token categories, cache writes and cache reads included. The same multiplier applies to US-pinned inference on the first-party API for Claude 4.6 and later models.
• Caches are workspace-scoped on Foundry. Caches are isolated per workspace within an organization on the Claude API, Claude Platform on AWS and Microsoft Foundry. Teams split across workspaces do not share cache entries, so a prefix cached in one workspace is a fresh write in another.

For EU procurement, the CCU model has a quiet upside: caching discounts flow through automatically as fewer CCUs metered, so an engineering optimization shows up directly on the Azure invoice without contract changes. The flip side is that CCUs are rated in USD before conversion, so currency exposure on a SEK or EUR budget remains, and a caching regression (an invalidated prefix after a prompt edit, for example) surfaces only as an unexplained CCU increase unless you track the usage fields yourself.

Checklist: pricing-correct caching in six checks

• 1. Confirm the prefix clears the model minimum. 512 tokens on Opus 5/Fable 5, 1,024 on Opus 4.8/Sonnet 5/Sonnet 4.6, 2,048 on Opus 4.7, 4,096 on Opus 4.6/Opus 4.5/Haiku 4.5.
• 2. Match TTL to inter-request gaps. Under 5 minutes: default TTL. Between 5 minutes and an hour: pay the 2x write once and ride 0.1x refreshes.
• 3. Count reads before enabling. One read breaks even on the 5-minute TTL, two on the 1-hour TTL. Fewer than that and caching is a net cost.
• 4. Watch the write premium on misses. A breakpoint that never gets read turns a 1x workload into a 1.25x or 2x workload.
• 5. Verify with the usage fields, not vibes. Sum input_tokens, cache_creation_input_tokens and cache_read_input_tokens; zero reads on repeated requests means a byte-level invalidator.
• 6. On Foundry, build your own cache telemetry. The CCU meter will not show you the split; the API response will.

Sources

• Anthropic docs: Prompt caching
• Anthropic docs: Pricing (model table, caching multipliers, Foundry CCU billing)
• Anthropic docs: Batch processing (caching in batches)