Prompt Caching — The Discount Everyone Quotes, and the Traffic Rate Where It Turns Into a Surcharge (2026)

Quick answer: Prompt caching lets a model reuse work it already did on the unchanged opening of your prompt, and bills those tokens at a fraction of the normal input price. Three things on this page are worth more than the definition. The first is that on their current flagship models all three major vendors now price a cache read at one tenth of their base input rate — Anthropic across its whole published table, OpenAI on GPT-5.6 and later, and Google on the two Gemini models we priced — and agree on almost nothing else: the minimum length a prefix must reach before it is eligible ranges from 512 to 4,096 tokens depending on which model you called, and on Anthropic falling short of it fails silently, with no error returned. The second is that the "50 percent discount" still quoted everywhere comes from an OpenAI announcement dated 1 October 2024 that is still live, while the current documentation says something different in both directions. The third is arithmetic, and it is the one that can cost you money: a cache write is billed at more than a normal input token, so if your traffic is thin enough that the entry expires between requests, every request pays the write premium and never collects a read. We work out the thresholds below, one per cache window: what decides it is the gap between consecutive requests, not the volume.

What it is, and what it is not

Every request you send to a language model is processed from the beginning. If a support bot ships the same 6,000-token system prompt, tool schema and policy document on every single conversation, the model does that same opening work every single time, and you pay full input price for it every single time.

Prompt caching interrupts that. The vendor keeps the processed form of the opening section for a short window, and requests that arrive with a byte-identical opening are charged a reduced rate on the part that was reused. Anthropic and OpenAI call it prompt caching. Google calls it context caching. The mechanics differ; the idea does not.

Three distinctions matter, and readers collapse all three.

It is not the same as your context window. The window is how much the model can hold at once. Caching is about how the front of that window is billed. A cached prefix occupies exactly as much of the window as an uncached one, and cached tokens still count against rate limits — OpenAI's documentation states that flatly, and adds that caching "does not change rate-limit calculations."

It is not retrieval-augmented generation. RAG changes which documents enter the prompt on this request. Caching changes what you are charged for the ones that were already there last time. They interact badly, in fact, and the section on cache misses below explains why.

And it is not a semantic cache. A semantic cache stores finished answers and returns one when a new question looks similar. Prompt caching stores no answers, matches nothing approximately, and has no effect on what the model says. OpenAI's documentation is explicit that the model still computes a fresh response, so "otherwise identical nondeterministic requests are not guaranteed to return identical output."

The three vendors agree on the price and on nothing else

Read side by side, the striking thing is how tightly the headline multiplier has converged and how far apart everything underneath it still is.

Four things fall out of that table that no one vendor's page will tell you.

The famous 1,024-token minimum is true of one branch of one vendor. It is the strict floor on OpenAI's GPT-5.6 and later, and it happens to coincide with Anthropic's floor for the Sonnet 5 generation. It is wrong by a factor of two against Anthropic's Opus 5 floor of 512 and by a factor of four against Google's 4,096 on the current Flash models; the full spread across the four bands is a factor of eight. If your system prompt is 3,000 tokens you are comfortably cacheable on one vendor and not eligible at all on another.

Falling short of the minimum fails silently. Anthropic's documentation is unusually direct about this: requests to cache fewer than the minimum "will be processed without caching, and no error is returned." The only way to know is to read the usage fields back — if both the creation and read counts are zero, nothing was cached. That is a check worth writing into your logging on day one, because the failure mode is a bill that quietly never improves.

Only Anthropic charges a fixed write premium for the longer lifetime. Its one-hour cache is a 2× write against 1.25× for the five-minute one. OpenAI's extended 24-hour retention, on the models that support it, is priced identically to the in-memory policy — its documentation says "prompt cache pricing is the same for both policies."

