OpenAI Prompt Caching Pricing: When 12 Hours Pays

OpenAI prompt caching pricing has three input categories to watch: ordinary input, cache writes, and cached-input reads. As of October 20, 2026, the listed flagship rates charge 1.25 times ordinary input for a 30-minute write and 2.5 times ordinary input for a 12-hour write. Cached reads cost less; the exact rate depends on the model and processing tier.

Long retention reduces your bill when those cheaper reads recover the higher write cost. For the Standard flagship rates below, one 12-hour write followed by two cached reads beats three ordinary-input uses of the same tokens. But choosing 12 hours over 30 minutes requires another comparison: how many shorter-retention writes would it actually prevent?

OpenAI prompt caching pricing at a glance#

As of October 20, 2026, the official OpenAI pricing page lists these Standard rates per million tokens.

Read each write column as the rate for tokens billed as cache writes. The 12-hour write rate is 2.5 times the ordinary input rate, rather than ordinary input plus another 2.5 times that rate.

The discount applies to tokens billed as cached input. Don't apply it to the entire request just because some shared context was reused. Keep changing input and generated output in separate cost categories.

As of October 20, 2026, the pricing page also lists separate Batch, Fast, and Ultrafast tables. Use rates from the same model and tier throughout your calculation. For applicable regional processing endpoints, the page lists a 10% uplift. A Standard-rate estimate won't capture those differences.

Model choice still matters. If you're comparing the two lower-cost flagship options, the GPT-6.1 Sol versus GPT-6 Luna comparison is a useful companion to the caching calculation.

What the 2.5x write price buys#

The October 20, 2026 OpenAI changelog announces 12-hour prompt caching in the Responses API. It describes keeping shared instructions, tools, and context cached longer so requests hours apart can benefit from cached-input pricing.

That gives you a practical decision: pay more to write shared context, then try to reuse it enough times to justify the premium.

Think of a support assistant with a substantial instruction set and a shared reference document. The reusable portion might stay constant while each customer's question changes. Your cost estimate should track the shared portion separately from those changing questions.

There are two distinct comparisons:

• Caching versus ordinary input: Does paying for a write and subsequent reads beat paying ordinary input every time?
• Long retention versus shorter retention: Does the higher write price prevent enough additional writes to lower total cost?

A workload can pass the first comparison and fail the second. Frequent reuse can make caching valuable while giving you little reason to pay for longer retention. Conversely, requests separated by hours are the use case the new retention option is intended to help.

Calculate the break-even against ordinary input#

Use these variables for one fixed block of reusable tokens:

• T: the number of tokens in that block.
• I: ordinary input price per million tokens.
• W: cache-write price per million tokens.
• C: cached-input price per million tokens.
• R: successful cached reads after the initial write.

The comparison is:

Ordinary input cost = T / 1,000,000 × (R + 1) × I
Cached block cost  = T / 1,000,000 × (W + R × C)

Caching costs less when:
R > (W - I) / (I - C)

This calculation covers only the shared block. It assumes one write, successful subsequent reads, and the same token count on every use. Add changing input and output separately when estimating the complete workload.

For the Standard rates dated October 20, 2026, the listed flagship models all need two successful reads after a 12-hour write to beat ordinary input for three uses. One subsequent read doesn't recover the write premium.

You can check the comparison without an API key. This example expresses costs relative to one ordinary-input use of the shared block, so its results are cost units rather than currency:

models = {
    "GPT-6 Astra": 0.10,
    "GPT-6.1 Sol": 0.05,
    "GPT-6 Luna": 0.10,
}

for model, read_ratio in models.items():
    print(model)
    for reads in range(4):
        ordinary = 1 + reads
        cached = 2.5 + reads * read_ratio
        print(
            f"  reads={reads}: ordinary={ordinary:.2f}, "
            f"12h={cached:.2f}, cheaper={cached < ordinary}"
        )

The ratios come from the dated Standard pricing table. A larger shared block increases the absolute financial effect, but it doesn't change this break-even read count because T cancels from both sides.

The catch is the word successful. Three requests aren't automatically one write and two reads. If the shared context isn't reused, the assumed savings disappear.

Compare 12-hour retention with 30-minute retention#

Ordinary input is a useful baseline, but it may not be your actual alternative. If you're already getting cache reuse with shorter retention, compare the two caching strategies directly.

