Cut AI Costs With Prompt Caching (2026)

Prompt caching is the single largest lever on an AI bill in 2026, and most teams still leave it switched off.

On September 1, 2026, Anthropic cut the price of a cache read on its flagship model by 75%, to $0.25 per million tokens - Anthropic pricing. That is 2.5% of the $10 input price for the same tokens. Read that number twice, because it quietly rewrote the economics of every agent, chatbot, and document pipeline built on a large model. When re-reading context costs one-fortieth of reading it fresh, the question stops being "which model is cheapest" and becomes "how much of my prompt am I paying full price for twice."

The uncomfortable truth is that an AI application resends almost the same thing on every call. A support agent resends its system prompt, its tools, and the whole conversation on turn after turn. A retrieval app resends the same retrieved documents for every question. A coding agent resends the entire file it is editing each time it thinks. Without caching, you pay the full input rate for all of it, every single time. With caching, you pay it once and then a fraction of a cent to reuse it. The gap between those two worlds is routinely a factor of three or more on the total bill, and it is entirely under your control.

This guide is the practical, first-principles version of that story. It explains what prompt caching actually is, how the four major providers price and implement it differently, where the hidden cliffs are that silently switch it off, and how to build an application so the cache does the heavy lifting. It assumes you are a founder or a builder, not a researcher, so it stays concrete: real prices, real mechanics, and a 30-day playbook you can hand to an engineer. Platforms like Founden, which build and run entire companies from a single description, treat this caching architecture as table stakes rather than a tuning project, and by the end you will understand why that matters for what you pay.

Contents

1. The 2026 prompt-caching scorecard
2. Why the cache line became your biggest bill
3. How prompt caching actually works
4. Anthropic: the $0.25 cache read that reset the math
5. OpenAI: automatic caching and the GPT-6 Astra bill
6. Google Gemini: implicit, explicit, and the storage tax
7. DeepSeek, open weights, and hosting your own cache
8. Beyond prefixes: gateways and semantic caching
9. The economics: break-even, hit rates, and stacking levers
10. Seven ways teams silently lose the cache
11. A practical playbook: cut the bill in 30 days
12. The 2026 backdrop: price wars, crawler tolls, and the compliance floor
13. Conclusion: a decision framework

1. The 2026 prompt-caching scorecard

Every caching implementation makes the same promise, pay once and reuse cheaply, but they differ on the handful of things that decide your actual bill. The scorecard below ranks the major implementations on four questions worth reasoning about from first principles: how cheap is a cache hit relative to reading the tokens fresh, how much work do you have to do to get hits, what does it cost to create and keep the cache alive, and how well does it survive an agent loop. Those, not raw sticker price, are what separate a caching layer that quietly halves your bill from one that adds a surcharge.

The five weighted criteria reflect that reasoning. Read discount (30%) is weighted highest because on a well-cached workload the cache-read line is the largest item on the bill, so its depth matters most. Zero-config (20%) and write and storage overhead (20%) capture the two ways a cache costs you: engineering effort and the premium to write or store it. Control and TTL (15%) and agent fit (15%) round out how much the implementation lets you tune, and how gracefully it holds up across long tool loops. Each cell carries the score and the evidence behind it, and the table is sorted by final score, highest first. Your own product's cost profile depends on which of these you land on, so read the justifications, not just the numbers.

Scores are 0 to 10 per criterion; the final column is the weighted average, one decimal, sorted descending (ties alphabetical). A high rank means the implementation cuts cost with the least friction, not that it is right for you: DeepSeek and self-hosting top the read-discount column because a hit costs almost nothing, but both trade away control, and self-hosting swaps a token bill for GPU capital and operations. Anthropic leads on balance because the deep Fable 5.1 read discount arrives alongside real control (breakpoints, dual TTLs, pre-warming) and the highest measured agent-loop savings. OpenAI wins outright on effort, since caching is invisible and automatic, at a higher per-hit price. Gemini and Bedrock are capable but each carries a friction: Gemini's hourly storage rent and Bedrock's model-limited, checkpoint-driven setup. The rest of this guide is the depth behind each row, because a table cell cannot tell you when a storage tax is trivial or when a semantic hit returns the wrong answer.

2. Why the cache line became your biggest bill

The right way to understand caching is to start with a structural question, not a pricing one: what does an AI application actually send to the model on each call? The answer is uncomfortable. Because every major LLM API is stateless, the model remembers nothing between requests, so your code has to resend the entire relevant context every single time. A chat app resends the whole conversation. A retrieval app resends the same retrieved documents for each question. A coding agent resends the file it is editing on every step of its reasoning. The model is not charging you for thinking so much as for re-reading the same tokens over and over, and that re-reading is the line item caching exists to attack.

