Anthropic's prompt caching cuts up to 90% of the cost of repeated tokens in production

Anthropic's official documentation details how cache hits cost only 10% of the base input price, a calculation that changes the margin for anyone resending large context on every API call.

Anthropic's prompt caching is easy to forget because it looks like an infrastructure detail. It isn't. According to the feature's official documentation, cache hits (when the model reuses a previously processed prompt prefix) cost 10% of the normal input price for most models, and 2.5% for the newest ones, Claude Fable 5.1 and Claude Mythos 5.1. For any product that sends the same large context (knowledge base, tool definitions, conversation history) on every call, this isn't a performance optimization. It's a rewrite of the product's variable cost structure.

The calculation that actually changes

Anthropic's pricing table has five columns per model: base input, 5-minute cache write, 1-hour cache write, cache read (hit), and output. In Claude Sonnet 4.5, for example, base input costs $3 per million tokens (MTok), a 5-minute cache write costs $3.75/MTok (25% more expensive than the base), and a cache read costs $0.30/MTok, ten times cheaper.

Applying this to a concrete case: a support agent with a 15,000-token knowledge base in the system prompt, reused across ten interactions in a single session in under five minutes. Without cache, each call reprocesses the 15,000 tokens at $3/MTok: ten calls cost $0.45 just for this fixed slice of the prompt. With automatic caching, the first call writes ($3.75/MTok x 15,000 tokens = $0.056) and the other nine read from the cache ($0.30/MTok x 15,000 tokens x 9 = $0.04). Total: $0.097, a drop of about 78% in this part of the bill. This number is derived from the official pricing table, not a measurement, but it shows the order of magnitude the mechanism delivers when the traffic pattern is favorable.

Why most AI-native products resend context from scratch

The reason this gain isn't automatic is structural: applications that use RAG, agents with extensive tool definitions, or code copilots that send the entire repository as context tend to assemble the prompt from scratch on every call, because that's the simplest way to code it. Anthropic's documentation describes two ways to enable caching: automatic, with a single cache_control field at the top of the request that the API pushes on its own to the last cacheable block on every turn, and explicit, with cache_control marked block by block for fine control over what stays stable and what changes.

The detail that separates those who save from those who don't lies in the order the prompt is assembled: the cache hierarchy follows tools, then system, then messages, and any change at one level invalidates that level and all the ones that follow. This means placing variable content (a timestamp, the session id, the user's text) before static content destroys the cache further down, even if the rest of the prompt is identical between calls.

The trap the documentation itself warns about

Anthropic explicitly describes this common mistake: if the cache breakpoint is placed in the last block of the prompt, and that last block changes with every request (for example, it has an embedded timestamp), the system never finds a previous write to reuse. The practical result: every call pays the cache-write premium (25% more expensive than normal input on the 5-minute TTL) and never gets to pay the read price, which is the cheap part. In other words, a poorly implemented prompt caching setup isn't neutral, it increases the bill compared to never having used cache at all.

For whoever decides product architecture, this becomes a checklist item before celebrating the projected savings: the breakpoint needs to sit in the last block whose prefix is identical across the calls that should share the cache, not in the last block of the prompt. Swapping the order of two blocks in the code can be the difference between cutting cost by 80% and increasing it by 25%.

Limits that lock out products with small prompts

There's a token floor for caching to kick in: 512 tokens on Opus 5 and the Fable/Mythos models, 1,024 on Sonnet 5 and Sonnet 4.5, and up to 4,096 on Haiku 4.5. Below that, Anthropic simply processes the request without caching and without an error, which is dangerous because the product team may think it's saving money when it isn't: the cache_creation_input_tokens and cache_read_input_tokens fields in the API response come back at zero, and only by checking them can a hit be confirmed.

Products with a short system prompt (300 to 800 tokens of instructions, with no embedded knowledge base) simply don't benefit from the mechanism as it stands today, unless they artificially expand the static context to clear the floor, which only pays off if that context gets reused many times.

5-minute TTL versus 1-hour TTL: a traffic choice, not a pricing one

The default cache lasts 5 minutes and is renewed at no extra cost on every read, but the clock counts from the start of the request that writes or reads the cache, not from the end of the response. For products with heavy traffic and continuous sessions, that's enough. For B2B tools with sparse usage, where the user takes more than 5 minutes between one call and the next, the cache expires before the next hit, and the option is to pay for a 1-hour TTL at 2x the base input price ($6/MTok instead of $3/MTok on Sonnet 4.5, for example). This only pays off if the volume of subsequent reads within that hour is high enough to offset the double price paid relative to normal input. A low-volume product using the 1-hour TTL can end up paying more than it would without any caching at all.

The counterpoint: this isn't Anthropic's competitive advantage

The strongest argument against treating this as a strategic differentiator is that context caching tends to be common practice among large-scale LLM providers: given the shared economic incentive (reducing the cost of reprocessing repeated context), it's reasonable to assume that other major providers offer equivalent context-caching mechanisms. If this reading is correct, prompt caching wouldn't be an exclusive moat for Anthropic, but a competitive baseline that every large-scale LLM provider needs to have. What changes from vendor to vendor is the implementation semantics (explicit breakpoints, a 20-block lookback window, the tools/system/messages hierarchy), and that's what creates engineering lock-in: once the team structures the prompt around Anthropic's specific caching rules, migrating to another provider mid-operation means rewriting that structure, not just swapping out the API call.

What this changes for decision-makers

The practical implication for those building AI products in Brazil and paying per token is twofold. First, the unit economics of any feature that repeatedly resends large context (RAG with a stable knowledge base, a copilot with a fixed repository, an agent with extensive tool definitions) needs to be recalculated assuming a well-structured cache, because the difference between 100% and 10% of the input price is too large to ignore when pricing the product. Second, and more important for those who already have caching implemented: it's worth auditing the usage fields in the API response to confirm real hits are happening, because the most common way to get this wrong (a breakpoint on content that changes with every call) doesn't throw an error, it silently generates a higher bill.

Source: Anthropic, official Prompt Caching documentation (https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching).