Anthropic Prompt Caching: How the Pricing Actually Works (Write vs. Read Costs)

Last updated 19 September 2026. Rates, TTL rules, and minimum cacheable lengths below were checked against Anthropic’s prompt caching and pricing documentation on that date. Model prices and multipliers change; confirm on Anthropic’s own docs before you budget. [VERIFY: 2026-09-19]

Not affiliated with Anthropic. Claude Token Optimization is an independent site and audit service. Claude® and related product names are trademarks of Anthropic PBC. Prompt caching rates, TTLs, and model prices change; always confirm on Anthropic’s own docs. [VERIFY: 2026-09-19]

If you searched “anthropic prompt caching pricing,” “anthropic prompt caching pricing mechanics,” or “claude prompt caching,” you are usually trying to answer one question: when does paying a write premium beat paying full input again?

Anthropic’s answer is mechanical. A cache write costs more than ordinary input. A cache read costs a fraction of ordinary input. Whether that trade pays off depends on how often the same prefix is reused before the TTL expires, and whether anything invalidates the entry. For a plainer overview of what caching is for, see the planned plain-language explanation of caching. For how tokens are counted in the first place, start with the pillar. To estimate cost before you send, open the calculator early — especially when you are comparing uncached input against a write-plus-reads plan.

The three prices that matter

Prompt caching does not replace base input pricing. It splits input into three billable buckets in the usage object:

1. Base / uncached input — tokens after the last cache breakpoint (or the whole prompt if nothing caches).
2. Cache creation (write) — tokens written into a new cache entry.
3. Cache read (hit / refresh) — tokens retrieved from an existing entry.

Anthropic publishes multipliers relative to each model’s base input price, not a single global dollar rate. Across active models the documented multipliers are: [VERIFY: 2026-09-19]

That is the entire pricing story in one table. Everything else — break-even, TTL choice, invalidation — is arithmetic and prompt structure on top of these multipliers.

Worked dollar examples (selected models)

Applying the multipliers to published base input rates gives concrete write and read prices. All figures below are derived from Anthropic’s model pricing table as of the verification date and should be re-checked before budgeting. [VERIFY: 2026-09-19]

Use the live Claude API pricing page when you need the full per-model card; this article focuses on the mechanics of write vs read, not every retired SKU.

Cache write premium: what you pay to store a prefix

A cache write is charged when content is first stored at a cache breakpoint. For the default five-minute TTL, that write is 1.25× base input — a 25% premium over sending the same tokens as ordinary input. For the optional one-hour TTL, the write is 2× base input — you pay double to keep the entry warm for an hour. [VERIFY: 2026-09-19]

Writes are not free side effects. If you place cache_control on a block that changes every request (a timestamp, a unique user payload, the incoming message), you can pay the write premium on every call and never earn a read. Anthropic’s documentation is explicit: writes happen at your breakpoint; the system does not silently invent stable entries behind a moving suffix.

Automatic caching (cache_control at the top level of the request) places the breakpoint on the last cacheable block and moves it forward as conversations grow. Explicit breakpoints let you pin the write to the last block that stays identical across requests. Both modes use the same multipliers.

Cache read discount: what you pay on a hit

A cache read (hit or refresh) is charged when a later request retrieves the cached prefix. On most models that read costs 0.1× base input — ten cents on the dollar relative to uncached input. On Claude Fable 5.1 and Claude Mythos 5.1, Anthropic documents a deeper 0.025× read multiplier. [VERIFY: 2026-09-19]

Using a cached entry also refreshes its lifetime at no additional charge beyond the read itself. That means a busy multi-turn agent that reuses the same tools + system prefix every minute can keep a five-minute entry warm indefinitely, as long as something keeps hitting it inside the TTL window.

Cache reads do not change the model’s output. Anthropic states that prompt caching has no effect on output token generation; you still pay ordinary output rates for whatever Claude writes back. [VERIFY: 2026-09-19]

TTL behaviour: five minutes, one hour, and the clock you are actually on

Default TTL is five minutes. The optional extended TTL is one hour, requested with "ttl": "1h" inside cache_control. [VERIFY: 2026-09-19]

Two timing details matter more than the headline numbers:

1. Lifetime is measured from the start of the request that writes or reads the entry, not from when the response finishes streaming. If a response takes four minutes to stream, a follow-up that needs the same prefix has roughly one minute left on a five-minute TTL after that response completes. [VERIFY: 2026-09-19]
2. A successful read refreshes the TTL for no extra write charge. Idle gaps longer than the TTL force a fresh write (and the write premium) on the next hit.

Anthropic’s pricing docs summarize when each TTL pays off: keep five-minute writes when prompts are reused more often than every five minutes; prefer the one-hour write when reuse is less frequent than five minutes but more frequent than hourly, when latency after an idle gap matters, or when you want cache hits to help rate-limit utilization (cache hits are not deducted against the rate limit in the way Anthropic describes for this feature). [VERIFY: 2026-09-19]

You can mix 1h and 5m breakpoints in one request, but longer-TTL entries must appear before shorter-TTL ones. Billing then splits the prompt into read / 1h-write / 5m-write regions by breakpoint position. [VERIFY: 2026-09-19]

Anthropic prompt caching segment definition

When people search “anthropic prompt caching segment definition,” they are asking what actually gets hashed into a cache entry.

A cache segment (prefix) is the contiguous prompt content from the start of the request hierarchy through the block marked with cache_control. Anthropic builds that hierarchy in a fixed order: tools, then system, then messages. The cache entry is a hash of everything up to and including the breakpoint. Exact match is required — including text and images. [VERIFY: 2026-09-19]

Practical consequences:

• Changing any block at or before the breakpoint produces a different hash and misses the old entry.
• You can define up to four explicit breakpoints to isolate sections that change at different frequencies (stable tools, daily context, growing conversation). [VERIFY: 2026-09-19]
• On a miss, the system can look backward up to 20 blocks per breakpoint for an earlier write — it looks for prior writes, not for “stable-looking” content. [VERIFY: 2026-09-19]
• Place the breakpoint on the last block that stays identical across the requests you want to share. Do not put it on a per-request timestamp or the fresh user message if those change every call.

That segment definition is why a coding loop that keeps tools and project instructions fixed while appending turns can hit cache repeatedly, while a loop that reshuffles tool JSON key order or injects a unique header every time will not.

What invalidates a cache

Modifications follow the tools → system → messages hierarchy. Changes higher in the stack invalidate that level and everything below it. Summarizing Anthropic’s invalidation table: [VERIFY: 2026-09-19]

Also treat these as operational invalidators even when the docs phrase them as misses:

• Letting the TTL expire without a refresh
• Sending from a different workspace (workspace-level isolation on the Claude API)
• Falling below the model’s minimum cacheable length (request processes without caching; no error)

Minimum cacheable length

Shorter prompts cannot be cached even if marked with cache_control. Anthropic documents per-model minimums; requests under the threshold process without caching and return zeros in both cache_creation_input_tokens and cache_read_input_tokens. [VERIFY: 2026-09-19]

If you are a few hundred tokens short of the minimum on a frequently reused system prompt, expanding the cached block to clear the threshold is often cheaper than forever paying full input — but only if you will actually get reads afterward.

Break-even calculation: how many reads before a write pays for itself

This is the section most “pricing mechanics” searches want. Compare one uncached send of a prefix against one write plus N reads of the same prefix. Ignore output tokens (identical either way) and ignore uncached suffix tokens after the breakpoint.

Let B = base input price per token for the model. Let W = write multiplier (1.25 for 5m, 2.0 for 1h). Let R = read multiplier (0.1 on most models; 0.025 on Fable/Mythos 5.1). [VERIFY: 2026-09-19]

Cost without caching for (1 + N) uses of the prefix: (1 + N) × B × tokens
Cost with caching: (W × B × tokens) + (N × R × B × tokens)

Caching is cheaper when W + N·R < 1 + N, which rearranges to N > (W − 1) / (1 − R).

Anthropic’s own pricing page states the same rule of thumb: a cache hit at 0.1× means caching pays off after one cache read for the five-minute duration, or after two cache reads for the one-hour duration. [VERIFY: 2026-09-19]

Worked example — Sonnet 4.6, 50,000-token system+tools prefix, 5-minute TTL

• Base input: $3 / MTok → 50k tokens = $0.150 uncached. [VERIFY: 2026-09-19]
• One 5m write: 1.25 × $0.150 = $0.1875
• Each read: 0.1 × $0.150 = $0.015

If the TTL expires before the second use, you never reach break-even and the write premium is pure waste. That is why TTL choice and request cadence belong in the same decision as the multiplier math.

For agentic coding sessions that reuse tools and repo context across many turns, the same arithmetic is why caching shows up as one of the largest levers — see the planned guide to caching inside a coding loop. Pair it with the broader list of eleven ways to cut usage when write/read is only one of several fixes.

TTL security and workspace isolation

Searches for “anthropic claude api prompt caching ttl security” usually mix two concerns: how long retained prefixes live, and who can hit them.

Anthropic documents ephemeral as the supported cache type, with five-minute or one-hour lifetimes — not indefinite storage. Entries are isolated between organizations, and on the Claude API (and several Anthropic-operated cloud paths) also per workspace within an organization. Exact matching is required; different organizations never share caches even with identical prompts. [VERIFY: 2026-09-19]

Operationally: treat cached prefixes as sensitive as the prompts themselves, prefer the shortest TTL that still matches your reuse pattern, and do not assume a cache entry written in one workspace is visible in another.

Tracking whether caching is actually working

Inspect the usage fields on every response: [VERIFY: 2026-09-19]

• cache_creation_input_tokens — write
• cache_read_input_tokens — read
• input_tokens — tokens after the last breakpoint only
• Optional cache_creation.ephemeral_5m_input_tokens / ephemeral_1h_input_tokens when TTLs are mixed

Total input processed ≈ read + creation + input. If both creation and read stay at zero, you are under the minimum length, outside the TTL, mismatched on the prefix, or never marking a breakpoint.

When caching is the wrong lever

Skip or postpone caching when:

• The reusable prefix is below the model minimum and you cannot expand it
• Reuse happens once per hour or less and you are still paying 2× writes without enough reads
• The “static” prefix secretly changes (timestamps, shuffled tool JSON, per-user PII injected above the breakpoint)
• You need human review of which prefixes are wasteful in production traffic — that is closer to what an audit finds than to another pricing table

FAQ

What is anthropic prompt caching pricing in one sentence?

You pay 1.25× or 2× base input to write a cache entry (5m or 1h), then typically 0.1× base input to read it, until TTL expires or the prefix changes. [VERIFY: 2026-09-19]

How do anthropic prompt caching pricing read write costs compare?

Writes are a premium; reads are a deep discount. Break-even is about one read after a 5m write, or two reads after a 1h write, at the standard 0.1× read rate. [VERIFY: 2026-09-19]

Where is the anthropic prompt caching documentation?

Primary sources: Anthropic’s prompt caching guide and the Claude API pricing page on platform.claude.com — the same sources this article was verified against on 19 September 2026.

Next steps

If you want a human to mark which of your prefixes should be cached, which breakpoints are in the wrong place, and which patterns still burn full input, have your prompts reviewed. See the sample audit report for the format. For the plain-language companion to this page, see the what is prompt caching article.