Follow that through and the cost curve is worse than linear. In an agent loop, each turn appends a little new content and then resends everything that came before it. If every turn adds roughly the same number of tokens, then turn two resends turn one, turn three resends turns one and two, and turn forty resends the previous thirty-nine. The total input processed across a task grows with the square of the turn count, not in proportion to it, which is why a long agent run can quietly cost ten times what a short one does even though it did only twice the work - Anthropic cost guide. A 40-turn task effectively sends its opening context 40 times, and without caching you pay the full input rate for all 40.

Almost everything the model reads on a given turn is content it already read on the previous turn. The stable, repeating part is the cached prefix: the system prompt, the tool definitions, and the accumulated transcript. The part that genuinely changes is small: the new user message, a freshly retrieved chunk, the current step's instruction. Caching does not stop the resending, and it cannot, because the model is stateless. What it does is reprice the repeated prefix to one-tenth of the input rate, or one-fortieth on Claude Fable 5.1, so the quadratic term that used to dominate your bill is multiplied by a small fraction. The practical consequence is counterintuitive: on a well-built agent, the cache-read line becomes the single largest item on the bill, ahead of both output tokens and uncached input, which is exactly why tuning it is the highest-leverage cost work you can do - Anthropic cost guide.

There is one part of the bill caching can never touch, and naming it prevents a lot of wasted effort. Caching is a byte-exact prefix match, so the one thing that differs on every request, the new question or the fresh document, sits after the last cache point by construction and always pays full input price. That irreducible tail is why the goal is not "cache everything" but "freeze the stable prefix and push all volatile content to the end." Teams running long, unattended agents feel this most acutely, which is why we treat caching as a first-class design constraint in our playbooks for orchestrating parallel AI agents and running Claude Code unattended. With the economics established, the rest comes down to mechanics.

3. How prompt caching actually works

Before comparing providers, it is worth being precise about the mechanism, because almost every caching failure in production traces back to a misunderstanding of one sentence: prompt caching is a prefix match, and any change anywhere in the prefix invalidates everything after it - Anthropic prompt caching. The cache key is a hash of the exact bytes of your prompt up to a marked point. If a single character changes at position 500, every cached token from position 500 onward is thrown away and re-billed at full price. This is not a quirk of one vendor. It is how all of the major exact-match caches work, and internalizing it is 80% of using caching well.