For an illustrative GPT-6.1 Sol calculation using the October 20, 2026 Standard rates, normalize ordinary input to one unit. A shorter-retention write costs 1.25 units, a longer-retention write costs 2.5 units, and a cached read costs 0.05 units.

Suppose the same shared block is used six times. Under a simplified model where every use is billed entirely as either a write or a read:

In this example, the longer-retention option becomes cheaper when it replaces three shorter-retention writes with one write. Replacing only two shorter-retention writes doesn't quite justify it, because the longer-retention scenario also pays for an extra read.

Run the comparison with different assumed write counts:

uses = 6
long_cost = 2.5 + (uses - 1) * 0.05

for short_writes in range(1, uses + 1):
    short_reads = uses - short_writes
    short_cost = short_writes * 1.25 + short_reads * 0.05
    print(
        f"30m writes={short_writes}: "
        f"30m units={short_cost:.2f}, "
        f"12h units={long_cost:.2f}, "
        f"12h cheaper={long_cost < short_cost}"
    )

These are hypothetical billing patterns, not predictions of cache behavior. The calculation assumes the longer-retention option achieves one write followed by reads. If it also incurs repeated writes, update that side of the comparison.

I'd start with measured writes and reads for each reusable context block. Request volume alone is a weak reason to choose longer retention: a busy application can still have many unrelated prompts.

Common mistakes that inflate OpenAI API cost#

Counting requests instead of token categories. A request may contain reusable context and fresh input. Estimate the reusable block independently, then add the rest of the request. Don't treat the entire prompt as a cache hit.

Treating write pricing as cached-read pricing. Writes are the expensive part of this tradeoff. A low cached-input rate doesn't make an unused cache economical. Repeated writes can outweigh the savings from occasional reads.

Assuming longer retention fixes every cache miss. As of October 20, 2026, the changelog says Prompt Cache Diagnostics is generally available in the Responses API for supported GPT-5.6 and later models. It can compare reuse against a previous response and identify reasons for cache misses. Investigate those reasons before paying more for retention.

Measuring only hit rate. As documented in the August 20, 2026 changelog entry, the Prompt Caching dashboard tracks hit rate, cache reads per write, and cache-read, cache-write, and uncached tokens. It also supports filtering by model and service tier. Reads per write and token volumes are especially useful for this pricing decision.

Assuming every model uses the same caching behavior. The April 24, 2026 changelog entry says GPT-5.5 supports extended prompt caching only and doesn't support in-memory prompt caching. Check the named model's current documentation before carrying assumptions across models.

Copying another provider's configuration. If you're comparing implementations, the Claude prompt caching walkthrough provides a separate reference. Keep its configuration and billing assumptions separate from this OpenAI calculation.

What an OpenAI prompt caching example can establish#

A cost calculator can demonstrate the economics, but it can't prove that your API requests produce cache hits. That requires observed usage from the actual workload.

As of October 20, 2026, the cited changelog announces the 12-hour option without showing its request setting or accepted value. The pricing page supplies rates, not a complete request example. Neither excerpt provides enough request syntax to build a dependable activation snippet here.

Before changing production requests, check the current Responses API documentation linked from the changelog for the exact configuration. Then use diagnostics and dashboard measurements to verify what gets billed as writes, reads, and uncached input.

For a useful evaluation, choose one reusable context block and record its token volume, number of writes, number of reads, model, and tier over a representative workload. Compare the observed shorter-retention cost with a longer-retention scenario that makes explicit assumptions about avoided writes.

Keep output costs visible, too. Caching savings on shared input can be meaningful while representing only a small part of the complete request bill. The right metric is total cost for the workload you need to serve.

Quick reference before choosing longer retention#

Use this checklist when reviewing a proposed caching change:

• Confirm the current model and processing-tier rates on the official pricing page.
• Separate reusable context from changing input and output.
• Count successful reads after each write, rather than total requests.
• Compare against your existing retention strategy as well as ordinary input.
• Use diagnostics to investigate misses before attributing them to retention.
• Include any applicable regional processing uplift in the final estimate.
• Recalculate when the model, tier, context, or request pattern changes.

For the Standard flagship rates dated October 20, 2026, two reads after one 12-hour write beat ordinary input for those three uses. Choose longer retention when the writes it avoids also justify its premium over your shorter-retention option.

Quick answers