简介
10月20日，OpenAI在Responses API里加了12小时Prompt缓存选项。同时据ChatGPT与Codex负责人Tibo在X上的说法，登录用户在Codex和ChatGPT Work里的缓存会永久保留。这两条消息连着看，指向同一件事：OpenAI正在用缓存把"长期上下文"的成本打下来。
但12小时缓存不是白捡的便宜——写入价格涨了。什么时候省、什么时候亏，需要先算清楚。
核心机制：缓存到底缓存了什么
Prompt缓存存的是模型对可复用前缀的KV张量，不是文本本身。后续请求如果开头有相同前缀，就跳过重算，只处理新增的尾部。这对"固定系统提示词 + 大量工具定义 + 长参考资料"的场景几乎是纯赚。
两种生命周期，两种价格
- 30分钟（默认）：缓存写入价为未缓存输入的1.25倍。
- 12小时：缓存写入价为未缓存输入的2.5倍。
- 读取价：两种生命周期相同，多数GPT-5.6及以上模型为输入价的0.1倍，GPT-6.1 Sol为0.05倍。
注意这些倍数是总价，不是在基价上加收。以GPT-6.1 Sol的$2/百万输入token为例：12小时写入=每百万$5，30分钟写入=$2.50，缓存读取=$0.10。
开启方法
设置位于Responses API请求中新增的prompt_cache_options对象。文档给出的混合生命周期写法值得直接照抄——把一整天都复用的材料放在prompt开头用"12h"，把变化快的会话上下文放在后面用"30m"：
{ "model": "gpt-6.1-sol", "prompt_cache_options": { "mode": "explicit", "ttl": "30m" }, "input": [ { "role": "developer", "content": [ { "type": "input_text", "text": "共享指令与参考资料...", "prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" } } ] } ] }
几条容易踩坑的机制：
- 每个请求最多4次缓存写入；隐式模式下自动断点会占掉一个名额。
- 最后一个显式断点之后的内容不会被写入。
- 只有GPT-5.6及以后的模型支持，且是Responses API；Chat Completions 侧暂未覆盖。
- 更早的模型继续使用旧的
prompt_cache_retention，默认24小时。
盈亏平衡点怎么算
一次12小时写入的成本=两次30分钟写入。所以：
- 如果同一前缀在30分钟内就会被复用多次 → 用默认30分钟更划算。
- 如果前缀会在30分钟后过期、需要重新写第二次 → 12小时不亏。
- 从第三次复用开始 → 12小时开始省钱。
换句话说，判断标准不是"我需不需要长缓存"，而是"我的调用间隔有多长"。典型适合12小时的场景：每天早上跑一次的批量任务、共享同一份产品知识库的客服/问答系统、带大量工具定义但调用零散的智能体。
必须澄清的三件事
- 12小时是"计费资格的最短生命周期"，不是过期时间。OpenAI文档明确说，条目可能保留更久，也可能不保证每次请求都复用KV张量、不保证降低延迟。"缓存有效期""实际命中率""请求延迟"是三个不同概念。
- Codex和Work的"永久缓存"目前只是X上的说法，尚未写进官方文档。从机理上推测，更可能是"重新计算缓存时不计费"的额度补贴，而不是真的永久保留张量。
- 缓存不保证命中。前缀必须严格一致，任何一处改动都会导致失效——包括系统提示词里一个空格。
实用优化清单
- 把最稳定的内容放最前面：系统提示词 → 工具定义 → 知识库 → 用户输入。顺序错了缓存全废。
- 不要在缓存前缀里塞时间戳、请求ID、用户ID这类每次都变的东西。
- 用显式断点而不是依赖隐式，才能精确控制哪一段被缓存。
- 监控实际命中率。Redis式的"设了就命中"在这里不成立，需要看计费明细里的缓存读token数。
- 与竞争对手对比：DeepSeek刚开源的推理框架缓存保留设计目标达到3天，OpenAI这次12小时的压力来源很清楚。
总结
12小时缓存本质上是一次成本结构的选择权下放：高频短间隔用30分钟，低频长间隔用12小时。开启成本几乎为零，但必须先把prompt结构理顺，否则缓存形同虚设。相关阅读：TorchTPU开源解读，那里讲的是另一端的成本账。