What Is Prompt Caching and How Much Does It Really Save?

Last updated 19 September 2026. Savings ranges and multipliers below were checked against Anthropic’s prompt caching and pricing documentation on that date. Model prices and cache rates 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 “prompt caching,” “what is prompt caching,” or “prompt caching claude,” you probably want a straight answer to the title: how much does it really save?

The short version: prompt caching lets Claude’s API remember a stable chunk of your prompt — tools, system instructions, a long document, yesterday’s conversation — so the next request can reuse that chunk instead of re-processing it at full input price. On Anthropic’s published rates, a successful cache read costs 0.1× base input on most models (and 0.025× on Claude Fable 5.1 and Mythos 5.1). A first-time cache write costs a premium — 1.25× for a five-minute TTL, or 2× for a one-hour TTL. [VERIFY: 2026-09-19]

That is not “90% off your Claude bill.” It is a deep discount on the reusable input you keep sending. Output tokens still cost what they cost. The changing part of each request still costs full input. How much of your actual invoice moves depends on how big that reusable prefix is and how often you hit it before it expires.

For how tokens are counted in the first place, start with the pillar. For the full write-vs-read arithmetic, TTL rules, and break-even math, go to the companion page on Anthropic prompt caching pricing — that is the technical deep dive this article funnels into. To estimate cost before you send, open the calculator early.

What prompt caching is (without the jargon)

Think of every Claude API call as shipping a stack of context: tool definitions, a system prompt, maybe a long policy PDF or a codebase summary, then the user’s latest question. Without caching, the API charges full input for that whole stack on every call — even when 40,000 of those tokens are identical to the last call.

Prompt caching says: mark the stable prefix once, pay a small write premium to store it, then pay a fraction of base input each time you reuse it. The model’s answer does not change. Anthropic documents that caching has no effect on output generation; you still pay ordinary output rates for whatever Claude writes back. [VERIFY: 2026-09-19]

Two everyday pictures:

1. The shared handbook. Your product bot always gets the same 30-page FAQ and brand rules. Cache that handbook. Each customer question only pays full price for the question (and the reply).
2. The growing chat. A coding agent reuses the same tools and project instructions while appending turns. Each new turn can read the earlier prefix from cache instead of re-billing it at 1×.

If those pictures do not match your traffic — one-off prompts, constantly rewritten system text, tiny prefixes — caching will not move the needle. That is fine; other levers will, which is why this page also points at broader cut-usage and cost-framework guides below.

How prompt caching reduces inference costs

“Inference cost” here means what you pay Anthropic (or a cloud that bills the same way) for processing tokens. Caching reduces that cost by changing the price per token on the cached prefix, not by making Claude think less carefully.

Mechanically, input splits into three billable buckets:

1. Uncached / base input — anything after the cache breakpoint, or the whole prompt if nothing caches.
2. Cache write (creation) — first time that prefix is stored.
3. Cache read (hit / refresh) — later requests that retrieve the same prefix.

On published Anthropic multipliers: writes are 1.25× (5-minute TTL) or 2× (1-hour TTL) vs base input; reads are 0.1× on most models. [VERIFY: 2026-09-19]

So if a 50,000-token system+tools block would cost $0.15 as ordinary Sonnet 4.6/4.5 input ($3 / MTok), a five-minute write is about $0.1875, and each later read is about $0.015. [VERIFY: 2026-09-19] After a single reuse, the write-plus-read path already beats two full uncached sends. That break-even rule of thumb — roughly one read after a 5m write, or two after a 1h write, at the standard 0.1× read rate — is Anthropic’s own framing; the companion pricing mechanics page walks the algebra and more model rows.

Caching also often improves time-to-first-token on long prefixes, because the provider can skip re-processing work it already did. Latency is a side benefit; the title question is about money.

How much does it really save? A range, not a magic number

Here is the honest team-lead answer.

On the reusable input portion alone, once caching is working (writes happening, then steady reads inside the TTL), expect something like about 40% to about 90% off that prefix’s input cost relative to sending it uncached every time — depending on how many hits you get per write and which TTL you chose. [VERIFY: 2026-09-19]

Why a range, not “you will save 90%”:

Illustrative math for input on the cached prefix only (ignore output; ignore the uncached suffix). After one 5m write at 1.25× and N reads at 0.1×, average cost per use vs always paying 1× is:

• N = 1 → average ≈ 0.675× → roughly ~32% off the prefix vs two uncached uses (break-even territory; still better than uncached once you reuse). [VERIFY: 2026-09-19]
• N = 4 → average ≈ 0.325× → roughly ~67% off. [VERIFY: 2026-09-19]
• N = 9 → average ≈ 0.215× → roughly ~78% off. [VERIFY: 2026-09-19]
• N = 19 → average ≈ 0.156× → roughly ~84% off. [VERIFY: 2026-09-19]

