# OpenAI prompt caching after GPT-5.6: free writes are over

*Cache writes now cost 1.25× on OpenAI's flagship line, and the default breakpoint lands on the most volatile part of your prompt. There's no TTL to tune. The whole optimisation is where you draw the boundary.*

---

For two years the received wisdom about OpenAI caching was that it was free and automatic: prefixes over 1,024 tokens cached themselves, you got a discount on hits, and there was nothing to configure. That was true, and it was the explicit counter-design to Anthropic's opt-in markers.

It is no longer how the flagship line is billed. On GPT-5.6 and later, [cache writes are billed at 1.25× the uncached input token rate and reported in `cache_write_tokens`](https://developers.openai.com/api/docs/guides/prompt-caching) — the same multiplier Anthropic charges on its 5-minute tier. Breakpoints are developer-placeable. And the matching behaviour changed underneath in a way that can drive your write volume up rather than down.

> **Compatibility note.** On models before the GPT-5.6 family, cache writes have no additional fee, there are no explicit breakpoints, and retention is selected with `prompt_cache_retention` — [in-memory, roughly 5–10 minutes of inactivity up to a one-hour ceiling, or extended retention up to 24 hours at the same price](https://developers.openai.com/api/docs/guides/prompt-caching). If that's your fleet, caching is free and automatic and there is nothing to decide. Everything below assumes 5.6+.

Vocabulary in [the glossary](/updates/llm-prompt-caching-what-it-is-and-key-terms-explained); the cross-provider chart is in [pricing 101](/updates/llm-prompt-caching-pricing-guide-and-cost-breakdown).

## The default that costs money

> **The trap:** the implicit breakpoint lands on your *latest* message — the one that always changes.

This is the most important paragraph in the piece. On GPT-5.6 and later, the service [places an implicit breakpoint at the latest user or tool message, and unlike earlier models it does not automatically fall back to the longest matching unmarked prefix before that breakpoint](https://developers.openai.com/api/docs/guides/prompt-caching).

Read that against the pre-5.6 behaviour it replaced. Older models hunted backwards for whatever stable prefix they could find. Current models write an entry at the boundary you were given, and if that boundary includes a timestamp or a fresh user message, the prefix hash differs every single time. OpenAI spells out the consequence: `cached_tokens` can be zero while the service writes the changing prefix again — at 1.25×.

So a workload with 4,000 tokens of rock-stable instructions can report zero cache reads and a steady stream of billable writes, purely from the default. The fix is one field: `prompt_cache_breakpoint: { "mode": "explicit" }` on the last block of the stable content. And if the changing suffix shouldn't be cached at all, set `prompt_cache_options.mode` to `explicit` to switch off the implicit breakpoint entirely — [only the breakpoints you provide are then used for reads and writes](https://developers.openai.com/api/docs/guides/prompt-caching).

One gotcha in that fix: setting `mode: "explicit"` with no explicit breakpoints means the request uses no caching at all and incurs no write charges. Silent, not an error.

## TTL isn't a lever here

> **Cost shape:** 30 minutes, refreshing on reuse, and no way to change it.

`prompt_cache_options.ttl` accepts exactly one value, `30m`, which is also the default. The lifetime [begins when the prefix is written and refreshes whenever the prefix is reused](https://developers.openai.com/api/docs/guides/prompt-caching), and OpenAI may retain it longer. Crucially, **reusing a cached prefix refreshes its lifetime without another write charge** — the same free-refresh mechanic Anthropic has, on a window six times longer.

That eliminates an entire category of decision. There's no cadence bet to make and nothing to gain from keep-alive pinging. It also means OpenAI is structurally cheaper than Anthropic for medium-gap orchestration: a sub-agent that takes eight minutes is comfortably inside the window with no premium to pay, where Anthropic would want the 2× tier.

The honest limitation: above 30 minutes of silence you have no lever at all. Anthropic sells you an hour; OpenAI doesn't sell you anything.

## The throughput ceiling nobody expects

`prompt_cache_key` moved from optimisation to requirement — on GPT-5.6 [you must set it to use the more reliable matching](https://developers.openai.com/api/docs/guides/prompt-caching) for both implicit and explicit caching. Without it you may still get hits, but not the improved matching.

Attached to that key is a constraint with no equivalent at either other provider: **keep total traffic per key to approximately 15 requests per minute, or some requests miss.** For higher volumes you partition across more keys with a stable mapping so requests sharing a prefix keep sharing a key.

Fifteen requests a minute is 900 an hour. Plenty of production workloads clear that against a single shared system prompt, and the symptom — hit rate degrading as volume climbs — looks like a caching bug rather than a documented ceiling.

## Scenario one: the orchestrator waiting on sub-agents

> **Verdict:** works by default under 30 minutes. Above it, nothing to do.

A 12-minute gap between orchestrator turns is a non-event: the prefix is inside the window, the read refreshes it free, and you pay one write for the whole run. The same workload on Anthropic's 5-minute tier would be re-paying writes at every turn.

Two things to get right. First, the orchestrator's prefix accumulates tool results and sub-agent output — so the *stable* part is the instructions and tool definitions at the front, and that's where the explicit breakpoint belongs. Leaving it implicit puts the boundary on the latest tool message, which changes constantly.

Second, [each request can create up to four new cache writes, breakpoints from earlier turns are read-only, and reads consider up to the latest 50 breakpoints](https://developers.openai.com/api/docs/guides/prompt-caching). That 50-breakpoint read window is generous — considerably more headroom than Anthropic's 20-block lookback — so growing conversations degrade less gracelessly here.

## Scenario two: the fast sub-agent

> **Verdict:** free win, provided the key is shared correctly.

Tight loops with seconds between turns sit deep inside the 30-minute window. One write, reads thereafter, refreshing continuously. After a single read the cached path is already ahead — 1.25 + 0.1 = 1.35× against 2.0× uncached for two requests — and by ten requests you're at 0.215× per request on the cached portion.

The failure here is fan-out. Dispatch twenty sub-agents in parallel against one `prompt_cache_key` and you're at the throughput ceiling immediately, and cold-start races mean several may write the same prefix simultaneously. Shard the key by sub-agent role or worker ID, keep the mapping deterministic, and warm one instance before fanning out.

## Scenario three: the chatbot

> **Verdict:** the one place implicit caching is genuinely right.

OpenAI's implicit mode is designed for exactly this shape, and the docs say so: [implicit caching works well when a conversation grows by appending new messages and the earlier history stays the same](https://developers.openai.com/api/docs/guides/prompt-caching). Each turn reads the previous prefix and writes the newly appended content at the latest breakpoint. Nothing to configure.

Use `prompt_cache_key` as a session or user ID — that's the documented pattern, and it doubles as your throughput partition, since one user rarely exceeds 15 requests a minute.

The thing that breaks it is context management. [Truncation, summarisation, and compaction reduce prompt size but can reset the reusable prefix](https://developers.openai.com/api/docs/guides/prompt-caching). Compact a long conversation and you've thrown away every cached token in it — a smaller prompt at full price, which may or may not be a win. It's a real trade and worth measuring rather than assuming.

## Scenario four: high-volume single-shot extraction

> **Verdict:** the worst-case for the default, and the best case once fixed.

Thousands of independent documents, identical instructions and schema, no shared conversation history. This is precisely the pattern OpenAI's docs single out as *not* working under implicit caching — separate requests with different content at the boundary, no history in common.

Left on the default, every request writes a fresh prefix at 1.25× and reads nothing. You have converted a workload that would have cost 1.0× per request into one costing 1.25×, for a 25% penalty, by turning on a feature. Fixed with an explicit breakpoint after the instructions plus explicit-only mode, the same workload runs at roughly 0.1× on the cached portion.

Then the second problem: at extraction volumes you are far past 15 requests per minute. One key will start missing. Shard deterministically — hash the document ID into N keys — and keep N stable, because a remapping invalidates the routing that makes the whole thing work.

Third, structured outputs. [A structured output schema contributes to the reusable prefix](https://developers.openai.com/api/docs/guides/prompt-caching), and so do tool definitions and their ordering. Extraction pipelines change schemas more often than they change instructions, and every schema edit is a full cache reset. Version them deliberately.

## What to log

`cached_tokens` and `cache_write_tokens`, in `input_tokens_details` on Responses or `prompt_tokens_details` on Chat Completions. The useful measurement is not hit rate — it's the **ratio between them**.

High writes with low reads is the signature of a breakpoint on changing content, and it's now a billable pathology rather than a curiosity. OpenAI names it directly: if `cache_write_tokens` stays high while `cached_tokens` stays low, check whether an implicit breakpoint is capturing content that changes between requests.

Reads and writes both nonzero is normal in implicit mode — a request can read an earlier prefix and write newly appended content at the same time. That's the mode working as designed, not a bug.

Note also that [cached input still counts toward tokens-per-minute rate limits](https://developers.openai.com/api/docs/guides/prompt-caching). This is the opposite of Anthropic, where hits are exempt. If you were counting on caching as a throughput lever, it isn't one here.

## The default is now the expensive one

For two years the right answer on OpenAI was to do nothing. On GPT-5.6 and later, doing nothing places a cache boundary on your most volatile content and bills you 1.25× to write it, repeatedly.

That's the whole story. There's no TTL to optimise, no tier to buy, no keep-alive to schedule. There is one field to set and one key discipline to maintain, and getting both right moves the same workload from a 25% surcharge to a 90% discount.

Next: [Gemini](/updates/llm-prompt-caching-gemini-how-to-and-pro-tips), where writes are free and you pay rent instead.

*Coolhand Labs tracks inference pricing across providers, including cache-write tiers introduced mid-generation. [See what we track](https://coolhandlabs.com/inference-apis).*