TL;DR: On October 20, 2026, OpenAI added a 12-hour prompt cache option to its API. In the Responses API, on GPT-5.6 and later models, you can now ask OpenAI to keep a cached prompt prefix for at least 12 hours instead of the default 30 minutes. A 12-hour cache write costs 2.5x the normal input price, against 1.25x for a 30-minute write, while cache reads cost the same for both. By our math, if your requests reuse the same long prefix but arrive more than 30 minutes apart, the 12-hour option starts saving money from the third request.
What happened
OpenAI’s API changelog entry for October 20 says: “You can now choose 12-hour prompt caching in the API.” The OpenAI Developers account announced it on X at 17:56 UTC (1:56 a.m. Manila time on October 21), pointing to persistent agents “like dots” that “reuse context throughout the day.”
According to OpenAI’s prompt caching guide:
- Where it works: the Responses API, on GPT-5.6 and later models. You set
prompt_cache_options.ttlto"12h"for the whole request, or setttlon an individualprompt_cache_breakpoint. Leaving both out keeps the default"30m". Unsupported values return a400error. - What it costs: cache writes cost 1.25x the standard input-token rate for 30 minutes, and 2.5x for 12 hours. OpenAI says these are “total write rates, not surcharges on top of ordinary input.” Reads cost 0.1x the input rate on most of these models and 0.05x on GPT-6.1 Sol, whichever lifetime you picked.
- Minimum size: a prefix has to be at least 1,024 tokens on GPT-5.6 and later before it can be cached.
- Mixing lifetimes: you can give shared material, such as instructions and tool definitions, a 12-hour breakpoint and newer conversation content a 30-minute one in the same request.
- Older models don’t change: models before GPT-5.6 still use the
prompt_cache_retentionsetting (in_memoryor24h), and OpenAI says the new settings don’t affect it.
When 12 hours is worth it
The question is simple: how often would your prefix expire and get written again?
| Requests reusing the same prefix, more than 30 min apart (within 12 h) | 30-minute cache (new write each time) | 12-hour cache (one write, then reads at 0.1x) |
|---|---|---|
| 1 | 1.25x | 2.5x |
| 2 | 2.5x | 2.6x |
| 3 | 3.75x | 2.7x |
| 10 | 12.5x | 3.4x |
The figures are multiples of what that prefix would cost as ordinary input once, and they’re our arithmetic from OpenAI’s published rates, not OpenAI’s numbers. They assume the whole prefix is reused, and that each 30-minute entry has expired before the next request. If your requests come more often than every 30 minutes, the default already works: a 30-minute read refreshes the entry for at least another 30 minutes, so a steady stream of traffic keeps the cheap cache alive without paying 2.5x.
In practice, 12 hours suits things like a support or sales assistant with a long system prompt that gets a handful of questions spread across the working day, a daily reporting agent that runs every few hours, or an internal tool used in bursts. If a prefix is used only once or twice a day, the longer cache costs about the same or more.
What to watch
- Switching costs a full write. OpenAI says upgrading a valid 30-minute entry to 12 hours “charges a new 12-hour write for those tokens, without credit for the earlier write.”
- Reads don’t reset the 12-hour clock. A later read keeps whichever expiry is later, the existing one or 30 minutes after the read, and doesn’t buy another 12 hours.
- It’s a price rule, not a speed promise. OpenAI says the lifetime decides eligibility for cache-read pricing and “does not guarantee” that every request reuses the cache or runs faster.
- Retention: OpenAI says prompt caching may store encrypted key/value data in GPU-local storage as application state, and that
"12h"doesn’t set a deletion deadline or change its maximum data-retention policy. If your organization has Zero Data Retention, check which settings apply to you before you switch.
What to do
- Find your repeated prefixes. Look for requests that send the same long instructions, tool lists or reference text, and check how far apart they arrive.
- Put stable material first. Caching works on prefixes, so instructions and tools that rarely change should come before anything specific to the user or session.
- Mark only the shared part as 12 hours. Use a 12-hour breakpoint for the stable prefix and keep newer conversation content on 30 minutes.
- Measure it. Compare cached-token counts and your bill for a few days before and after. If you’re also setting budget limits on agents, see our guide to hard spending limits for AI agents.
For another recent OpenAI API change, see our story on prompt-to-voice for all API customers.
Sources & method
Sources
- OpenAI API changelog, Oct 20, 2026 entry
- OpenAI API docs, “Prompt caching” guide
- OpenAI Developers on X, Oct 20, 2026, 17:56 UTC
- OpenAI Developers on X, follow-up post
Method. Last checked October 21, 2026, at about 10:25 a.m. Manila time (02:25 UTC). The feature, model and API limits, rates and caching rules come from OpenAI’s changelog and prompt caching guide; the announcement time comes from OpenAI Developers’ X post. The cost table is our own arithmetic from OpenAI’s published multipliers, and we haven’t measured it on live traffic. No affiliate links on this page. How we work.
Spotted an error? See our corrections policy and tell us.