Google is the only one billing for storage. The cache read on Gemini 3.7 Flash is $0.075 per million tokens against a $0.75 input price, exactly one tenth. But explicit caching also carries a storage charge of $0.50 per million tokens per hour on the Flash models and $4.50 on Gemini 3.1 Pro Preview, which is a cost category the other two do not have at all. Two dated details travel with those figures and both are on Google's own pricing page: the Flash rates carry a scheduled doubling on 1 January 2027 (input $0.75 to $1.50, cache $0.075 to $0.15, storage $0.50 to $1.00), so anyone modeling next year's costs from today's page will be exactly half right. And on Batch, where Gemini 3.1 Pro Preview input drops to $1.00, the caching price is marked "Same as Standard" at $0.20 — a fifth of batch input, not a tenth.

One more structural note, because it changes what you can build: Google's caching documentation states that the Interactions API supports implicit caching only, and that explicit cache objects require switching to the older generateContent API. On Gemini you cannot have the newest API surface and hand-managed cache entries at the same time.

The 50 percent that is not there any more

Search for prompt caching pricing and the 50 percent figure comes back repeatedly and confidently. We traced it to its source on 22 August 2026.

It traces cleanly, which makes a change from most benchmark trails. OpenAI's announcement post Prompt Caching in the API is dated 1 October 2024 and is still live. It says that "by reusing recently seen input tokens, developers can get a 50% discount," and prints a table to match: gpt-4o at $2.50 uncached against $1.25 cached, gpt-4o-mini at $0.15 against $0.075, o1-preview at $15.00 against $7.50. Every row is exactly half. The same post gives the 1,024-token minimum, the 128-token increments and the five-to-ten-minute eviction that are still quoted today.

Now read the current documentation. On GPT-5.6 and later, OpenAI's API guide states that "cached input tokens are billed at 0.1× the uncached input token rate" and that "tokens written to the cache are billed at 1.25× the uncached input token rate." The string "50%" does not appear anywhere in that guide. For earlier models it declines to give a number at all: "cached input is billed at the cached-input rate when the model offers one. Rates and discounts vary by model."

So the figure in circulation is wrong in two directions at once, which is why neither correction has caught on. On current models a cached token costs five times less than the quoted figure implies: a 90 percent discount where the 2024 post promised 50. And there is now a charge that did not exist in 2024 at all, the write, which that announcement had no reason to mention because writes were free.

We are not accusing anyone of misquoting. The 2024 post is clearly dated and carries no correction notice. The point is narrower and more useful: a pricing fact about a model family does not survive the model family, and this one has outlived several while still circulating as current.

There is a version of that mistake on this site, which is the honest place to put it. Our own OpenAI API pricing calculator prices GPT-4o, GPT-4o mini, o1 and other legacy models alongside newer ones, and tells readers as a flat figure that cached input costs "about 10% of full price". That is right on GPT-5.6 and later and wrong by a factor of five on exactly the models the 2024 announcement priced at half — the same conflation this section is about, running the other way. It then illustrates the saving with "a typical bot with 300-token system prompt", which is below every minimum in the table above and would not cache at all, so the illustration's own "saves 20-30% on input cost" is a saving of nothing. It describes the window as a flat five minutes, where OpenAI's own figure for the older models is five to ten minutes of inactivity up to a one-hour maximum, and thirty minutes on GPT-5.6 and later — one number printed where the documentation gives three. And it tells the reader to add cache_control markers, which is Anthropic's parameter and not one OpenAI accepts. Four errors, found by writing this entry, filed for correction, and left standing here rather than quietly patched out of the sentence that criticizes everyone else for the same thing.

Where caching costs you money

Here is the part that is specific to a small operation, and it is our own arithmetic rather than anyone's finding. It is worked in full so you can check it.

Price everything in multiples of the base input rate for one copy of your shared prefix. Paying full price is 1.00. A cache read is 0.10. A five-minute cache write is 1.25.

If k requests sharing that prefix land inside one live window, the total is 1.25 + 0.10 × (k − 1) against k for paying full price. Set them equal and the crossover is at k = 1.28, so caching wins from the second request onward:

Read the first row again. A cache entry that is written and never read costs 25 percent more than not caching at all. On Anthropic's one-hour cache, where the write is 2×, a never-read entry costs 100 percent more.

That is not a hypothetical, and the condition that decides it is a gap, not a rate. All three vendors refresh a live entry for free when it is read — Anthropic prices reads and refreshes in a single column and says the cache "is refreshed for no additional cost each time the cached content is used", and OpenAI says reusing a prefix "refreshes its lifetime without creating another cache-write charge". So one write can serve an unbroken chain of requests of any length, provided no consecutive pair is further apart than the lifetime. The moment a gap exceeds it, the chain breaks and the next request pays a fresh write.

Two numbers therefore govern each cache window: the gap that keeps the chain alive, and the chain length at which the write pays for itself. The second falls straight out of the table above — at a 1.25× write you are ahead from the second request, and at a 2× write you need 2.0 + 0.10 × (k − 1) < k, which is k > 2.11, so the third.

One subtlety on the first row, because it is easy to lose: Anthropic's lifetime is "measured from the start of the request that writes or reads the cache entry, not from the end of its response." A response that takes four minutes to stream leaves roughly one minute of usable window, so a five-minute cache on slow generations is tighter than five minutes.

The practical output of the page is the last column. A cache window whose chain never forms is not a neutral setting. It is a standing surcharge of 25 percent, or 100 percent on the one-hour setting.

What that looks like in dollars

Take a support bot with an 8,000-token static prefix — system instructions, tool definitions and a policy document — running on Claude Sonnet 5, where base input is $2.00 per million tokens, a five-minute write is $2.50, a one-hour write is $4.00 and a read is $0.20. Say it handles 40 conversations a day across a ten-hour business day: four an hour, one every fifteen minutes, with an overnight gap that breaks any chain.

The default TTL is the one that loses money here, and it loses it by exactly 25 percent. The one-hour setting saves just over 85 percent against paying full price, and $21.17 a month against the default — for a change to one field.

Now be honest about the size of that. The entire decision is worth about twenty-one dollars a month. Run the same bot at 4,000 conversations a day, where requests are seconds apart and the five-minute cache holds through the whole business day, and the monthly prefix cost falls from $1,920 to $192.55 — thirty writes, one at the start of each day, and 119,970 reads. The decision at this volume is a different one — caching on or off, rather than which window — and it is worth roughly $1,727 a month. Neither the percentage nor the winning setting nor even the question is the same at the two volumes. What stays constant is that the dollars, not the percentage, decide whether this is worth an afternoon of your engineering time. Our LLM API cost calculator and token counter are for running your own version of this before you build anything.

Three things are deliberately missing from those figures, and each moves the answer. Output tokens are not in them, and they are usually the larger half of an LLM bill. The varying tail of each request — the user's actual message — is never cacheable and is not counted. And every number above assumes each request shares a byte-identical prefix, which is true of a system prompt and false of conversation history, as the next section explains.

What breaks a cache hit

A cache hit requires an exact prefix match. Not similar, not semantically equivalent — identical, every byte, through the point where the cache boundary sits. OpenAI's documentation repeats the rule twice on the same page and extends it explicitly to "images and tools, which must be identical between requests."

The failure modes are mundane and expensive.

A timestamp in the system prompt. Anthropic's documentation walks through exactly this as its named common mistake: a static block of context followed by a per-request block containing a timestamp, with the cache boundary on the wrong side of it. Every request writes a fresh entry, no request ever reads one, and you pay the write premium forever. Sorting a rendered date, a session ID or a "today is" line into the cacheable prefix is the single most common way to buy a 25 percent surcharge by accident.

Editing your tool definitions. Anthropic's invalidation table puts tool changes at the top of the hierarchy: modifying a tool's name, description or parameters invalidates the tools cache, the system cache and the message cache — everything. OpenAI adds that tool ordering and structured-output schema keys count too, and suggests keeping the underlying tools array fixed and narrowing with an allow-list where the API supports it. If you are shipping function calling, a one-word docstring edit is a full cache reset.

Rewriting conversation history. Append new turns; do not rewrite old ones. OpenAI states that "changing, deleting, or reordering earlier content changes the prefix and can cause a cache miss," and adds the one that catches people: "context truncation, summarization, and compaction can reduce prompt size, but they can also reset the reusable prefix." The tactic most often recommended for cutting token costs — summarizing old turns — destroys the cache that was cutting them. Our guide on managing the context window covers that trade in full.

Rebuilding the knowledge blob. If your prompt carries retrieved documents whose order changes per query, the prefix changes with it, and you are back to writes. RAG and caching coexist by keeping the stable material — brand voice, escalation policy, product catalog — ahead of the boundary and the query-specific retrieval behind it. Our knowledge base entry covers what belongs in which layer.

Toggles you forgot were settings. Anthropic's table lists several: enabling web search or citations rewrites the system prompt; switching speed modes invalidates the system and message caches; adding or removing an image anywhere in the prompt invalidates the message blocks. And a language-level trap worth its own line — Anthropic warns that some languages, naming Swift and Go, randomize map key order during JSON conversion, so identical tool results can serialize differently on consecutive requests and break the cache for no reason visible in your code.

The default that bills you

One reading of OpenAI's documentation is worth stating plainly, and labeling as a reading.

Three separate sentences in the current guide: implicit caching is the default mode; cache writes on GPT-5.6 and later "are billed at 1.25× the uncached input token rate"; and "if you set mode to explicit but provide no explicit breakpoints, the request does not use prompt caching or incur cache-write charges."

Read together, those three describe an opt-out. Our reading is that a GPT-5.6 workload with little or no prefix reuse is paying the 1.25× write premium by default, and that the documented way to stop is a mode flag most people will never set. The documentation does not say that in so many words, and we have not measured a bill against it. If you are running low-reuse traffic on a recent OpenAI model, that is a line item worth checking on your own invoice, and we would welcome a correction if it reads otherwise in practice.

Anthropic sits the other way round: caching is opt-in there, so an application that never adds cache_control never pays a write premium and never gets a discount either.

How to tell whether it is working

Each vendor reports the same two facts under three different names, which is its own small tax.

The number to watch is the ratio of reads to writes. A healthy cached workload reads many times per write. A ratio near zero — writes that are never followed by a read — is the 25 percent surcharge in the table above, wearing a disguise. One read per write is already the second row of that table and a 32.5 percent saving, and the gains compound from there. Anthropic also notes that input_tokens counts only the tokens after your last cache boundary, so it will look far smaller than your real prompt — read it as a diagnostic of where your boundary sits rather than as your input volume.

Three more operational facts worth knowing before you design around it. Caches are isolated per organization at Anthropic and OpenAI, both of which say so in as many words, and Anthropic isolates per workspace as well on most platforms, so two workspaces running the same system prompt hold two separate entries and pay two separate writes; Google's caching documentation does not address isolation, which should be read as undocumented rather than as a guarantee either way. Neither Anthropic nor OpenAI offers a manual cache clear — OpenAI's FAQ says "manual cache clearing is not currently available" — so you change the prefix and wait. And OpenAI adds a ceiling most readers of a cost page will not expect: on GPT-5.6 you must set prompt_cache_key to get the reliable matching, and its documentation says to keep traffic on any one key to roughly 15 requests a minute, above which "some requests may miss the cache." A high-volume deployment therefore needs its keys sharded, or it loses hits at exactly the volume where they are worth most.

Where it breaks

Treating it as an optimization rather than a design constraint. Caching pays only if your prompt has a large, genuinely static front end. If your architecture assembles a bespoke prompt per user, there is nothing to cache, and no flag will create one. That is a decision about prompt structure, taken before any billing setting.

