OpenAI API 12 小时提示缓存怎么选：长任务什么时候真的省钱

正文

Agent 每隔几小时处理同一项目时，固定指令和参考材料可能一次次重新进入上下文。OpenAI Responses API 提供较长的提示缓存时间，但缓存写入本身有费用；选 12 小时不一定比默认策略便宜。

对支持该机制的 GPT-5.6 及后续模型，官方文档说明：在 Responses API 使用 prompt_cache_options.ttl 选择 30m 或 12h。这两个值表示最短缓存寿命，不是删除截止时间，也不保证每次请求都命中或更快。OpenAI Prompt caching 文档

30 分钟与 12 小时的价格差在哪里

选项	最短寿命	缓存写入费率	适合先评估的场景
`30m`	30 分钟	普通输入单价的 1.25 倍	请求频繁、上下文变化较快。
`12h`	12 小时	普通输入单价的 2.5 倍	相同前缀会跨较长间隔重复使用。

这两个写入费率是完整写入价格，不是普通输入价格之外再加一次。相同模型下，两种寿命的缓存读取单价相同；具体价格、长上下文和服务档位另以模型页面为准。缓存读取、写入与普通输入要分开统计。

一个成本例子：看需要重建几次

假设使用 GPT-6.1 Sol Standard、固定前缀为 10 万 token；普通输入每百万 token 为 $2，缓存读取为 $0.10。只比较这段前缀，不计其余输入、输出、工具调用及其他费用。

假设	前缀费用
每次都重新做一次 30 分钟缓存写入	每次 $0.25。
首次写入 12 小时缓存	$0.50；每次后续完整缓存读取 $0.01。
两次请求，短缓存两次写入，长缓存一次写入加一次读取	分别为 $0.50 与 $0.51。
三次请求，短缓存三次写入，长缓存一次写入加两次读取	分别为 $0.75 与 $0.52。

这是算术示例，不代表短缓存一定会在每次请求前过期：短缓存读取可以刷新覆盖时间；12 小时请求也不保证命中。使用实际请求间隔、命中和写入记录计算自己的费用。价格来自 GPT-6.1 Sol 模型页。

如何设置和观察缓存

使用支持的模型及 Responses API 时，请求可以设置：

JSON

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "ttl": "12h" },
  "input": "这里放实际任务输入"
}

这是请求体示例；短文本可能达不到模型的最小可缓存长度，因此不能用它判断命中。真实工作流应把稳定的系统指令、工具定义和参考材料放在可复用的前缀，避免每次把时间戳或变化内容插到前面。不同模型支持的参数和缓存阈值，应以当前文档为准；旧模型使用的 prompt_cache_retention 不是同一个参数。

记录返回的 usage.input_tokens_details 中可用的缓存读取、写入和寿命分项，结合模型价格算总额；不要在写入分项已经计价后再次把总写入 token 加一遍。对照首次请求、间隔后的重复请求和前缀变化后的请求，并测量实际耗时。