AI engineering
Pay for longer prompt caching only when reuse justifies the write
A longer-lived prefix is valuable only if useful requests reuse it. The right comparison includes writes, reads and misses, plus the output and dynamic input costs that caching does not remove.
OpenAI's 20 October changelog introduces the 12-hour prompt-caching option. The guide is the source for model-specific behaviour and prices, rather than treating that announcement as a universal saving. (OpenAI)
For supported GPT-5.6-and-later models, the guide describes 30-minute writes at 1.25 times ordinary input and 12-hour writes at 2.5 times. These are total write rates. Read rates vary by model. Twelve hours is a minimum lifetime, not a deletion deadline. (OpenAI)
Price the reusable prefix as a separate unit
Let P be the tokens in an unchanged reusable prefix, U the ordinary input price per token and r the applicable cached-read price divided by U. Keep dynamic suffix tokens and output tokens outside this first comparison: they still belong in the total application bill.
Simplified comparison against processing the same prefix uncached:
W = prefix writes
H = successful full-prefix reads
M = ordinary uncached prefix uses without a write
baseline prefix cost = P * U * (W + H + M)
cached prefix cost = P * U * (2.5*W + r*H + M)
cached cost is lower when:
H * (1-r) > W * 1.5This is an editorial cost model, not an API billing export. It assumes identical prefix size and full reuse on each counted hit. Partial hits, different breakpoints or changing instructions require a more detailed token-level calculation. The 2.5 multiplier is the total write charge in this comparison; adding ordinary input again would double-count that write.
A small numerical illustration
| Total requests | Uncached prefix units | 12-hour prefix units | Interpretation |
|---|---|---|---|
| 2: one write, one hit | 2 | 2.6 | The extra write cost has not been recovered |
| 3: one write, two hits | 3 | 2.7 | The prefix component is lower under these assumptions |
| A new write on every request | One per request | 2.5 per request | Long lifetime alone provides no reuse benefit |
The result is not a claim about your total bill. A workload with a large changing suffix or substantial output may see a much smaller total difference. Use the chosen model's current rate, not the illustrative ratio, before applying the formula.
Compare the default policy as well
Uncached processing is a useful algebraic baseline, but the default cache policy may already reuse the prefix. Compare the actual sequence under both lifetimes: which requests create a new write, which reuse it and which miss? Longer gaps help only if the longer option changes reuse enough to cover its higher write rate.
- Keep stable instructions and reference material separate from frequently changing input.
- Record actual prefix writes, read tokens, misses and request spacing from usage evidence.
- Compare the same model, task, region and input preparation over a representative workload.
- Include invalidation when reference material, tool definitions or instructions change.
Treat retention and suitability as separate checks
Before opting in, classify the material you intend to retain and obtain the appropriate organisational approval. Keep a record of the model, region and retention choice used in the estimate. A cheaper prefix calculation does not establish permission to retain sensitive material.
The useful deliverable is a repeatable cost worksheet and a policy decision, followed by observation of real usage. Custom software and internal tools should make those assumptions visible instead of quoting a guaranteed percentage saving. No benchmark, spend reduction or production configuration change was performed for this article.
Sources
- Prompt caching guide — OpenAI
- OpenAI API changelog — OpenAI