Assuming the percentage is the payoff. An 85 percent saving on a component that costs $19 a month is $16 a month. Size the prefix, multiply by volume, and only then decide whether it justifies the work. This is the same discipline our ROI guide applies to the whole deployment.

Expecting to find the setting on a packaged platform. Prompt caching is an API-level feature. If you are on a packaged platform that bills you in conversations, contacts or AI credits, you are not touching it and cannot — the vendor may or may not be using it behind the scenes and will not tell you. It becomes yours to control at the point you take on your own model key. Our BYOLLM entry and BYOLLM chatbot guide cover that boundary; the three pricing models guide covers which billing shape you are actually on.

Quoting a saving from a launch post. The whole middle of this page is one worked example of why. Check the current pricing table for the specific model you are calling, on the date you are calling it, and note that Google has already published a rate change dated 1 January 2027.

Confusing it with anything that reduces what you send. Caching does not shorten your prompt and it does not free context-window space. Whether it relieves rate limits is one of the places the vendors diverge, and carrying one vendor's rule to another will cost you: OpenAI states that cached input tokens still count toward tokens-per-minute limits, while Anthropic lists improved rate-limit utilization as a reason to choose its one-hour cache, "because cache hits are not deducted against your rate limit." If your problem is a full window rather than a large bill, this is the wrong tool either way, and our companion guide on reducing chatbot costs covers the levers that are.

Related terms

• Chatbot context window — the capacity constraint caching is most often confused with, and does not relieve.
• System prompt — usually the largest single thing in a cacheable prefix.
• Large language model — the thing being billed, and the reason the minimums differ per model.
• BYOLLM — the arrangement under which any of this is yours to control.
• Retrieval-augmented generation — the layer whose per-query documents belong behind the cache boundary, not in front of it.
• Chatbot knowledge base — what goes in the stable half of the prompt.
• Function calling — tool definitions sit at the top of the invalidation hierarchy.

FAQ

What is prompt caching?

It is a billing and latency feature that stores the processed form of the unchanged opening of your prompt, so that later requests reusing that identical opening are charged a reduced input rate on the reused portion. On their current flagship models all three major vendors price the reused tokens at one tenth of their base input rate, though OpenAI's own documentation still says rates and discounts vary by model on anything before GPT-5.6. It changes nothing about the model's output — OpenAI's documentation states that the model still computes a fresh response and that identical requests are not guaranteed to return identical text.

How much does prompt caching save?

On a warm cache, up to about 90 percent of the input cost of the cached portion, approached asymptotically as reuse rises: 32.5 percent across two requests sharing one live entry, 78.5 percent across ten, 87.7 percent across fifty, on the 0.1× read and 1.25× write multipliers the arithmetic on this page uses. It saves nothing on output tokens, which are usually the larger half of the bill, and nothing on the varying tail of each request.

Is prompt caching a 50% discount?

Not any more, and it is worth knowing which direction the error runs. The 50 percent figure comes from OpenAI's announcement of 1 October 2024, which is still live and priced gpt-4o at $2.50 uncached against $1.25 cached. OpenAI's current documentation gives 0.1× for GPT-5.6 and later — a 90 percent discount rather than 50, so a cached token costs five times less — and says rates vary by model for earlier ones. It also introduces a cache-write charge of 1.25× that did not exist in 2024.

Can prompt caching increase my bill?

Yes, and this is the least-discussed thing about it. A cache write costs 1.25 times a normal input token on the five-minute setting and twice on Anthropic's one-hour setting. A live entry is refreshed free every time it is read, so one write can serve an unbroken chain of requests — but if any consecutive pair arrives further apart than the lifetime, the chain breaks and the next request writes again. On the five-minute default that means gaps under five minutes and at least two requests in the chain; on OpenAI's GPT-5.6 window, gaps under thirty minutes; on Anthropic's one-hour setting, gaps under an hour and at least three requests, because the write is twice as expensive.

What is the minimum prompt length for caching?

