On this page · 11 sections
Summary. On 20 August 2026 OpenAI released a Prompt Caching dashboard that reports cache hit rate, cache reads per write, and the split between cache-read, cache-write and uncached tokens. That middle number is the one that matters. On GPT-5.6 and later, cache reads are billed at 0.1x the uncached input rate and cache writes at 1.25x, so a workload that writes to the cache and rarely reads back pays a 25 percent premium on every input token instead of a 90 percent discount. For gpt-5.6-sol at $5.00 per 1M input tokens, 10M input tokens a month costs $50.00 uncached, $10.75 at nine reads per write, and $62.50 if every request writes and nothing reads. Azure published a notice on its OpenAI pricing page saying cache write billing "is expected to start on or after August 21, 2026" and every rate cell on that page renders as a placeholder.
What changed, and when
The changelog entry is dated 20 August 2026. OpenAI describes the release as a dashboard where you "Track your cache hit rate over time, cache reads per write, and the breakdown of cache-read, cache-write, and uncached tokens to understand your caching efficiency and identify opportunities to improve," filtered by model and service tier.
A dashboard is not usually news. This one is, because the metric it leads with did not exist as a billing category until the GPT-5.6 family shipped. Look at the pricing table: gpt-5.5, gpt-5.4, gpt-5.2, gpt-5.1 and gpt-5 all have an empty cache-writes column. Only gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna and gpt-5.6-cyber carry a number there. Azure's documentation says the same thing plainly: "Models before the GPT-5.6 family don't charge extra to write to the cache."
So a team that moved from GPT-5.5 to GPT-5.6 Sol saw an unchanged headline input price, $5.00 per 1M tokens on both, and quietly acquired a third billing line it had never had to think about.
The arithmetic nobody published
OpenAI's caching guide states the three rates directly: "Cached input tokens are billed at 0.1x the uncached input token rate. Tokens written to the cache are billed at 1.25x the uncached input token rate. Tokens that are neither read nor written are billed at the uncached input token rate."
Set W as write tokens and R as read tokens. Caching costs 1.25W + 0.10R in units of the input rate; not caching costs W + R. Those are equal when 0.25W = 0.90R, which is R/W = 0.278.
You need more than 0.28 read tokens for every write token before caching beats not caching at all. Below that line the cache is a cost centre. At a ratio of zero, where a timestamp or a changing user message sits before the implicit breakpoint and every request rewrites the prefix, you pay a flat 25 percent surcharge on input tokens for no benefit whatsoever.
Here is the same thing in dollars, on gpt-5.6-sol standard short-context rates ($5.00 input, $0.50 cached input, $6.25 cache writes per 1M tokens), for a workload consuming 10M input tokens a month:
| Cache behaviour | Token split | Monthly input cost | Versus no caching |
|---|---|---|---|
| No caching at all | 10M uncached | $50.00 | baseline |
| Every request rewrites, nothing reads | 10M written | $62.50 | +25.0% |
| 1 read per write | 5M written, 5M read | $33.75 | -32.5% |
| 4 reads per write | 2M written, 8M read | $16.50 | -67.0% |
| 9 reads per write | 1M written, 9M read | $10.75 | -78.5% |
On gpt-5.6-terra ($2.00 / $0.20 / $2.50) the same shapes give $20.00, $25.00 and $4.30. In Fast mode, renamed from Priority processing on 30 July 2026, gpt-5.6-sol runs at $10.00 input, $1.00 cached and $12.50 cache writes, so every figure above doubles. The Fast mode guide confirms the discount survives the tier: "Cached input discounts still apply to Fast mode requests." It says nothing at all about cache writes.
Three vendors, three incompatible shapes
The interesting part is not that OpenAI charges for writes. Anthropic has done so for a long time and says so in a table. The interesting part is how differently the three large providers publish the same cost.
| OpenAI direct | Anthropic Claude | Azure OpenAI | |
|---|---|---|---|
| Cache write rate | 1.25x input, published | 1.25x for 5-minute, 2x for 1-hour, published | Charge confirmed, rate not published |
| Cache read rate | 0.1x input, published | 0.1x input, published | "a discount on input token pricing", no figure |
| Cache lifetime | 30m, "the only supported value" | 5 minutes or 1 hour | 30m on GPT-5.6+; earlier models in-memory or 24h |
| Break-even guidance | none published | "caching pays off after one cache read for the 5-minute duration" | none published |
| Minimum cacheable prefix | 1,024 tokens | 512 to 4,096 tokens depending on model | 1,024 tokens |
| Storage meter | none | none | none |
Google is a fourth shape again. The Gemini API bills context caching as a discounted per-token read plus a storage meter charged by the hour. Gemini 3.7 Flash caching storage is "$0.50 / 1,000,000 tokens per hour (storage price) through December 31, 2026" and "$1.00 / 1,000,000 tokens per hour (storage price) starting January 1, 2027". Gemini 3.1 Pro Preview charges $4.50 per 1M tokens per hour, or $8.10 on Priority. A cache you hold open and rarely hit costs Google money by the clock and costs OpenAI money only once.
Anthropic is the only one of the four that tells you where the line is. Its pricing page states: "A cache hit costs 10% of the standard input price, which means caching pays off after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)." OpenAI shipped a dashboard instead of that sentence.
Where OpenAI contradicts OpenAI
OpenAI's original Prompt Caching announcement, dated 1 October 2024, is still live and still canonical. Three of its statements are now wrong for GPT-5.6, and nothing on the page says so.
| The 2024 announcement says | The 2026 documentation says |
|---|---|
| "developers can get a 50% discount" | cache reads are billed at 0.1x input, a 90 percent discount |
| "Prompt Caching is automatically applied" with no write charge | cache writes are billed at 1.25x the uncached input rate |
| "Caches are typically cleared after 5-10 minutes of inactivity" | prompt_cache_options.ttl accepts only 30m, which is also the default |
A team costing a GPT-5.6 migration from that announcement page would model a 50 percent saving, budget no write charge, and size its cache reuse window to ten minutes. All three inputs are wrong in the same direction.
Azure's version of the problem is different and, today, sharper. Its Foundry documentation confirms the charge exists: "On GPT-5.6 models and later model families, cache writes can incur charges in addition to discounted cache reads." Its FAQ repeats it. Both then send you to the Azure OpenAI pricing page for the number. As fetched on 21 August 2026, that page renders a Cache writes column for the GPT-5.6 series only, every rate cell in it reads $-, and the page carries this notice: "Cache write charges are not active yet, so they will not appear on your bill at this time. Billing is expected to start on or after August 21, 2026."
That date is today. Azure customers on GPT-5.6 deployments should assume a new billing line lands this month at a rate they cannot currently look up.
What actually breaks, and how to tell if it is you
Three GPT-5.6 behaviour changes turn a working cache strategy into an expensive one.
The prefix-matching fallback is gone. OpenAI's guide is explicit that GPT-5.6 caches exact prefixes at breakpoints and, "Unlike earlier models, it does not automatically fall back to the longest matching unmarked prefix before that breakpoint." Code written against GPT-5.4 behaviour will still run and will silently stop hitting the cache.
prompt_cache_key is now load-bearing. "For GPT-5.6, you must set prompt_cache_key to use the more reliable matching for both implicit and explicit caching." Without it you get best-effort hits and none of the improved matching, while still paying for writes.
The implicit breakpoint writes whether you want it or not. In implicit mode the service places a breakpoint on the latest user or tool message. Put a timestamp, a session ID or any per-request content before it and you generate a fresh cache write on every call. OpenAI's own troubleshooting section names this: "If cache_write_tokens stays high while cached_tokens remains low, check whether an implicit breakpoint includes content that changes between requests."
Check your own numbers rather than assuming. Read cached_tokens and cache_write_tokens from the usage block on live traffic, or open the new dashboard and look at cache reads per write. If that ratio sits below 0.28, you are paying more than you would with caching switched off.
Turning it off is a documented single-line change. Set prompt_cache_options.mode to explicit and add no explicit breakpoints: "the request does not use prompt caching or incur cache-write charges." Note that this path needs a Standard pay-as-you-go deployment on Azure; provisioned throughput deployments do not support breakpoints, and models before GPT-5.6 return a 400 if you send the parameter at all.
The limits that will bite at scale
Four hard numbers appear in both the OpenAI and Azure documentation and constrain any high-volume design. Each request can create at most four new cache writes, and if you set more than four breakpoints only the last four are written. In implicit mode the latest message consumes one of those four slots. For reads, the service considers up to the latest 50 breakpoints in the conversation and reads from the longest matching prefix. And traffic for a single prompt_cache_key should stay near 15 requests per minute: above that, Azure states, "some requests might miss the cache."
That last one is the trap for anyone who partitioned a large workload behind one shared key to maximise hit rate. Past roughly 15 requests per minute the strategy inverts. Use stable, deterministic keys such as session or user identifiers and let the traffic spread.
One more constraint applies only to GPT-5.6 and is easy to miss on a migration: Azure documents that "On GPT-5.5 and earlier models, cache hits after the first 1,024 tokens occur in 128-token increments. This rounding doesn't apply to GPT-5.6 models and later model families." A prefix that used to round up into a hit now has to match exactly.
India-specific considerations
Regional processing endpoints carry "a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." That uplift multiplies the cache-write rate along with everything else, so gpt-5.6-sol cache writes land near $6.88 per 1M tokens on a residency endpoint rather than $6.25. Teams keeping inference inside India for DPDP-aligned data residency reasons therefore pay a slightly larger penalty for a badly placed breakpoint than teams on global endpoints.
Azure's residency position is narrower than it first looks. In-memory prompt caching is compatible with all data residency regions, but extended prompt caching "temporarily stores data on GPU machines," staying inside the data zone boundary for Data Zone deployments and the regional boundary for Regional deployments. If your DPDP posture depends on a specific regional boundary, the deployment type decides whether extended caching is available to you at all.
What is still unknown
Azure has not published a cache-write rate, so nobody outside Microsoft can model an Azure GPT-5.6 caching bill today. OpenAI's Fast mode guide does not mention cache writes even though the pricing table charges $12.50 per 1M for them on gpt-5.6-sol. And the 2024 announcement page remains live and uncorrected, which means the first result many engineers reach for still says caching has "no additional fees".
The honest engineering read: the cache is now a decision with a wrong answer, not a free optimisation. Measure the ratio before you assume which side of it you are on.
FAQ
How eCorpIT can help
Most teams discover a caching problem in a monthly invoice rather than in a metric. Our senior engineering teams instrument LLM traffic so cache reads, cache writes and uncached tokens are separated per route before the bill arrives, which is the same work described in our AI evaluation and observability service. If you are moving from GPT-5.5 to GPT-5.6, or weighing the same workload across providers as in our Bedrock versus direct OpenAI cost comparison, we can model the reads-per-write ratio against your real traffic first. Talk to us via /contact-us/.
Related reading: the GPT-5.6 price cut and Fast mode migration, the Assistants API shutdown on 26 August 2026, and mid-conversation tool changes and the Claude prompt cache.
References
Last updated: 21 August 2026.