The order the model reads your request in is fixed: tools first, then the system prompt, then the messages - Anthropic prompt caching. That ordering is the whole game. Stable content that never changes (your frozen system prompt, a deterministic tool list, a reference document) belongs at the front, before the cache breakpoint. Volatile content that changes every request (the user's new question, a timestamp, a per-request ID) belongs at the very end, after the last thing you want to cache. Get that ordering right and caching largely works for free. Get it wrong, by interpolating "current time: 14:32:07" into the top of your system prompt, and no amount of cache configuration will save you, because you have made the prefix unique on every call.

A cache breakpoint is the marker that says "hash everything up to here and store it." On Anthropic you place up to four breakpoints per request and the system checks 20 blocks backward for a matching entry - Anthropic prompt caching. On OpenAI and DeepSeek the breakpoints are automatic and invisible: the provider hashes the front of your prompt and reuses whatever prefix it recognizes, with no markers to manage - OpenAI prompt caching. On Google you choose between an automatic (implicit) mode and a manual (explicit) mode that gives you a named cache handle - Gemini context caching. These are four genuinely different designs wearing the same name, and the differences decide how much work you have to do and how much you save.

Three practical constraints shape every implementation, and they are the ones people trip over first:

• A minimum prefix size. A prompt shorter than the model's floor will not cache at all, with no error raised. On Claude's newest models that floor is 512 tokens; on Gemini 3.x Flash it is 4,096 tokens - Gemini context caching.
• A time-to-live. A cache entry expires after a window (commonly 5 minutes, extendable to an hour) unless a new request refreshes it - Anthropic pricing.
• A usage signal. Every provider returns fields that tell you exactly how many tokens were served from cache, and reading them is the only way to know caching is working.

That last point deserves emphasis because it is where money leaks silently. On Anthropic the response carries cache_read_input_tokens, cache_creation_input_tokens, and input_tokens, and the three must sum to your total prompt size - Anthropic prompt caching. On OpenAI the usage block reports cached_tokens; on DeepSeek it splits into prompt_cache_hit_tokens and prompt_cache_miss_tokens - DeepSeek KV cache. If the "read" or "hit" number is zero across two identical requests, caching is broken and you are paying full price without knowing it. The costliest caching failure is not a bad first implementation, it is a working one that a later code change quietly disables, so the standing rule is to assert on these fields in a test, not to eyeball them once at setup.

4. Anthropic: the $0.25 cache read that reset the math

Anthropic's caching is the most fully featured of the four, and after the September 1 launch of Claude Fable 5.1 it is also the cheapest to read from - Anthropic pricing. The mechanics start from published multipliers relative to the base input price: a 5-minute cache write costs 1.25x the input rate, a 1-hour cache write costs 2x, and a cache read costs 0.1x - Anthropic prompt caching. In plain terms, you pay a small premium to put something in the cache, and then one-tenth of the normal price every time you read it back. The write premium is the thing OpenAI and DeepSeek do not charge, and it is the reason Anthropic's break-even math is worth understanding rather than assuming.

The break-even is gentler than the premium suggests. Because a 5-minute write costs 1.25x and a read costs 0.1x, caching pays off after a single cache read on the short duration, and after two reads on the 1-hour duration - Anthropic pricing. For anything that reuses context even twice, caching is already cheaper, and an agent that reuses its system prompt across forty turns is not close to the margin: it is saving on thirty-nine of the forty. This is why the honest advice is to turn caching on and leave it on permanently, rather than treating it as an optimization you reach for only under cost pressure.

What Fable 5.1 changed is the read side. On every other Claude model a cache read is 0.1x the input price; on Fable 5.1 it is 0.025x, which is $0.25 per million tokens against a $10 input rate - Anthropic pricing. That single footnote moves every break-even below it and changes the design calculus for long-horizon agents. When a miss costs forty times a hit rather than ten times, the penalty for accidentally invalidating the cache is far steeper, and keeping the prefix byte-stable becomes the highest-leverage thing an engineer can do. The concrete prices across the Claude lineup are worth seeing side by side, because the cache-read column is where the real spending happens on a cached workload:

All figures are per million tokens - Anthropic pricing.

The other reason Anthropic scores well is that it gives you tools to keep the cache intact under real-world pressure. Cache entries follow a three-tier invalidation hierarchy (tools, then system, then messages), so a change to tool_choice invalidates only the messages cache and leaves the expensive tools-plus-system prefix untouched - Anthropic prompt caching. Operator instructions that arrive mid-conversation can be appended as a system-role message rather than edited into the top-level system prompt, which preserves the cached history instead of rewriting it. And for bursty traffic there is a 1-hour TTL and a max_tokens: 0 pre-warm request that writes the cache before the first real user arrives. None of this is mandatory, but it is the difference between a cache that survives contact with production and one that quietly degrades.

The measured payoff is not hypothetical. Anthropic reports that prompt caching cut agent-loop cost by a factor of 2.7 to 5.3, on runs that read 79% to 90% of their input from cache, and that a small issue-triage agent's bill fell 83% from caching alone (88% with input trimming added) - Anthropic cost guide. Over a full day of real traffic its agent loops read a median 84% of input from cache, the top 10% of harnesses read 94% or more, and deep inside a task a well-built loop pays full price on under 1% of its input - Anthropic cost guide. On the DeepResearch benchmark the effect is starkest on Fable 5.1 precisely because its read discount is deepest: cost per task fell from $37.94 to $7.12, an 81% drop, against Claude Sonnet 5's 62% drop from $3.20 to $1.20 - Anthropic cost guide.

The worked example makes the shape concrete at a smaller scale. A one-hour coding session on Claude Opus 5 that reads 40,000 of its 50,000 input tokens from cache drops from $0.705 to $0.525, and the cache-read line for those 40,000 tokens is two cents - Anthropic pricing. Two cents to reprocess forty thousand tokens is the number that should reframe how you think about context, and it is why we treat caching as the first cost lever, not the last, in our guide to Claude Fable 5 for building companies.

5. OpenAI: automatic caching and the GPT-6 Astra bill

OpenAI took the opposite design philosophy: caching is fully automatic, on by default, and invisible - OpenAI prompt caching. There are no breakpoints to place and no markers to manage. The API hashes the front of your prompt, and any prefix it has seen recently is served from cache at the discounted rate without a line of code from you. On GPT-5.6 and later the cache triggers once a prompt passes 1,024 tokens, grows in fixed increments, and a cache hit is billed at 0.1x the uncached input rate, a 90% discount - OpenAI prompt caching. The trade for that simplicity is control: you get less say over exactly what is cached and for how long.

The pricing is where GPT-6 Astra, released September 3, 2026, lands in the same bracket as Claude Fable 5.1 on the sticker but higher on the cache read. Astra is $10 input, $1.00 cached input, and $50 output per million tokens on the short-context tier - OpenAI pricing. That cached-input rate is four times Fable 5.1's $0.25, which is the single sharpest divergence between the two flagships and a real input to a build-vs-build decision, covered in our guide to GPT-6 Astra vs Fable 5.1. There is also a cliff worth knowing: a prompt over 272,000 tokens reprices the entire request to the long-context tier at $20 input and $75 output, with cached input doubling to $2.00 - OpenAI pricing. A cache hit does not save you from the long-context reprice; it only discounts the already-repriced input.

The GPT-5.6 family is the volume play, and its cached-input rates are what make high-traffic products viable. The tiers step down cleanly, and the cached column is the one that decides a per-request cost at scale:

Short-context tier, per million tokens - OpenAI pricing. We break down which tier fits which workload in GPT-5.6 Sol vs Terra vs Luna.

Two operational details matter for getting hits reliably. First, cache routing uses a hash of the initial tokens, and you can steer related requests to the same cache with an optional prompt_cache_key parameter, which is useful when a fleet of workers shares a prefix but you want them to land on one entry - OpenAI prompt caching. Second, the retention window on GPT-5.6 and later is 30 minutes after the most recent write or reuse, extendable toward 24 hours with a prompt_cache_retention setting - OpenAI prompt caching. That longer window is a genuine advantage over the default 5-minute TTL elsewhere: for a chat product where users reply after a coffee break, OpenAI keeps the prefix warm through the gap without you paying a write premium to extend it, because OpenAI does not charge a separate premium to create the cache in the first place.

6. Google Gemini: implicit, explicit, and the storage tax

Google splits caching into two modes, and understanding the split is the key to Gemini's cost profile. Implicit caching is on by default for every Gemini 2.5 and newer model, and it passes the discount to you automatically whenever a request re-hits recent context, with no code change - Gemini context caching. Explicit caching is the manual path: you declare the content through the CachedContent API, get a handle, set a TTL, and reference it on later calls. The discount on both is 90% on 2.5-and-later models (75% on the older 2.0 generation), so the read economics rival Anthropic's standard tier - Gemini context caching.

The pricing of the workhorse model is aggressive, and it is the reason Gemini keeps winning high-volume, large-context jobs. Gemini 3.8 Flash is $0.75 input, $3.75 output, and a $0.075 cache read per million tokens through the end of 2026 - Gemini pricing. A cache read at seven-and-a-half cents per million is the cheapest headline read rate among the frontier-adjacent models, which is what makes Flash the default for document-QA and classification at scale. There is a scheduled catch: that is introductory pricing, and it doubles on January 1, 2027, to $1.50 input and $0.15 cache read, so anything you size on Flash economics should be modeled at both prices - Gemini pricing.

The design difference that trips people up is the storage tax on explicit caching. Where Anthropic and OpenAI bill you only for writes and reads, Gemini's explicit cache charges rent for keeping the content alive: Flash is $0.50 per million tokens per hour of storage through 2026, and Gemini 3.1 Pro is $4.50 per million tokens per hour - Gemini pricing. For a large document that many users query within a short window, that rent is trivial against the reads it enables. For a cache you declare and forget, it is a meter running in the background, and the wrong TTL turns a saving into a slow leak. The right mental model is that explicit Gemini caching is a lease, not a purchase, and you size the lease to the traffic.

Implicit caching removes the storage tax but hands back control, and it has been less reliable than the docs imply. Through mid-2026 developers reported that implicit caching silently stopped applying its discount on some Gemini Flash-Lite projects around June 30, which is exactly the failure mode the usage fields exist to catch - Google AI Developers Forum. The minimums also bite harder than elsewhere: Gemini 3.x Flash needs 4,096 tokens before anything caches, versus 512 on the newest Claude models, so short prompts that would cache on Anthropic silently will not on Gemini - Gemini context caching. The practical takeaway is to use explicit caching with a deliberately chosen TTL when you know a large context will be reused, and to verify usage.cached_content_token_count religiously when relying on the implicit path.

7. DeepSeek, open weights, and hosting your own cache

The cheapest reads in the market are not on the frontier models at all, they are on DeepSeek and on hardware you rent yourself. DeepSeek's caching is automatic in the most literal sense: a disk-based key-value cache runs by default for every user, matches any recognized prefix on a best-effort basis, and clears itself when the content falls out of use, usually within hours to a few days - DeepSeek KV cache. You write no code, place no breakpoints, and read the outcome from prompt_cache_hit_tokens and prompt_cache_miss_tokens in the response. The catch is that you also get no control: you cannot pin a TTL, guarantee a hit, or pre-warm, which is the honest trade for a cache that costs almost nothing.

The pricing is the headline. DeepSeek-V4.1-Flash bills a cache hit at $0.003 per million tokens off-peak ($0.006 at peak) against a cache-miss input of $0.15, so a cached read costs roughly 2% of a miss, and the DeepSeek-V4-Pro tier reads at $0.022 per million against a $0.66 miss - DeepSeek pricing. A read at three-tenths of a cent per million tokens is the cheapest cache-read rate available anywhere, and it is what makes DeepSeek the reflexive choice for high-volume, cost-sensitive pipelines, a case we make in depth in our look at DeepSeek V4.1 Flash. Seen next to the frontier models, the spread in cache-read prices is enormous, and it is the single number that should drive a high-volume routing decision:

For teams that self-host an open-weight model, caching stops being a line item and becomes free. Open weights, including the Qwen 3.8 family that Alibaba released this year at roughly $0.15 input and $0.47 output per million on hosted endpoints, can run on your own GPUs, and the two dominant serving stacks cache automatically - Gemini alternatives roundup. vLLM's automatic prefix caching splits the key-value cache into 16-token blocks, hashes each block, and reuses any block whose hash it has seen, enabled with --enable-prefix-caching and on by default in recent versions. SGLang's RadixAttention stores activations in a radix tree keyed by token sequence and starts each request at the longest matching branch, on by default - SGLang vs vLLM. Because the reused tensors sit in GPU memory you already pay for, a cache hit costs nothing beyond the electricity, and a healthy agent workload reaches a 70%-plus hit rate once the first few requests warm the tree.

The trade is real and worth stating plainly, because "free reads" hides a large fixed cost. Self-hosting swaps a per-token bill for GPU capital and operations: you provision the hardware, keep the server warm, and own the reliability. For most founders that is the wrong trade until volume is very large or data cannot leave your infrastructure, which is exactly the calculus we walk through in the best open-weight model to self-host. The same prefix discipline applies either way, and it bites harder here: a single whitespace change in the system prompt invalidates the entire cached prefix on vLLM and SGLang just as it does on the managed APIs, so the character-for-character stability of your prompt is the one thing that determines whether any of this saves you money.

8. Beyond prefixes: gateways and semantic caching

Everything so far shares one mechanism, and it is worth naming the boundary of that mechanism before crossing it. Prefix caching keys on identical leading bytes, which means it can only ever discount the repeated front of a prompt and can never return a wrong answer, because a byte-identical prefix is by definition the same prefix. A second, fundamentally different technique, semantic caching, keys on the meaning of a request rather than its bytes: it embeds each incoming prompt, compares it against stored prompts by vector similarity, and returns a previously computed answer when the similarity clears a threshold. The difference in what they save is large. Prefix caching discounts input tokens only; a semantic hit skips the model call entirely, saving both input and output, because you serve the stored answer instead of generating a new one.

The hit-rate gap is the reason semantic caching exists. Exact-match response caches for natural-language prompts hit only about 4% of the time, because users phrase the same question a hundred different ways, whereas embedding-keyed semantic caches recognize those variants as equivalent and hit closer to 60% - GPTCache docs. The open-source GPTCache library popularized the pattern, and managed offerings now remove the operational burden: Redis LangCache auto-generates the embeddings so there is no model to run, returns a hit when similarity clears a configurable threshold (commonly 0.85 to 0.95), and reports customers such as Mangoes.ai reaching a 70% hit rate that cut LLM spend 70% - Redis LangCache. AI gateways such as Portkey and Helicone put the same cache at the proxy layer, in front of whatever model you call.

The power comes with a hazard that prefix caching does not have, and it is a correctness hazard rather than a cost one. A threshold that is too loose returns answers that do not quite fit the question, and because the answer is fluent and plausible it is far harder to catch than a dead link or an error. Portkey, drawing on more than 250 million cache requests, recommends starting the similarity threshold at about 0.95 and backtesting on roughly 5,000 real queries until accuracy holds above 99%, and pairing every threshold with a TTL so stale answers expire - Portkey semantic caching. This is why semantic caching belongs on repeatable, low-stakes traffic, a support FAQ, a documentation assistant, a classifier, and why it is dangerous on an agent that must act on fresh state. The safe default is to run provider prefix caching everywhere and add semantic caching only where a wrong-but-plausible answer is genuinely tolerable.

One layer sits between your code and all of this and deserves a mention: the multi-provider gateway. Tools like OpenRouter pass each underlying provider's caching through unchanged, forwarding Anthropic's manual breakpoints, OpenAI's automatic cache, and DeepSeek's disk cache with their native economics, and they add a separate response cache that returns byte-identical requests at zero token cost, which is closer to an HTTP cache than to prompt caching - OpenRouter caching. The managed clouds add a tenancy guarantee worth knowing: Amazon Bedrock scopes caches to your account and Azure OpenAI never shares a cache between subscriptions, so there is no cross-customer prefix you can accidentally warm or leak into - Azure OpenAI caching. For a builder, the gateway is a convenience layer, not a new kind of caching, and the economics still come from the provider underneath.

9. The economics: break-even, hit rates, and stacking levers

Caching is close to free money, but "close to" hides a break-even that is worth internalizing, because it is the reason a naive implementation can cost more than none at all. You pay a write premium the first time content enters the cache, and you only recover it on reuse. On Anthropic a 5-minute write costs 1.25x the input rate and a read costs 0.1x, so the arithmetic works out to caching being net-positive by the second request; a 1-hour write costs 2x, so it takes until the third request to pay off - Anthropic pricing. The lesson is that caching a prompt used exactly once is a small loss, and caching anything reused even twice is a win, which is why the correct policy is to leave it on for everything that repeats and off for genuinely single-shot prompts.

The TTL choice follows directly from how far apart your reusing requests are, and a cache read refreshes the entry's timer for free, so keeping a prefix warm is often cheaper than paying to store it longer. The rule is to measure the start-to-start gap between requests that share a prefix: under five minutes, the default TTL refreshes on every request and is strictly cheaper; between five minutes and an hour, the 1-hour TTL is the only window where paying the 2x write is worth it; beyond an hour, neither helps and you re-warm on a schedule with a max_tokens: 0 request instead - Anthropic prompt caching.

Once caching is working, the discounts stack, and they stack multiplicatively, which is where the largest savings hide. The Batch API takes 50% off every token, including cache reads and writes, so a shared prefix that already reads at 0.1x reads at 0.05x once batched, and on Claude Fable 5.1 a cache read at 0.025x drops to 0.0125x - Anthropic pricing. The one caveat is that batches must use the 1-hour TTL, because the default 5-minute window expires mid-run. The compounding is dramatic on a repeated prefix, and the chart below shows it on a system prompt that would cost $10 per million tokens to read fresh:

Two other levers interact with caching in ways that are easy to get wrong. The first is model routing: caches are scoped to a single model, so a cost cascade that sends some turns to a cheaper model forfeits cache reuse across the two, because each model keeps its own separate cache and re-pays the write premium. Running one capable model at a lower effort setting often beats a two-model cascade for exactly this reason, since it keeps a single cache namespace warm, a point we develop in our guides to cutting agent costs with model routing and setting the effort dial. The second is your hit rate, which is the KPI that tells you whether any of this is working: divide cache-read tokens by the sum of cache-read, cache-creation, and uncached input, and a stable production prompt should sit at or above 85% - Anthropic prompt caching. Anything much lower means a silent invalidator is at work, which is the subject of the next section.

10. Seven ways teams silently lose the cache

The most expensive caching failure is not a bad first implementation, it is a working cache that a later change quietly disables. Nothing errors, every request still succeeds, and the bill simply climbs, so the failure can run for months before anyone notices. The root cause is always the same: something upstream of the cache breakpoint changed a byte, and because caching is a strict prefix match, that one byte invalidated everything after it. The patterns that do this are well known and greppable, and catching them is mostly a matter of knowing where to look in the code that assembles the prompt.

Each of these has the same fix, which is architectural rather than a patch: move the dynamic piece after the last breakpoint, make it deterministic, or delete it if it is not load-bearing. A timestamp belongs in a user message at the end of the conversation, not in the system prompt header, because a value at turn five invalidates nothing before turn five. A tool list should be sorted deterministically and kept identical across users. Anthropic even provides a cache-preserving channel for mid-conversation instructions, a system-role message appended to the message array rather than an edit to the top-level system prompt, precisely so operator changes do not rewrite the cached prefix - Anthropic prompt caching. The discipline is to treat the prefix as frozen and everything volatile as a suffix.

Verification is the other half, and it is not optional. Every provider returns usage fields that are the only ground truth that caching is working: on Anthropic the response splits into cache_read_input_tokens, cache_creation_input_tokens, and input_tokens, and if the read number is zero across two identical requests, caching is broken - Anthropic prompt caching. Reading these once at setup is not enough, because the failure mode is a regression that arrives later. The durable fix is a standing check: an integration test that fires the same request twice and asserts that the second one shows cache reads greater than zero, so a future change to prompt assembly that breaks the cache fails a test instead of quietly inflating the bill. Anthropic also ships a beta cache-diagnostics mode that names exactly where two requests diverged, which turns a payload-diffing chore into a one-line answer when a hit rate mysteriously collapses.

11. A practical playbook: cut the bill in 30 days

Turning the theory into a lower bill is a short, ordered sequence, and the order matters because each step depends on the one before it. The overarching principle is that caching is a free win that goes first and stays on permanently, before you touch any lever that trades quality for cost. What follows is the sequence that consistently moves the number, framed for a small team with an existing application rather than a greenfield build.

The first move is the highest leverage: turn caching on and make the prefix cacheable. On OpenAI and DeepSeek this is automatic, so the work is purely structural: order the request so the stable content comes first. On Anthropic and Bedrock you add a cache_control breakpoint at the end of the shared portion. Everywhere, the job is to freeze the system prompt and tool list and push the volatile tail to the end.

• Freeze the system prompt so no timestamp, user ID, or random value lives in it
• Sort the tool list deterministically so it renders identically on every request
• Place the breakpoint at the end of the shared prefix, not after the unique question
• Verify the usage fields show cache reads above zero on a second identical request
• Choose the TTL from the start-to-start gap between reusing requests

Those five steps are the whole free win, and they are worth walking through with the actual usage signal in front of you, because the signal is what separates a cache that works from one that only looks like it does. A minimal verification on the Claude API makes the pattern concrete: place the breakpoint on the shared block, then read the response usage to confirm the second call reads from cache.

{
  "model": "claude-fable-5-1",
  "system": [
    { "type": "text", "text": "<large frozen system prompt and reference material>",
      "cache_control": { "type": "ephemeral" } }
  ],
  "messages": [{ "role": "user", "content": "The one thing that changes every request" }]
}

{
  "usage": {
    "cache_creation_input_tokens": 4096,
    "cache_read_input_tokens": 0,
    "input_tokens": 12
  }
}

On the first call cache_read_input_tokens is zero and cache_creation_input_tokens shows the write; on the second identical call the read field should carry the whole prefix and creation should fall to near zero. If it does not, a silent invalidator from the previous section is in the prompt. With caching verified, the remaining moves are cheaper wins on top: route non-urgent work through the Batch API for the stacking 50% discount, keep the main loop on one model at a tuned effort rather than a cache-splitting cascade, and only then consider a semantic cache on the repeatable, low-stakes portion of your traffic. Teams that would rather not hand-tune any of this are increasingly reaching for platforms such as Founden, which run the entire agent loop, caching, batching, and model selection included, as part of building and operating a company from a description, so the cost architecture is the platform's job rather than yours.

12. The 2026 backdrop: price wars, crawler tolls, and the compliance floor

Caching became the dominant cost lever because of a specific 90-day stretch that reset builder economics more than any capability jump did. The frontier price floor moved up and held: both GPT-6 Astra, released September 3, and Claude Fable 5.1, released September 1, sit at $10 input and $50 output per million tokens, so roughly $10/$50 is the current reference for a frontier call, and the cache read, at $1 on Astra and $0.25 on Fable 5.1, is where real spending is decided - Simon Willison on GPT-6 Astra. The cheap tier moved the opposite way and is time-boxed: Gemini 3.8 Flash is a near-frontier workhorse at an introductory $0.75 input, but that doubles to $1.50 on January 1, 2027, so any 2026 cost model built on Flash's intro rate silently doubles in the new year - Gemini Flash pricing. Anthropic also shipped signed on-demand compaction on September 4, a primitive that lets a builder summarize a long conversation at a chosen boundary rather than pay to resend it, which is caching's natural complement for very long agent runs - Anthropic compaction.

The unit of work moved at the same time, and it pushed cost prediction back onto token accounting. Cursor Projects and the OpenAI Agents API both launched in beta on September 10, and both bill at the underlying model's API rate with no harness fee, so the cost of an agent is now the sum of its tokens and tool calls rather than a platform markup - OpenAI Agents API. Metered, effort-based billing spread in parallel, with Replit charging its Agent by task complexity rather than a flat per-prompt fee, a model we unpack in setting up metered billing for your AI product - Replit effort pricing. The capital backing this shift is real: Temporal raised a $550M Series E at a $12.55B valuation on September 14, on the thesis that durable execution is the substrate agentic systems run on - Temporal Series E.

Operating costs and control got concrete too, in ways that touch a small team's monthly bill directly. Vercel shipped a Flat Rate CDN for Pro teams on September 8, trading usage-based delivery for a predictable monthly figure - Vercel Flat Rate CDN. Cloudflare flipped its crawler defaults on September 15 so that new domains block Training and Agent bots on pages that display ads while leaving Search allowed, a decision every content-bearing product now has to make deliberately - Cloudflare crawler defaults. Even the subscription tiers tightened: Anthropic's promotional Claude Code weekly-limit boost ended on September 14 and was replaced by a smaller permanent increase, a net reduction of roughly 17% in included headroom for heavy users - Claude Code limits. And the model-distribution layer began consolidating, with NVIDIA agreeing to acquire Hugging Face for $12.93 billion on September 3 - NVIDIA and Hugging Face.

The legal floor shifted alongside the commercial one, and three dated obligations now touch a builder's code rather than just its terms of service. EU AI Act Article 50 transparency duties became applicable on August 2, 2026, requiring disclosure for chatbots, synthetic media, and emotion recognition, with fines up to EUR 15M or 3% of worldwide turnover - Cooley on Article 50. The revised Product Liability Directive, which for the first time treats software and AI as liable products, must be transposed into national law by December 9, 2026 - Jones Day on the PLD. And the Digital Omnibus entered into force on July 27, 2026, deferring some high-risk obligations and easing SME compliance - European Commission. A generative feature shipped into the EU is in scope of the disclosure duty today regardless of its risk tier, which is why we keep a running checklist in making your AI app EU compliant. Taken together, the message of the quarter is that cost architecture is now the discipline, and caching is its first primitive.

13. Conclusion: a decision framework

Strip away the provider differences and the decision is simple, because one rule dominates all the others: turn prompt caching on, and leave it on, for anything that repeats context. It is a free win that goes first, before any lever that trades quality for cost, and on a real workload it is worth a factor of two to five on the total bill. The only prompts you should not cache are the genuinely single-shot ones, where the write premium has no reuse to recover it. Everything else in this guide is about which implementation you land on and how to keep the cache from silently breaking.

Which implementation to choose follows from what you actually value, and the honest answer is that there is no universal winner. If you want the deepest read discount with real control, Claude Fable 5.1 at $0.25 per million cached tokens plus breakpoints and dual TTLs is the strongest balance, and it pairs naturally with the model choices we compare in the best AI model to build your app. If you want caching to be invisible and automatic, OpenAI's zero-config prefix cache is the least work, at a higher per-hit price and the long-context reprice cliff detailed in what GPT-6 Astra really costs. If you want the cheapest possible reads, DeepSeek's automatic disk cache and self-hosted vLLM or SGLang are unbeatable on price and weakest on control. If you serve large reused contexts, Gemini's explicit cache is built for it, provided you watch the hourly storage rent. And semantic caching is a powerful addition only where a plausible wrong answer is tolerable.

The deeper point for a founder is that caching is one primitive in a cost discipline that now decides whether an AI product has a margin at all, alongside model routing, effort tuning, batching, and the metered billing we cover in pricing your product to beat token costs. Getting all of it right by hand is real engineering, which is why the whole stack, from caching strategy to model selection, is increasingly something builders delegate to a platform rather than assemble themselves. Whether you build it yourself using the patterns in the AI-native company tech stack or hire an AI workforce to run the company, the economics are the same: the teams that win in 2026 are the ones paying full price for the tokens they actually need, and a fraction of a cent for the ones they are only re-reading.

This guide reflects the AI pricing and prompt-caching landscape as of September 2026. Model names, per-token prices, and cache-read rates change frequently, and several rates cited here (notably Gemini 3.8 Flash) are introductory and scheduled to rise on January 1, 2027. Verify current pricing on each provider's own page before committing a cost model.