Push N higher and you asymptote toward the 0.1× read price — about 90% off that prefix versus always paying full input — which is where the top of the range comes from. [VERIFY: 2026-09-19] A 1h write at 2× needs more hits before the average looks that good; that is why Anthropic’s rule of thumb is two reads after a one-hour write.

On the whole invoice, the story is softer. If reusable context is half of your input tokens and input is most of the bill, cutting that half by ~80% might shave something like ~30–40% off total spend in a favorable agentic or RAG pattern. If reusable context is 10% of input, the same caching excellence might move the invoice by only a few percent. Output-heavy workloads (long essays, big code generations) leave a large uncapped line item either way.

So when someone asks “how much does prompt caching really save?” the responsible answer is: a large discount on repeated input, often in the 40–90% band for that repeated slice, and a smaller, highly workload-dependent cut to the total bill. Anyone quoting a single sitewide percentage without looking at your prefix share and hit rate is selling a headline, not a forecast. [VERIFY: 2026-09-19]

What has to be true for savings to show up

Four conditions do most of the work:

1. Something large is stable. Tools, system instructions, retrieval packs, or conversation history that you keep sending unchanged.
2. You reuse it inside the TTL. Default is five minutes; each successful read refreshes the clock at no extra write charge. Idle longer than the TTL and you pay another write. [VERIFY: 2026-09-19]
3. You clear the minimum length. Anthropic will not cache short prefixes; under-threshold requests process without caching and without an error. Minimums vary by model (hundreds to thousands of tokens). Details live on the pricing mechanics page. [VERIFY: 2026-09-19]
4. Exact match. A changed tool schema, a new image, a rewritten system paragraph, or a timestamp above the breakpoint can miss the old entry. Exactness is a feature (isolation and correctness), not a bug.

If you are guessing whether your stack meets those conditions, paste a week of traffic into the cost calculator as a rough input/output split, then read the technical companion — or have prompts reviewed via the audit (see a sample report).

When prompt caching is the wrong lever

Skip or postpone caching when:

• Calls are mostly unique one-shots with little shared prefix.
• The “stable” prompt secretly changes every request.
• Reuse is rarer than hourly and you would pay 2× writes without enough reads.
• The expensive part of the bill is output, not input — caching will not shrink that line.
• You need a broader cut list (session structure, model routing, context discipline) — start with the planned eleven ways to cut Claude token usage and the planned LLM cost optimization framework.

Caching is one of the highest-leverage API features when the pattern fits. It is not a substitute for fixing a bloated system prompt or defaulting every task to the heaviest model.

Prompt caching on Claude vs the idea in general

“Prompt caching” as a phrase also shows up around other providers. The idea is the same: do not re-bill identical prompt prefixes. The pricing and rules are provider-specific. This site’s numbers and TTL talk are for Claude / Anthropic’s API as documented on 19 September 2026. If your stack is multi-provider, treat each vendor’s cache product as its own spreadsheet row — then compare cost per finished task, not only per million tokens. Current Claude list prices with cache columns live on Claude API pricing.

FAQ

What is prompt caching in one sentence?

It is a way for the API to store a reusable prompt prefix so later requests can read it at a fraction of full input price instead of re-processing it every time. [VERIFY: 2026-09-19]

How does prompt caching reduce inference costs?

By billing cache reads at a documented multiplier (typically 0.1× base input on Claude) after you pay a write premium once per warm entry — so repeated tokens stop costing 1×. [VERIFY: 2026-09-19]

How much can Claude prompt caching save?

On the cached input portion, often roughly 40–90% versus always paying full input, once you have steady hits; on the total bill, usually less, because output and changing suffixes never get that discount. Conditions above move both numbers. [VERIFY: 2026-09-19]

Where do I get the full Anthropic pricing mechanics?

The companion article Anthropic Prompt Caching: How the Pricing Actually Works covers write vs read multipliers, TTL security, segment definition, invalidation, minimums, and break-even tables — verified against Anthropic’s docs on the same date.

Next steps

1. Skim the full pricing mechanics if you need write/read tables and break-even math.
2. Rough out your input vs output mix in the cost calculator.
3. If you want a human to mark which prefixes should be cached (and which habits still burn full input), audit your prompts — see the example report for format. No dollar price on this page; the offer page has the current scope.

Prompt caching is the plain-language entry. The deep dive is next door. Use both, then decide whether caching is your biggest lever or only one row in a wider cost plan.