GPT-6 prompt caching: 90% off if your prefix holds

Two days after GPT-6 Sol and Luna landed, OpenAI shipped the part that actually changes your invoice. GPT-6 prompt caching now reads cached input tokens at up to a 90% discount, with higher hit rates on by default — and, more usefully, with explicit controls so you stop guessing whether you got the discount. If you run an agent loop that replays the same system prompt and tool definitions a few hundred times an hour, this is the cheapest optimization available to you, and most teams are leaving it on the table.

What actually happened

OpenAI's developer account put it plainly: improved prompt caching in the API for GPT-6, "helping agents run faster and cost less," with higher cache-hit rates by default meaning more input tokens qualify for cached-input discounts of up to 90%. OpenAI's caching guide has the mechanics, documented for GPT-5.6 and later — which includes the GPT-6 family:

• Cached reads bill at 0.1x the standard input rate. Not a rebate, a different rate.
• Retention is 30 minutes minimum, set via prompt_cache_options.ttl. Older models relied on prompt_cache_retention with an in-memory window that typically evaporated after five to ten idle minutes.
• Explicit cache breakpoints. Implicit breakpoints still fire automatically at message boundaries; prompt_cache_breakpoint lets you mark the end of the prefix you intend to reuse.
• Prewarming. Set prompt_cache_options.prewarm: true to load context ahead of the traffic that will hit it.
• 1,024 visible input tokens minimum before a prompt is eligible at all.
• A Prompt Caching Dashboard and a diagnostics tool for hit rates and miss causes.

The catch is the one it has always been: caching matches on an exact prefix. A timestamp, a shuffled tool list, a user ID injected three tokens too early — any of those and you pay full rate on everything after the divergence.

Why prompt caching matters for your business

Your agent bill is mostly the same tokens, over and over. A support triage loop or a document pipeline resends the identical system prompt, schema and tool block on every turn. That block is usually the largest part of the request and the least interesting. At 0.1x it nearly stops mattering. At full rate it is your line item.

The 30-minute window changes what "batch" means. A five-minute in-memory cache punished anything bursty — a run that paused for a phone call came back cold. Thirty minutes covers a realistic human-in-the-loop rhythm: agent drafts, someone reviews, agent continues, still warm. Reschedule your jobs to cluster inside that window rather than trickling all day.

Prefix discipline is now a design rule, not a micro-optimization. Static content first — system prompt, tools, schemas, policy text. Volatile content last — the user turn, the timestamp, the record ID. Then set an explicit breakpoint where the stable half ends. This is a refactor measured in minutes that pays every single request.

Measure it, because the dashboard makes excuses impossible. Pull your cache-hit rate before you change anything. If it is under 50% on a loop that repeats a fixed preamble, something in your prefix is moving and you can find it in the diagnostics tool. We have seen a single injected timestamp cost more than the model upgrade everyone was arguing about.

Sources: OpenAI prompt caching guide, OpenAI.