# Anthropic Claude prompt caching pricing: write, read, TTL math Anthropic prices prompt caching with three numbers: a 1.25x or 2x premium on cache writes depending on TTL, a 0.1x rate on cache reads, and the base input rate for everything after the last breakpoint. This deep-dive verifies every figure against the current official docs and covers per-model minimums, break-even math, batch stacking and how Claude on Azure converts it all into CCUs. - Published: 2026-08-31 · Category: AI & Machine Learning · Tags: Prompt Caching, Anthropic, Claude, Claude API, LLM Cost Optimization, Microsoft Foundry, Azure, Batch API - Author: Technspire AB, Stockholm (https://technspire.com) - Canonical: https://technspire.com/en/blog/anthropic-prompt-caching-pricing-mechanics Updated 6 September 2026 with a per-model price table and a section on cache isolation and security. All rates verified against the Anthropic documentation. 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](/en/blog/prompt-caching-2026-real-cost-wins); 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 | Model | Base input | 5m write (1.25x) | 1h write (2x) | Cache read (0.1x) | Output | | --- | --- | --- | --- | --- | --- | | Claude Fable 5 | $10 | $12.50 | $20 | $1 | $50 | | Claude Opus 5 (and Opus 4.8, 4.7, 4.6, 4.5) | $5 | $6.25 | $10 | $0.50 | $25 | | Claude Sonnet 5 | $2 | $2.50 | $4 | $0.20 | $10 | | Claude Sonnet 4.6 (and 4.5) | $3 | $3.75 | $6 | $0.30 | $15 | | Claude Haiku 4.5 | $1 | $1.25 | $2 | $0.10 | $5 | One pricing note worth keeping on record: Sonnet 5's $2/$10 rates were announced as introductory pricing through 31 August 2026, with a scheduled increase to $3/$15 on 1 September. That increase did not happen; Anthropic's pricing page now lists $2/$10 as the standard price. If your forecast still carries a 50% Sonnet price jump from September, you can delete that line. ## 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. ## Cache isolation and security Questions about caching security come down to scoping, and the scoping is strict. Cache entries are isolated per workspace within an organization, and this holds across the first-party Claude API, Claude on AWS, and Microsoft Foundry. No other organization can read your entries, and neither can your own second workspace: a hit requires a byte-identical prefix from the same workspace, and the entry expires at the end of its TTL. There is no cache ID to leak and no way to address another tenant's entry, because entries are not addressable at all. The request content itself is the key. A related point of confusion imported from the OpenAI side: `prompt_cache_key` is an OpenAI API parameter used to influence cache routing, and it has no Anthropic equivalent. Claude caching is controlled entirely through `cache_control` breakpoints, and cache identity is the exact rendered prefix in the order tools, system, messages. If you arrived here searching for how to set a cache key on the Claude API: you do not. You mark breakpoints, and the prefix does the rest. The realistic failure mode is accidental misses rather than leaks: an interpolated timestamp or a reordered tool list quietly turns reads into full-price writes. From a data-handling perspective, a cached prefix persists server-side only until its TTL runs out, refreshed by use. If a prompt must not persist at all, do not mark it with a breakpoint. ## 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.** As covered in the isolation section above, 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. **Want to know what would actually reduce your AI bill?** Our [AI cost assessment](/en/services/azure-openai-integration#offers) reviews a real month of your usage, tests the caching and batching opportunities on your workloads, and delivers a prioritized savings plan with the math shown. ## Sources - [Anthropic docs: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) - [Anthropic docs: Pricing (model table, caching multipliers, Foundry CCU billing)](https://platform.claude.com/docs/en/about-claude/pricing) - [Anthropic docs: Batch processing (caching in batches)](https://platform.claude.com/docs/en/build-with-claude/batch-processing) --- Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt