The Cache Write Tax

Two of the three labs now charge you to try

On July 9, OpenAI's newly priced GPT-5.6 family started charging 1.25x the standard input rate the first time a prompt is written into cache. No earlier GPT model did that. Source: OpenAI, "Prompt caching," API documentation. Anthropic has charged that same style of premium since prompt caching became generally available: 1.25x the base input rate for a 5-minute cache, 2x for a one-hour cache, on every model including Claude Fable 5. Source: Anthropic, "Pricing," Claude Platform Docs. DeepSeek's disk-based cache, running since August 2024 and carried into V4, charges neither. A cache write costs exactly the standard rate, whether or not anything ever reads it back. Source: DeepSeek API Docs, "DeepSeek API Introduces Context Caching on Disk". Two of the three labs that set frontier pricing now bill you for attempting to save money, independent of whether the attempt works.

The three-way split, as of this month

Prompt caching only has one job: store the tokens behind a repeated prefix so the next request that shares it skips full-price reprocessing. How each provider prices the first write to that cache is where the three diverge.

DeepSeek runs a two-tier system: a request either hits the cache or it doesn't, and a miss costs exactly what an uncached request would have cost anyway. DeepSeek's own numbers put the average unoptimized user's savings above 50% and first-token latency on a repeated 128K prompt dropping from 13 seconds to roughly 500ms, with no code change required and no separate line item for the write. OpenAI and Anthropic both run a three-tier system: a standard rate, a discounted read, and now, on both, a premium write that costs more than doing nothing would have.

Why the premium almost always pays for itself

The write tax is not, by itself, a bad trade. Anthropic's own pricing documentation states the break-even directly: "caching pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)." Source: Anthropic, "Pricing," Claude Platform Docs. The arithmetic is simple once it's written out: a 5-minute write costs 0.25x more than doing nothing, and a single subsequent read at 0.1x the standard rate saves 0.9x relative to sending that prefix at full price again. One read clears the tax with room to spare. The same shape holds for GPT-5.6: a 1.25x write is covered by one 0.1x-priced read.

So for the workload prompt caching was built for, a system prompt, a tool schema block, a long document that gets referenced across many turns of the same session, the premium is close to irrelevant. It gets paid once and forgotten. The place the tax actually bites is a workload most teams don't think of as a caching decision at all.

The tax lands on the prefix nobody reads twice

Every cache write is a bet that something will read the same prefix again before the window closes: 5 minutes, 30 minutes, or an hour, depending on provider and setting. When that bet loses, on Anthropic or OpenAI, you didn't just fail to save money. You paid 25 to 100% more than if you had never tried to cache at all.

That bet loses more often than the marketing around prompt caching implies. A few concrete cases where it does:

• Per-session system prompts. Any agent that bakes user-specific state, a user ID, a personalization block, retrieved memory, into the system prompt has a prefix that's structurally unique to that session. It never gets a second reader.
• Bursty or low-traffic endpoints. This blog has already covered how a Deep Research-style agent's cost profile swings wildly by task; a request that arrives once every 20 minutes on a service with a 5-minute cache window pays the write premium on every single call, because nothing else arrives inside the window to read it back.
• Exploratory and one-off API calls. Development traffic, internal tooling, ad hoc analysis scripts. None of it repeats, all of it gets marked cache_control anyway because a template or SDK default turned caching on globally.
• GPT-5.6's shorter guaranteed window. OpenAI's older models held a cache for up to 24 hours; GPT-5.6 guarantees only 30 minutes by default. Source: OpenAI, "Prompt caching," API documentation. A shorter window means fewer opportunities for a second read to arrive before the bet expires, which raises the odds of eating the premium for nothing on exactly the traffic pattern that used to be safe to cache.

None of these are exotic. They're the default shape of agentic and multi-tenant traffic, which is precisely the traffic most teams reach for cache_control to fix first.

Why DeepSeek's cache can't lose

The structural difference is what matters more than any single number in the table above. DeepSeek's caching decision has no downside because there's nothing to decide: every request is billed at the miss rate unless it happens to match, and the miss rate is the same as if caching didn't exist. DeepSeek's docs are explicit that matching is exact-prefix, from the 0th token, so there's no partial credit and no manual tuning, just automatic detection running underneath a stable, unchanged price.

Anthropic and OpenAI both require an active choice: mark a cache_control breakpoint, pick a TTL, and take on the write premium as the price of that bet. Anthropic's automatic-caching mode manages the breakpoints for you, which removes the manual tuning step but not the underlying wager, since the system is still guessing at what's worth caching rather than pricing the guess out of existence the way DeepSeek's model does.

This is the same tradeoff that shows up everywhere else in LLM cost engineering: a technique that's free to attempt and only pays off on a hit beats one that costs something to attempt regardless of outcome, even when the second one's best case is better. The same principle is why a verifier-gated router beats one that guesses blind: the value isn't in the upside, it's in removing the downside of being wrong.

What changes about how you should cache

• Don't mark everything `cache_control` by default. On a provider that charges a write premium, that habit taxes every one-shot prefix in your traffic for the benefit of the ones that repeat.
• Estimate reuse probability before you cache, not after. A system prompt shared across every request in a tenant is a safe bet. A prefix built per-session, per-user, or per-request usually isn't.
• Match the TTL to your actual traffic rate. A 5-minute Anthropic cache on an endpoint that sees a request every 8 minutes is a guaranteed loss. The 1-hour tier costs more to write but is the safer default for lower-traffic paths, precisely because it has more time to find a second reader.
• Prefer automatic, no-downside caching where the workload allows it. If routing can send a request to a provider whose cache write costs nothing extra, that removes the reuse-prediction problem entirely for that slice of traffic instead of asking an engineer to guess correctly every time.
• Track cache-write-to-cache-read ratio as its own metric. A high ratio of writes to hits is the signal that cache_control is being applied somewhere it shouldn't be, and it's invisible in a bill that just shows total spend.

None of this requires new infrastructure, just a routing layer that already knows the shape of the request before it decides where to send it:

import openai

client = openai.OpenAI(
    base_url="https://api.getnadir.com/v1",
    api_key="ndr_...",
)

# A prefix flagged as low-reuse-probability (per-session state, a one-off
# tool result, dev traffic) routes to the cheapest path with no write
# penalty. A prefix flagged as shared across a tenant, a system prompt,
# a static tool schema, still gets cached where the premium is worth it.
response = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": prompt}],
)

Same call shape as talking to any OpenAI-compatible endpoint. Nadir routes each request to the cheapest model and provider that can handle it, and reports the routing and caching decision per request in the response metadata, so the reuse bet this post describes stops being a guess an engineer makes once at integration time and becomes a decision made fresh on every request.

What to actually ship this week

• Audit your `cache_control` calls for prefixes that are unique per session or per user. Those are the ones paying the write tax with no chance of a matching read.
• Check your provider's current cache pricing before assuming last year's numbers still hold. GPT-5.6 changed the calculus for OpenAI traffic this month; assume the next model generation, on any provider, can change it again.
• Set the TTL to match measured request inter-arrival time, not a copy-pasted default. A 5-minute window is wasted on any endpoint slower than one request per 5 minutes.
• Route low-reuse-probability traffic to a provider whose write costs nothing extra, rather than disabling caching on it entirely and losing the upside on the requests that do repeat.

Conclusion

Prompt caching is still one of the highest-leverage cost levers in production LLM engineering; nothing here argues otherwise. What changed this month is that the two labs that set frontier pricing both now charge a fee to place that bet, and GPT-5.6 joining Anthropic in doing so means the majority of frontier-tier traffic is now priced this way by default. The fix isn't to stop caching. It's to stop treating cache_control as a free toggle and start treating it as what it now is on two of the three major providers: a wager with a real cost when it loses, next to at least one provider whose cache can't lose at all.

Related reading

• Prompt caching cuts repeated-context cost up to 90%, and most teams still aren't using it right.
• DeepSeek V4 matches frontier benchmarks at a fraction of the price. Here's what that changes about routing.
• Semantic caching catches the requests prefix caching misses.
• Round-robin routing was built for stateless servers. LLM inference isn't stateless.
• Every major provider's pricing, in one table.
• The Memory Tax: persistent AI memory has the same cache-invalidation problem, at a much larger scale.

Sources: [DeepSeek API Docs, "DeepSeek API Introduces Context Caching on Disk," August 2, 2024](https://api-docs.deepseek.com/news/news0802/). [Anthropic, "Pricing," Claude Platform Docs](https://platform.claude.com/docs/en/about-claude/pricing). [OpenAI, "Prompt caching," API documentation](https://developers.openai.com/api/docs/guides/prompt-caching). [OpenAI, "Pricing," API documentation](https://developers.openai.com/api/docs/pricing).