AREX Feed Article
OpenAI API 新增可选 12 小时提示缓存：写入按 2.5 倍输入价计费，可与 30 分钟档混用
北京时间 10 月 21 日凌晨（UTC 时间 10 月 20 日），OpenAI 开发者官方账号 宣布：API 现已支持可选的 12 小时 prompt caching（提示缓存）。帖文称，持久型 agent（帖文以 dots 为例）会在全天反复复用上下文，开发者可以让共享的 instructions、tools 与上下文缓存更久，即使请求相隔数小时，也按更低的 cached-input（缓存输入）费率计费。OpenAI 官方 当天为 v1/responses 添加的条目确认了这项功能，并给出关键定价：12 小时档的缓存写入按输入 token 价格的 2.5 倍计费。
（帖文所附链接的落地页）同步更新了完整费率：默认 30 分钟档写入按普通输入价的 1.25 倍计费，新的 12 小时档写入按 2.5 倍计费；缓存读取费率与所选寿命无关——多数 GPT-5.6 及之后的模型为普通输入价的 0.1 倍，GPT-6.1 Sol 为 0.05 倍。文档同时写明，这套选项目前放在 Responses API 之下。
“12h” 是最低寿命，不是删除期限
OpenAI 的提示缓存保存的不是 token 本身，而是模型处理输入时算出的 key-value（KV）张量，覆盖 prompt 中不变的前缀。后续请求命中相同前缀时，模型直接复用这些已算好的状态，命中的部分按缓存输入价计费。提示缓存本身默认开启，这次更新做的事是把“缓存条目留多久”交给开发者选择。
按文档，GPT-5.6 及之后的模型在 Responses API 里通过 prompt_cache_options.ttl 设置最低缓存寿命："30m"（默认）最低保留 30 分钟，适合频繁复用上下文的对话和 agent 步骤；"12h" 最低保留 12 小时，面向跨更长间隔复用的稳定指令或参考资料。文档强调这些写入费率都是“总费率”，不是在普通输入价之外再加的附加费；OpenAI 也可能把条目保留得比请求的最低寿命更久——“12h” 不设定删除期限，也不改变最大数据保留政策。填入不支持的值会返回 400 invalid_request_error。
此外还有两个使用门槛：可缓存前缀至少要有 1,024 个可见输入 token（隐藏系统内容不计入），且整个渲染前缀必须逐字匹配，改动了断点之前的指令、工具定义或相关设置，后续前缀就无法命中；缓存条目不跨组织共享，也不能跨区域处理边界复用。
同一请求里，共享指令留 12 小时，会话内容留 30 分钟
文档给出了混用两种寿命的完整示例：把全天复用的材料放在 prompt 开头，给它的断点设 "12h"；变化更快的会话上下文走默认 "30m"。示例请求用 gpt-6.1-sol 实现：请求级 ttl 设为 "30m"，developer 消息里的共享指令单独标 prompt_cache_breakpoint.ttl = "12h"，会话内容沿用请求默认值，当前这条问题放在最后一个断点之后——explicit-only（仅显式断点）模式下，断点之后的内容按普通输入价处理，不产生缓存写入费。
计费规则随之明确：一个断点覆盖它之前的整个前缀，同一请求内每个 token 按覆盖它的最长寿命计一次费。其中一条对存量用户影响直接：把已有效的 30 分钟覆盖升级成 12 小时，会按一次新的 12 小时写入计费，旧的写入费不给抵扣。反过来，用 30 分钟档读取命中一条 12 小时条目时，覆盖取“原有到期时间”与“读取后 30 分钟”中更晚的一个，既不重置 12 小时的时钟，也不另收写入费。
账目在 API 响应里可以直接查：usage.input_tokens_details.cache_write_tokens_details 会把写入拆成 ttl_30m_tokens 和 ttl_12h_tokens 两项。另外，prompt_cache_options.prewarm 允许在不生成输出的情况下提前把共享指令灌进缓存，预热写入同样按所选寿命的写入费计——配上 12 小时档，一次预热即可覆盖一个工作日。
官方数字与开发者演算：12 小时档何时回本
文档用 30 分钟档的费率先算了一笔官方账：在 0.1 倍读取价下，写入一次并完整复用一次，成本是普通输入的 1.35 倍，不缓存跑两次则是 2 倍；十个请求（一次写入加九次完整读取）合计 2.15 倍，不缓存是 10 倍。官方给出的选择标准是把 12 小时档更高的写入费，与“30 分钟覆盖过期后重写前缀”的成本做比较。
@OpenAIDevs 在里说得更直接：如果需要全天复用同一上下文，重复复用带来的节省“会明显超过 12 小时缓存的额外成本”。这是 OpenAI 自己的口径，帖文没有给出具体数字。
回复区很快有人补上演算。 在回复里按文档费率推算：只要前缀在这 12 小时里会“冷掉”两次，就到了 12 小时档的盈亏平衡点；他还提醒“第一次调用就把 ttl 设好”，避开升级存量缓存那笔重复的写入费。 用 GPT-6.1 Sol 的单价（输入 $2/百万 tokens、缓存读取 $0.10/百万）估了一个 100 万 token 前缀、每小时调用一次的场景：12 小时档是 $5 写入加 11 次 × $0.10 读取，共 $6.10；30 分钟档每小时重写一次，12 × $2.50 共 $30——差约 5 倍。他采用的输入与缓存读取单价同 changelog 公布的 GPT-6.1 Sol 标价一致（每百万 tokens 输入 $2、缓存输入 $0.10），$5 与 $2.50 的写入费则分别对应文档给出的 2.5 倍与 1.25 倍费率；不过这组标准价按 272K 输入以内标注，更长 prompt 另有价目。
30 分钟窗口留下的缺口
9 月 22 日，OpenAI 随 GPT-6 家族上线了改进版提示缓存系统：默认命中率更高，共享前缀在 30 分钟窗口内复用即享缓存折扣，并配套推出监控命中率的 Prompt Caching Dashboard、诊断缓存未命中的工具、显式缓存断点与 prewarm 预热（）。博客援引 Mario Rodriguez（首席产品官）的引语称，GitHub Copilot 过去几个月在数十亿次请求中，把需要重新处理的 prompt token 占比降低了 50% 以上。
但那套系统的折扣窗口停在 30 分钟：请求间隔一超过半小时，同一段长指令就要按全价重读一遍。Raz Bhimani 在回复中举例：每小时检查一次收件箱的 agent，过去每次都要为同一份长指令付全价，现在只有新增的邮件内容按全价计（）。@OpenAIDevs 帖文里的 dots 正是这类持久 agent；帖文没有解释 dots 的更多细节，回复区里也有人对它不满——Devon 写道，dots 单次调用撑不过 2 小时，追问对话记录存在哪里，认为对他近来的用法帮助有限（）。
回复区在问：Codex 有没有份
现行文档把 12 小时档写在 Responses API 与 GPT-5.6 及之后的模型之下；更早的模型仍走 prompt_cache_retention 参数，可选 "in_memory"（非活动后通常保留 5～10 分钟）或 "24h"（通常保持约 30 分钟可用、最长可保留 24 小时），没有 12 小时这一档。Icarusdissident 在回复中问：“只限 API，还是 Codex 也有份？”（）截至发稿，在检索到的这条帖文串及其全部回复里，未见 @OpenAIDevs 的回应。