On August 21, 2026, one of the few AI optimizations that used to be a guaranteed win quietly grew a price tag. As of that date, Azure OpenAI began billing for prompt cache writes on the GPT-5.6 model family, and the direct OpenAI API made the same move. Writing a prefix into the cache, which cost nothing through GPT-5.5, now bills at 1.25x the standard input rate. Cached reads are still cheap. The write is not.
For two years, every FinOps deck and vendor cost guide told the same story: turn on prompt caching, watch your input token bill drop 50 to 90 percent, move on. That advice was correct when the cache was free to populate. It is now conditional. On GPT-5.6 and later, a cache write you never read back is pure waste, and it is waste you now pay a premium for.
This is a small line item that scales into a real number, because caching is everywhere. The 2026 State of FinOps survey found 98 percent of respondents now manage AI spend, up from 63 percent in 2025 and 31 percent in 2024, and AI cost management is now the single most requested skill FinOps teams are trying to hire. Most of those teams enabled caching under the old economics and have not looked at it since.
What actually changed with GPT-5.6
The mechanic is worth getting exact, because the whole cost calculation turns on it.
Prompt caching stores the processed computation of a stable prefix so the model does not reprocess the same tokens on every call. Per Microsoft’s documentation, a prompt has to be at least 1,024 tokens long and the first 1,024 tokens must be identical across requests for any caching to happen at all. A single character difference in that leading block is a full cache miss.
Before GPT-5.6, populating that cache was free. You paid the normal input rate on the first call, the prefix got cached as a side effect, and every matching call afterward billed the cached portion at a steep discount. The write was a freebie.
On GPT-5.6 and later, that freebie is gone. Microsoft’s own guidance now states plainly that “cache writes can incur charges in addition to discounted cache reads,” and it tells teams to structure prompts “so that reused content stays identical across requests, which favors cache reads over cache writes.” Flexera’s teardown puts a number on it: OpenAI began charging 1.25x the uncached input rate for cache writes starting with GPT-5.6, in both automatic and explicit modes. Cached reads stay discounted, roughly 90 percent off across the GPT-5.x lineup, and up to 100 percent off on Provisioned Throughput deployments.
So the shape of your AI bill flipped. The first call is now more expensive than not caching at all. You only get ahead if that prefix gets read back enough times to repay the write premium.
The three providers, side by side
Anthropic has priced caching this way from the start, so the OpenAI change is really a convergence on the model Claude users already knew. Here is how the write and read economics compare, all expressed as a multiple of each provider’s standard input rate.
| Provider / model | Cache write | Cache read |
|---|---|---|
| OpenAI, through GPT-5.5 (automatic) | Free | ~75 to 90% off |
| OpenAI, GPT-5.6 and later | 1.25x input | up to ~90% off |
| Azure OpenAI, GPT-5.6 and later | 1.25x input | discounted; up to 100% off on Provisioned |
| Anthropic Claude, 5-minute cache | 1.25x input | 0.1x input (90% off) |
| Anthropic Claude, 1-hour cache | 2.0x input | 0.1x input (90% off) |
Anthropic’s figures are the cleanest illustration of the trade. On Claude Sonnet 5 at $3 per million input tokens, a cache write costs $3.75 per million and a cache read costs $0.30 per million. That is a 12.5x gap between a miss and a hit on the same prefix, which is exactly the spread that decides whether caching pays.
The break-even nobody recalculated
Here is the math that used to be irrelevant and is now the whole game.
Without caching, every call costs 1x the input rate. With caching on GPT-5.6, the first call costs 1.25x to write the prefix, and each subsequent matching call costs about 0.1x to read it. Run that out: for N calls against a stable prefix, caching wins once N clears roughly 1.3. In plain terms, a single cache write is earned back after about two reuses of the same prefix. Read the prefix three times or thirty times, and caching still crushes the alternative.
That is why the vendor examples still look spectacular. Flexera models a support bot with a 10,000-token system prompt handling 5,000 requests a day at a 95 percent cache hit rate, and it still saves roughly 84 percent a month, about $3,790, despite paying the 1.25x write premium. When reuse is high and the prefix is stable, the write charge is a rounding error.
The problem is that not every workload looks like that support bot, and the write premium is no longer zero when the reuse assumption breaks.
Where caching now quietly costs you money
The dangerous workloads are the ones that generate cache writes without earning the reads back. Four patterns turn caching from a saving into a tax:
High-churn prefixes. If your system prompt embeds anything that changes per request inside the first 1,024 tokens, a timestamp, a session ID, a user name, a rotating instruction, every call misses the cache and pays 1.25x to rewrite a prefix that will never be read. Under the old pricing this cost nothing. Now it is a 25 percent surcharge on your entire prefix, on every single call.
Low request volume per key. Azure’s documentation warns that if requests for the same prefix exceed roughly 15 requests per minute per cache key, some will miss, and in-memory caches clear after 5 to 10 minutes of inactivity. A prefix that is written, sits idle past the retention window, then gets read is charged as a write with no offsetting hit. Sporadic, low-traffic assistants live in exactly this zone.
One-shot and batch jobs. Classification runs, bulk extraction, nightly summarization: if each item carries a unique prefix used once, you pay the write premium and never read. The old economics hid this. The new economics bill it.
Dynamic prompt assembly. Retrieval-augmented systems that rebuild the prompt from freshly retrieved chunks on every call rarely hold the first 1,024 tokens identical. They were already missing the cache; now the misses that trigger writes cost extra.
I saw a version of this months before the pricing changed, reviewing an AI vendor’s invoice during an Ops Harmony engagement. Their integration stamped a request ID into the top of the system prompt “for traceability.” Under free writes it was harmless. The same design today would add a quarter to the input cost of every call, and nobody on the finance side would know why the token bill drifted up, because the dashboard would still show tokens, not write-versus-read mix.
What FinOps teams should monitor now
The fix is not to turn caching off. For stable, high-reuse prefixes it is still one of the highest-return moves in AI cost management, and it always will be. The fix is to make the write-versus-read ratio visible and to stop paying for writes you never read.
Three concrete moves:
First, instrument the split. On GPT-5.6 and later, Standard deployments report cache reads as cached_tokens and cache writes as cache_write_tokens in the usage object. Pull both. A healthy caching workload shows reads dwarfing writes. If cache_write_tokens is a large fraction of your cached activity, you are paying the premium without collecting the discount, and that is the signal to investigate the prefix.
Second, enforce prefix discipline. Stable content goes at the front, dynamic content at the end, conversation context stays append-only. Anything variable inside the first 1,024 tokens is now a direct cost, not just a missed optimization. This is a code review item and an architecture standard, not a dashboard tweak.
Third, use the off switch where reuse is low. Azure lets you set prompt_cache_options.mode to explicit with no breakpoints, which disables caching for that request and, critically, incurs no cache-write charge. For genuine one-shot workloads, not caching is now cheaper than caching. That sentence would have been nonsense a month ago.
This is the same discipline that separates teams who measure AI spend from teams who govern it, the theme running through everything from cost per outcome instead of cost per token to AI gateway cost controls. Caching did not get worse. It got conditional. The provider changed the rules in a single pricing note, and the workloads that were quietly free riders are now quietly billable.
The teams that will feel this are not the ones running the textbook high-reuse chatbot. They are the ones who turned caching on in 2024, filed it under “done,” and never went back to check whether their prefixes actually get read. If you compare model pricing the way you would in an enterprise API cost comparison, the sticker input rate is no longer the number that matters most. The write-to-read ratio is. Go find yours before the next invoice does it for you.