OpenAI Prompt Caching: When the 12-Hour Option Saves Money

OpenAI's 12-hour prompt cache saves money over the 30-minute default once a prefix would otherwise lapse and trigger more than two cache writes across a 12-hour window. A 12-hour write costs 2.5 times the normal input rate while a 30-minute write costs 1.25 times that rate, making two 30-minute writes equal to one 12-hour write.

At Layer3Labs, we help teams build and cost agent workflows.

OpenAI's prompt caching guide documents the 12-hour time to live (TTL) option for GPT-5.6 and later models in the Responses API, for prompts reused across longer gaps.

The Break-Even Rule for Prompt Caching

OpenAI prompt caching with a 12-hour lifetime beats the default 30-minute lifetime whenever your workflow requires more than two cache writes in 12 hours. Every write multiplier applies directly to your model's uncached input-token rate, so you can calculate cost thresholds without converting to dollar figures.

A 30-minute cache write costs 1.25 times the standard input rate, while a 12-hour cache write costs 2.5 times the standard input rate. Two 30-minute cache writes total 2.5 times the input rate (1.25 multiplied by 2 equals 2.5), which exactly ties the cost of a single 12-hour write. If an idle gap exceeds 30 minutes and forces a third write, the 30-minute strategy reaches 3.75 times the input rate (1.25 multiplied by 3), making the 12-hour write cheaper.

Cache reads cost 0.1 times the base input rate on most supported models and 0.05 times on GPT-6.1 Sol, per OpenAI's prompt caching guide. Reads cost the same under either lifetime, so the difference comes from writes. At exactly two writes the write costs tie, and the 30-minute option can still come out slightly cheaper in total, because a 12-hour entry means one write and one extra read, as the two-burst row shows.

Comparison of Prefix Reuse Scenarios

The table shows each scenario's total cost as a multiple of the prefix's ordinary input cost. It is our arithmetic from OpenAI's published multipliers, using the 0.1 times read rate (GPT-6.1 Sol's 0.05 times rate would lower every figure). We assume every request reuses the full prefix. Each burst is five requests sent within a few minutes, and a 12-hour entry stays valid across the span between the first and last request.

When requests arrive every 10 minutes, the 30-minute entry refreshes continuously and never lapses, requiring only one initial write at 1.25 times the prefix cost. When requests arrive every 45 minutes, the 30-minute entry expires between each call, causing 16 separate writes totaling 20 times the prefix cost.

Configuration in the Responses API

You configure cache lifetime in the Responses API by defining the prompt_cache_options object with a ttl value of either '30m' or '12h'. Omitting prompt_cache_options preserves the default 30-minute minimum lifetime. Supplying any unsupported lifetime value causes the API to return a 400 invalid_request_error.

Setting ttl at the request level applies that lifetime to the implicit breakpoint at the end of the prompt and to any explicit breakpoints that lack their own setting. You can override the request-level policy on a specific prefix by setting prompt_cache_breakpoint.ttl directly on that breakpoint.

OpenAI's guidance is to put material reused all day first and give it the 12h lifetime, and to use 30m for session context that changes more often. In explicit-only mode, the current question sits after the last breakpoint, so that content does not incur a cache-write charge.

Unchanged Terms and Read Multipliers

Selecting the 12-hour lifetime does not increase the cost of reading cached tokens. Cache reads remain 0.1 times the standard input rate on most models, or 0.05 times the standard input rate on GPT-6.1 Sol, under both the 30-minute and 12-hour settings.

A 12-hour value is a minimum cache lifetime, and OpenAI may retain entries longer than that. Choosing 12h leaves OpenAI's maximum data retention policy unchanged.

These write and read rates represent total billing rates rather than surcharges on top of standard input tokens. OpenAI notes that while prompt caching charges these published rates, it does not guarantee that every single call reuses stored Key-Value (KV) tensors or delivers reduced latency. If you need to size GPU hardware memory rather than calculate API bills, our KV-cache calculator provides memory estimates for self-hosted models.

Cache Layering and Upgrade Rules

When a prompt combines multiple cached blocks, OpenAI bills each token once at the longest lifetime among the selected writes covering that token. If you submit a prompt that upgrades an active 30-minute cached prefix to a 12-hour lifetime, the API charges a full 12-hour write at 2.5 times the input rate without crediting the earlier 30-minute write fee.

Any portion of a prompt already covered by a valid 12-hour entry continues to be billed as a cache read. A 30-minute read operation refreshes coverage for at least 30 minutes following that read. If that read accesses tokens protected by an active 12-hour entry, the system maintains the later of the original expiry timestamp or 30 minutes after the read.

Excluded Workflows and Model Constraints

The 12-hour cache option does not help workflows with prompt prefixes that fall below a model's minimum cacheable length. For GPT-5.6 and later models, OpenAI calculates the minimum cacheable length by excluding hidden tokens and rounding down to a multiple of 128 tokens.

Older models released before GPT-5.6 use the prompt_cache_retention parameter instead of prompt_cache_options.ttl. Its 24h option is supported only on some models. To review prefix lengths and model compatibility, inspect OpenAI's prompt caching guide before adjusting your API parameters.