OpenAI added a 12-hour prompt cache to the Responses API on October 20, 2026, and one of its Codex leads says logged-in users of Codex and ChatGPT Work now get their cache kept "forever." The API change is documented, with a price: cache writes at the 12-hour setting cost 2.5x the normal input rate. The "forever" claim for Codex and Work comes from a single post on X and does not yet appear in OpenAI's docs.
This is a claimed-versus-verified breakdown. It separates what OpenAI's API changelog and prompt caching guide state from what was said on X, and works through when the new option pays off. It sits inside the daily improvement sprint we have been tracking in the 28-days Codex post and the Astra 28-day log.
Quick reference: claimed vs. verified
| Question | Answer | Status |
|---|---|---|
| Is there a 12-hour cache option in the API? | Yes, in the Responses API via prompt_cache_options.ttl | Verified in the OpenAI changelog and docs |
| What does a 12-hour write cost? | 2.5x the uncached input-token rate | Verified |
| What does a 30-minute write cost? | 1.25x (the default) | Verified in the docs |
| What do reads cost? | 0.1x on most GPT-5.6+ models, 0.05x on GPT-6.1 Sol, for either lifetime | Verified in the docs |
| Which models? | GPT-5.6 and later, Responses API | Verified in the docs |
| Do Codex and Work keep cache "forever" for logged-in users? | Stated by an OpenAI Codex lead on X | Announced, not documented |
| Is a cache hit guaranteed? | No: OpenAI says a valid lifetime does not guarantee every request reuses cached state | Verified in the docs |
What OpenAI actually shipped in the API
The changelog entry dated October 20 is short. It says developers can now choose 12-hour prompt caching in the API, that it keeps shared instructions, tools and context cached longer to benefit from lower cached-input pricing "even when requests are hours apart," and that 12-hour cache writes cost 2.5x the input token price.
The longer explanation is in the prompt caching guide. Prompt caching stores the model's key-value (KV) tensors for a reusable prefix, not the tokens themselves, so a later request that starts with the same prefix skips recomputing it. Only the new tail of the prompt is processed fresh.
For GPT-5.6 and later, the guide describes two lifetimes:
ttl value | Minimum lifetime | Write rate | Best for |
|---|---|---|---|
"30m" (default) | 30 minutes | 1.25x uncached input | Conversations and agent steps that reuse context often |
"12h" | 12 hours | 2.5x uncached input | Stable instructions or reference material reused across longer gaps |
Reads are billed at 0.1x the ordinary input rate on most of these models and 0.05x on GPT-6.1 Sol, regardless of lifetime. Our GPT-6.1 Sol launch post has the launch prices: $2 input, $0.10 cached input, $2.50 cache write and $10 output per million tokens, which matches the 1.25x write multiple on a $2 base.
How to turn it on
The setting lives in a new prompt_cache_options object on Responses API requests. The docs show a mixed-lifetime pattern that is worth copying: put material that is reused all day at the start of the prompt with a "12h" breakpoint, and put session context that changes quickly behind a "30m" one.
{
"model": "gpt-6.1-sol",
"prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
"input": [
{
"role": "developer",
"content": [
{
"type": "input_text",
"text": "Shared instructions and reference material...",
"prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" }
}
]
}
]
}
A few mechanics from the guide that change the economics:
- Up to four cache writes per request. In implicit mode the automatic breakpoint uses one of those four slots.
- Content after the last explicit breakpoint is not written. In explicit-only mode the current question is billed at the plain uncached rate with no write charge, so you do not pay to cache text that will never be reused.
- Overlap is billed once, at the longest lifetime. If a 12-hour write covers an earlier 30-minute breakpoint, those tokens are billed at the 12-hour rate once.
- Upgrading is not credited. Turning valid 30-minute coverage into 12-hour coverage charges a fresh 12-hour write with no credit for the earlier one.
- A read can refresh the clock. A 30-minute read refreshes coverage to at least 30 minutes after that read, but does not restart a 12-hour clock or trigger another write charge.
The docs also say the minimum cacheable prefix is 1,024 visible input tokens for GPT-5.6 and later, and that cached state lives on individual machines, so traffic above about 15 requests per minute can overflow to other machines and miss.
Does the 2.5x write price pay off?
OpenAI's own worked numbers use the default option: writing a prefix once and fully reusing it once costs 1.35x its ordinary input cost against 2x without caching, and one write plus nine reads costs 2.15x against 10x. Apply the same arithmetic to the 12-hour option at the 0.1x read rate and the break-even is easy to compute yourself.
| Scenario (prefix of 100K tokens, 0.1x reads) | 30-minute option | 12-hour option |
|---|---|---|
| One write, no reuse | 1.25x | 2.5x |
| One write, one reuse inside 30 minutes | 1.35x | 2.6x |
| Write, then reuse every hour for 8 hours (9 requests) | A fresh 1.25x write whenever the entry lapsed, so up to 9 writes: 11.25x | One 2.5x write plus 8 reads at 0.1x: 3.3x |
| No caching, 9 requests | 9x | 9x |
Those multiples are our arithmetic on OpenAI's published rates, not an OpenAI benchmark. They show the pattern: if requests arrive more than 30 minutes apart, the 30-minute entry keeps expiring and you pay the write charge again each time, which can end up costing more than no caching at all. The 12-hour option turns that into a single write.
The inverse is true too. If your agent loops every few seconds, the default 30-minute lifetime already keeps the entry warm through reads, and paying 2.5x instead of 1.25x on the write buys you nothing.
Cost optimization coin stack shrinking, illustrating prompt caching cost savings on reused prefixes
The "cache forever" claim for Codex and Work
The second half of the announcement is about OpenAI's own products. The post is from Tibo Sottiaux, who has been announcing one improvement per day during the 28-day sprint. His Day 16 post on X, as quoted in the OpenAI developer forum thread, reads: "You can now cache for 12h in the API and for logged in users across Codex & Work we keep cache forever and you don't have any penalty for coming back to an old conversation or resuming after a few hours and are now guaranteed to hit the cache."
What we could verify:
- Verified: the API changelog entry and the prompt caching guide for the 12-hour option.
- Verified: the Day 16 post exists on X from Sottiaux's account and is mirrored in the OpenAI Developer Community thread.
- Not found: any page in the Codex or Work docs that describes an indefinite cache, a guarantee of a cache hit, or what "logged in" excludes (for example API-key use).
- In tension with the API docs: the guide says "Cache entries are not stored indefinitely" for API models and that a valid lifetime "does not guarantee that every request reuses stored KV tensors." The product behavior may differ because OpenAI controls both the client and the serving side, but the sprint post does not explain how, and "forever" is almost certainly shorthand for "no time pressure from the user's side" rather than literal permanent storage.
In practical terms, read it as: in Codex and Work, resuming an old conversation should no longer trigger a cold, full-price re-read of the history. Whether that shows up as less quota burn is the thing to measure. Our earlier post on dots Pro usage limits being halved shows why that matters: quota is the pain point for heavy agent users.
Why long-running agents care
The changelog frames the feature as keeping shared instructions, tools and context cached "even when requests are hours apart," which is the situation persistent agents that stay alive through the day are in. We have not independently confirmed any savings figure; the reasoning is straightforward though.
An ambient agent wakes on events: an email at 9:00, a calendar change at 11:40, a message at 15:10. Each wake-up resends the same system prompt, tool definitions and memory. With a 30-minute cache that prefix is stone cold at every wake-up, so you pay a write each time. With a 12-hour entry, the first event pays 2.5x and the rest of the day reads at 0.1x or 0.05x.
This also changes how you structure prompts. Keep the stable material first (instructions, tool schemas, reference documents), then per-session context, then the live question. Reordering, editing a tool description or switching reasoning.effort mid-prefix can break the match, as the docs' settings table lists. For effort changes, the docs point to a configuration update that preserves the earlier prefix.
For background on why agent loops are so token-hungry and how speed and cost trade off, see what tokens per second means and the cost-per-task comparison of Sol and Astra.
Agent session resume bookmark between two sections, resuming an old Codex conversation against a warm prompt cache
What to do this week
- Measure before switching. Use the Prompt Caching Dashboard and the Prompt Cache Diagnostics tool the docs point to, which can compare cache reuse against a previous response and list reasons for misses.
- Find prefixes with long gaps. Look for large shared prefixes that are reused more than 30 minutes apart. Those are the candidates for
"12h". - Leave tight loops on the default. Anything called every few seconds keeps its own cache warm.
- Isolate tenants. The docs recommend separate
prompt_cache_keyvalues for customers or users to keep cache accounting separate and to prevent cache-hit probing across users. - Do not treat it as a retention setting. The guide says
"12h"does not set a deletion deadline or change maximum data-retention policy, and OpenAI may keep entries longer than requested. - Codex and Work users: try resuming an old thread and watch your usage meter. If the numbers do not match the claim, say so to OpenAI; the lack of docs means there is nothing to hold them to yet. Our post on Codex Composer Predictions and the free Codex Auto-Review follow the same sprint.
How this fits the sprint
Day 16 is one of a stream of small, practical changes: Ultrafast mode for Sol and Astra, pre-warmed sandboxes billed only during active turns, and simplified API tiers, all listed in the changelog. Caching is the least glamorous and arguably the biggest for anyone who pays per token. The sprint's general pattern, though, is that many items are announced on X first and documented later, so the right habit is to check the changelog and docs before changing a billing-sensitive setup.
What we still do not know
- Whether the Codex and Work behavior is literally unbounded or a very long internal TTL.
- Whether it applies to API-key use of Codex or only to ChatGPT-login sessions.
- Whether the cache-hit guarantee extends to long conversations after compaction, which the docs say can prevent reuse from the first changed token onward.
- Real-world savings numbers from third parties. No hands-on measurements were available when we published.
We will add an update section when OpenAI documents the Codex and Work behavior or when measurements appear.
Related reading
- OpenAI Codex 28 days: daily improvement or reset
- OpenAI Astra 28 days of updates: day-by-day log
- GPT-6.1 Sol launch, pricing and benchmarks
- GPT-6.1 Sol vs Astra cost per task
- dots Pro usage halved
- Codex Composer Predictions
- Tokens per second explained
- Official: OpenAI API changelog and prompt caching guide
Specs and prices are as of October 21, 2026 and may change; check OpenAI's pricing page before you commit.