There is no single answer, which is the problem with the 1,024-token figure in circulation. Anthropic's floor ranges from 512 tokens on Opus 5 to 4,096 on Opus 4.5 and Haiku 4.5. OpenAI treats 1,024 as a strict minimum on GPT-5.6 and later and says earlier models vary between 1,024 and 2,048. Google requires 4,096 on the current Flash models and 2,048 on Gemini 2.5. Check the model you are actually calling, and note that Anthropic's documentation states a sub-minimum request is processed without caching and no error is returned.

Why is my cache hit rate zero?

Almost always because something in the prefix changes between requests. The usual culprits, in rough order of frequency: a timestamp or session ID rendered into the cached section; an edit to a tool definition, which invalidates everything below it; summarizing or truncating conversation history, which rewrites the prefix you were trying to reuse; retrieved documents arriving in a different order; and a prefix that never reached the model's minimum length in the first place, which fails without an error. Read the usage fields back — if both the write and read counts are zero, nothing was cached at all.

Does prompt caching help with a full context window?

No. Cached tokens occupy exactly as much of the window as uncached ones. On rate limits the vendors disagree: OpenAI states that cached input tokens still count toward tokens-per-minute limits, while Anthropic says cache hits are not deducted against your limit and lists that as a reason to use its one-hour cache. Either way, caching is a price change rather than a capacity change. If the window is your constraint, the tools are summarization, retrieval and trimming — and note that all three break the cache.

Do I get prompt caching on a chatbot platform like Tidio or Chatbase?

Not as a control you can see. Prompt caching is an API-level feature between an application and a model vendor. If your platform bills you in conversations, contacts, messages or AI credits, whatever caching happens is the platform's business and does not appear on your invoice as a line you can influence. It becomes yours the moment you bring your own model key.

Is prompt caching a privacy risk?

Anthropic and OpenAI both address it directly and in similar terms; Google's caching documentation does not, which is itself worth knowing. Anthropic and OpenAI state that caches are isolated between organizations, and Anthropic additionally isolates per workspace on most platforms. Anthropic states that prompt caching is zero-data-retention eligible, that raw prompt text is not stored, and that key-value representations and hashes are held in memory only rather than at rest. OpenAI notes that its in-memory policy holds entries in volatile memory and that organizations with zero data retention enabled default to that policy rather than the 24-hour one. As always, read the vendor's current data terms rather than this paragraph.

Sources

