OpenAI API Can Now Keep Prompt Caches for 12 Hours - Writes Cost 2.5x the Input Rate

On October 20, 2026, OpenAI announced in its API changelog that developers can now opt for a 12-hour prompt cache¹. The option is part of the Responses API. OpenAI describes it as a way to hold shared instructions, tool definitions and context in the cache for longer, so that the cheaper cached-input rate still applies when calls are spread hours apart. The trade-off is the write price: a 12-hour write costs 2.5 times the input rate.

The default lifetime is 30 minutes, and the 12-hour lifetime applies only when you request it explicitly². Whether it saves money depends on how often, and at what spacing, the same prefix is sent.

Only the Write Price Differs Between 30 Minutes and 12 Hours

According to OpenAI’s guide, on GPT-5.6 and later models a cache write is billed at 1.25 times the input rate for the default 30 minutes, and at 2.5 times when 12 hours is chosen in the Responses API. Reading from the cache costs a tenth of the input price for most of these models, or one twentieth for GPT-6.1 Sol, and this does not depend on the chosen lifetime².

Setting	Minimum lifetime	Write rate	Read rate
"30m" (default)	30 minutes	1.25x input	0.1x input (0.05x on GPT-6.1 Sol)
"12h"	12 hours	2.5x input	Same as above

The guide notes that these multipliers are not a fee added to regular input; they are the full price of the tokens that get written. The lifetime is set per request with prompt_cache_options.ttl, and each explicit breakpoint can override it with prompt_cache_breakpoint.ttl. This is a separate parameter from prompt_cache_retention, which GPT-5.5 and earlier models use, and the new setting leaves that parameter untouched.

The pricing page lists the following rates per million tokens (standard processing, short context)³.

Model	Input	Cached read	30-minute write	12-hour write
GPT-6 Astra	$10.00	$1.00	$12.50	$25.00
GPT-6.1 Sol	$2.00	$0.10	$2.50	$5.00
GPT-6 Luna	$0.10	$0.01	$0.125	$0.25

Writing a shared 100,000-token prefix on GPT-6.1 Sol therefore costs $0.25 with the 30-minute lifetime and $0.50 with 12 hours, after which each read costs $0.01.

The Deciding Factor: How Many Times Across Gaps Longer Than 30 Minutes

In its guide, OpenAI suggests weighing the higher 12-hour write price against what it costs to write the prefix again once the 30-minute coverage has run out². For the 30-minute setting, the guide’s example uses are chats and agent loops that keep coming back to the same context. Every read pushes the 30-minute window out so that it ends no earlier than half an hour after that read.

The question is what happens when the same prefix arrives with gaps of more than 30 minutes. Taking the input rate as 1 and working from the guide’s multipliers, here is the cost of sending a prefix n times within 12 hours at such intervals: with 30 minutes it is rewritten every time, while with 12 hours only the first send is a write.

Sends	30 minutes	12 hours
1	1.25	2.50
2	2.50	2.60
3	3.75	2.70

Up to two sends, 30 minutes is cheaper; from three onward, 12 hours wins. On GPT-6.1 Sol, where reads cost 0.05x, two sends come to 2.50 versus 2.55, so the crossover stays the same.

The guide positions 12 hours for fixed instructions and reference documents that are picked up again after long pauses. Its example puts material used all day at the front of the prompt with a 12-hour breakpoint, and gives the more volatile per-session context a 30-minute one². An internal assistant that is called on and off during working hours, or a setup that places long internal policies or product documents at the top of every request, would likely fit this pattern.

Upgrades Get No Credit, and the Lifetime Is Not a Guarantee

The guide spells out several conditions worth checking before switching².

• No credit when upgrading from 30 minutes to 12 hours. If a valid 30-minute entry is upgraded to 12 hours, those tokens are charged as a fresh 12-hour write, and the earlier write is not deducted. It is better to decide on 12 hours when the prefix is first written
• Do not write the parts that change every time. In explicit mode, whatever follows the final breakpoint you chose is billed as ordinary input and incurs no write charge. Writing content that will not be reused, such as the user’s question, only means paying the higher write rate for it
• The minimum lifetime does not promise reuse. What the lifetime controls is whether a request qualifies for the cached-read rate; it does not ensure the cache is reused on every call or that latency drops
• Twelve hours is not a deletion deadline either. OpenAI may keep entries beyond the requested minimum, and "12h" neither sets a point at which data is deleted nor changes the data-retention ceiling. There is currently no way to clear the cache manually

In the usage response, write tokens are split into ttl_30m_tokens and ttl_12h_tokens. Together with the prompt caching dashboard released in August, this shows how many writes of each kind are happening.

Caching Terms Shape the Bill

Changes around caching in OpenAI’s API have come one after another over roughly the last two months. In August a dashboard made hit rates visible. With the release of GPT-6 Sol and Luna in September, changing reasoning effort or turning tools on and off stopped breaking the cache. On GPT-6.1 Sol, the cached-read price dropped from $0.20 to $0.10. This update adds a choice of lifetime on top of those.

A table of input and output prices alone makes these differences hard to see. Checking in the usage data how far apart the same prefix is being sent, and attaching 12 hours only to prefixes that are visibly being rewritten after the 30-minute coverage lapses, is likely the least wasteful approach on cost.

Sources

1. API Changelog - OpenAI (entry for October 20, 2026)
2. Prompt caching - OpenAI API guide
3. Pricing - OpenAI API pricing