• Anthropic. Prompt caching, Claude Platform documentation, read in full 22 August 2026 — the source of every Anthropic figure on this page. Specifically: the pricing multipliers, stated on the page as "5-minute cache write tokens are 1.25 times the base input tokens price", "1-hour cache write tokens are 2 times the base input tokens price" and "cache read tokens are 0.1 times the base input tokens price"; the per-model price rows used in the dollar example (Claude Sonnet 5 at $2/MTok base input, $2.50 5-minute cache write, $4 1-hour cache write, $0.20 cache hits and refreshes, $10 output); the minimum cacheable prompt lengths for the active models — 512 tokens for Opus 5, Fable 5 and Mythos 5, 1,024 for Opus 4.8, Sonnet 5, Sonnet 4.6 and Sonnet 4.5, 2,048 for Mythos Preview and Opus 4.7, and 4,096 for Opus 4.6, Opus 4.5 and Haiku 4.5, with the doc's retired Opus 4.1, Opus 4, Sonnet 4 and Haiku 3.5 rows omitted here as out of scope; the statement that sub-minimum requests "will be processed without caching, and no error is returned"; that the default cache has a five-minute lifetime "refreshed for no additional cost each time the cached content is used" and that the lifetime "is measured from the start of the request that writes or reads the cache entry, not from the end of its response"; the statement, given as a reason to prefer the one-hour cache, that it improves rate-limit utilization "because cache hits are not deducted against your rate limit"; the note that "a cache entry only becomes available after the first response begins" and that parallel requests should wait for the first response if they need hits; the limit of four cache breakpoints and the 20-block lookback window; the named common mistake of placing a breakpoint on a block containing a timestamp; the invalidation table in which tool-definition changes invalidate the tools, system and message caches while tool_choice changes and image changes affect message blocks; the warning that Swift and Go may randomize key order during JSON conversion and break caches; the usage fields cache_creation_input_tokens, cache_read_input_tokens and the note that input_tokens counts only tokens after the last breakpoint; workspace-level and organization-level cache isolation; and the data-retention statement that the feature is ZDR eligible, that raw prompt text is not stored and that key-value representations and hashes are held in memory only and not stored at rest. platform.claude.com
• OpenAI. Prompt caching, API documentation, read in full 22 August 2026 — the source of every current OpenAI figure, and of the contrast with the 2024 announcement below. Specifically: that caching "works automatically for eligible requests, with no code changes required"; the strict 1,024-token minimum on GPT-5.6 and later against "1,024 to 2,048 tokens, depending on the model" on earlier ones; the multipliers "cached input tokens are billed at 0.1× the uncached input token rate" and "tokens written to the cache are billed at 1.25× the uncached input token rate", together with the note that the 1.25× rate "is the total rate for written tokens" rather than a surcharge; the statement for earlier models that "creating a cache entry has no additional fee" and that "rates and discounts vary by model"; the 30-minute lifetime on GPT-5.6+ which "refreshes whenever the prefix is reused" without a further write charge, against 5 to 10 minutes of inactivity and a one-hour maximum under the in-memory policy; that extended 24-hour retention is priced the same as in-memory ("prompt cache pricing is the same for both policies") and that organizations with zero data retention default to in-memory; the sentence "if you set mode to explicit but provide no explicit breakpoints, the request does not use prompt caching or incur cache-write charges", which this page reads together with implicit being the default and labels as a reading rather than a vendor statement; the exact-prefix rule and its extension to "images and tools, which must be identical between requests"; the guidance that "changing, deleting, or reordering earlier content changes the prefix and can cause a cache miss" and that "context truncation, summarization, and compaction can reduce prompt size, but they can also reset the reusable prefix"; the note that tool ordering and structured-output schema keys contribute to the prefix; the usage fields cached_tokens and cache_write_tokens and their differing containers across the Responses and Chat Completions APIs; that "cached input tokens still count toward tokens-per-minute rate limits" and caching "does not change rate-limit calculations or guarantee identical model outputs"; that "manual cache clearing is not currently available"; the requirement that "for GPT-5.6, you must set prompt_cache_key to use the more reliable matching" together with the instruction to "keep the total traffic across all prefixes for each key to approximately 15 requests per minute"; and that "prompt caches are not shared between organizations." The string "50%" does not appear anywhere in this document. developers.openai.com
• OpenAI. Prompt Caching in the API, announcement post dated 1 October 2024, read 22 August 2026 and still live at the URL below — the traceable origin of the "50 percent" figure still in circulation. Specifically: "by reusing recently seen input tokens, developers can get a 50% discount and faster prompt processing times"; the pricing table giving gpt-4o-2024-08-06 at $2.50 uncached against $1.25 cached, gpt-4o-mini at $0.15 against $0.075 and o1-preview at $15.00 against $7.50, every row exactly half; the automatic application "on prompts longer than 1,024 tokens" with the cache growing "in 128-token increments"; the cached_tokens field within usage; and that caches "are typically cleared after 5-10 minutes of inactivity and are always removed within one hour of the cache's last use." Cited as a dated historical statement, not as a current price. The post carries no correction notice and has not, as far as we can tell, been altered. openai.com
• Google. Context caching, Gemini API documentation, page footer stating "Last updated 2026-08-13 UTC", read 22 August 2026 — the source of the Gemini minimums and of the API restriction. Specifically: that implicit caching "is enabled by default for all Gemini 2.5 and newer models"; the minimum input token table giving 4,096 for Gemini 3.7 Flash, 3.6 Flash, 3.5 Flash and 3.1 Pro Preview and 2,048 for Gemini 2.5 Flash and 2.5 Pro; the note that "the Interactions API only supports implicit caching" and that explicit caching requires the generateContent API; the guidance to place large common content at the beginning and send similar-prefix requests close together; and the response field usage.total_cached_tokens. This page states no discount percentage and no cache lifetime, which is why the rate figures above are cited to the pricing page instead. ai.google.dev
• Google. Gemini API pricing, read 22 August 2026 — the source of the Gemini rate figures. Specifically: Gemini 3.7 Flash Standard input at $0.75 per million tokens through 31 December 2026 rising to $1.50 from 1 January 2027, context caching at $0.075 rising to $0.15, and a storage price of $0.50 per million tokens per hour rising to $1.00 on the same date; and Gemini 3.1 Pro Preview Standard input at $2.00 for prompts up to 200k tokens with context caching at $0.20 and storage at $4.50 per million tokens per hour, with the Batch tier marked "Same as Standard" for caching against a halved $1.00 batch input price. The one-tenth read ratio quoted in this entry's comparison table was computed by us from those two model rows and is not a Google statement; we checked two models and do not assert it holds across the whole catalog. ai.google.dev
• Chatbotscape break-even model — the crossover table, the three-row gap-and-chain-length table (gaps under 5, 30 and 60 minutes for the three cache windows; two requests to repay a 1.25× write and three to repay a 2× write), and the monthly dollar figures for an 8,000-token prefix on Claude Sonnet 5 are all our own arithmetic on the published multipliers, shown in full so they can be checked rather than presented as a measurement. We have not run this workload. The model counts input tokens on the shared prefix only: it excludes output tokens, excludes the varying tail of each request, assumes a byte-identical prefix across requests, assumes evenly spaced traffic rather than a realistic arrival distribution, assumes a live entry is refreshed free on every read as all three vendors document, takes no account of Anthropic's rule that an entry becomes available only once the first response begins (so a burst of simultaneous requests writes many entries rather than one), takes no account of OpenAI's roughly 15-requests-per-minute ceiling per cache key, and ignores the latency benefit entirely. Every one of those simplifications is stated where the figures appear. The structural result generalizes; the specific dollar amounts depend entirely on the prefix size, model and volume assumed.
• Content-corpus and codebase string counts, run 22 August 2026 before this entry was saved, published so they reproduce. grep -ril "prompt caching" --include="*.md" ./glossary ./academy ./best ./news ./sample-reviews matched zero files at the time of the count. After this publishing run the same command matches seven: this entry, the same-day companion guide academy/reduce-chatbot-costs-guide.md, and the five existing pages this run added a link from — glossary/chatbot-context-window.md, glossary/system-prompt.md, glossary/byollm.md, academy/byollm-chatbot-guide.md and academy/manage-chatbot-context-window.md. No glossary entry defined the term. A second command, grep -ril "prompt caching" web/src, matched four files — web/src/app/tools/openai-api-pricing-calculator/page.tsx, web/src/app/tools/llm-api-cost-calculator/page.tsx, web/src/components/tools/OpenAiCalculator.tsx and web/src/data/openai-pricing.json — which is how the four errors on our own calculator, disclosed in the body of this entry, were found. Unscoped from the repository root the string also matched four internal planning documents — tools-roadmap.md, tools-launch-priority-v3.md, 00-analysis-and-roadmap.md and a version backup of the last of those — none of which is published. Published as a transparency statement about a gap in our own coverage: we shipped a BYOLLM guide, a token counter and two API cost calculators, one of them carrying four inaccuracies about this feature, before giving it a definitional entry of its own.
• Ahrefs Keywords Explorer, US overview and volume-by-country, queried 22 August 2026 — the search-demand, difficulty, parent-topic and country-split figures in this entry's keyword note, including the checks behind declining 'context window', 'token cost', 'llm inference cost' and the two cost-optimization terms that went to the companion guide instead.
• Chatbotscape evaluation methodology. /methodology (continuously updated).