OpenAI 12 小时提示词缓存怎么用：写入成本、命中条件与对账
Responses API 可为 GPT-5.6 及后续支持模型选择 30 分钟或 12 小时提示词缓存；本文说明前缀设计、TTL 成本、显式断点、命中验收和账单核对。
OpenAI 提示词缓存会复用相同请求前缀的计算状态，降低后续输入成本和首段处理时间。对 GPT-5.6 及后续支持模型，Responses API 可以选择默认 30 分钟或 12 小时的最短缓存生命周期。12 小时不是免费延长：写入按普通输入价格的 2.5 倍计费，适合跨较长间隔重复使用的稳定指令或资料，不适合频繁变化的短提示。
先看成本与命中条件
- GPT-5.6 及后续模型的可缓存前缀至少需要 1024 token；更早模型的门槛和参数可能不同。
- 30 分钟写入按普通输入价格的 1.25 倍，12 小时写入按 2.5 倍；这是总写入费率，不是在普通输入费上再次加收。
- 后续读取在多数相关模型上按普通输入价格的 0.1 倍；具体模型价格必须以执行当天价格页为准。
- 缓存匹配的是从开头开始的相同渲染上下文，包括开发者消息、工具定义、历史消息以及支持的图片、文档和音频。
直接来源：OpenAI Prompt caching 官方指南。
什么时候选 30m，什么时候选 12h
连续多轮会话、短时间批处理或 Agent 步骤优先用默认 30m。稳定系统指令、工具定义或参考资料会隔几个小时重复使用时，再评估 12h。按读取费率 0.1 倍粗算，只复用一次时，12 小时的一次写入加一次读取约为 2.6 倍普通输入成本，高于两次不缓存的 2 倍；复用两次时约为 2.7 倍，才低于三次不缓存的 3 倍。这个比较只针对完全相同的缓存前缀，实际还要计入未缓存的新输入。
12 小时表示最短生命周期，不是固定删除时间，也不保证每次请求一定命中或延迟一定降低。
可复现的配置步骤
- 把稳定的系统说明、开发者消息、工具定义和参考资料放在最前面，把用户变量与当前问题放在后面。
- 先用默认 30 分钟跑一组固定请求，记录总输入、cached tokens、cache-write tokens、首 token 时延和请求 ID。
- 确认前缀超过模型门槛后，在 Responses API 设置
prompt_cache_options.ttl: "12h"；若需要自行控制断点，再启用 explicit 模式并在可复用内容块末尾设置 breakpoint。 - 同一组请求只修改末尾变量，分别在 5 分钟、40 分钟和数小时后重放，检查命中与写入分布。
- 把 Schema、工具顺序、消息空格或图片引用的变化作为负例，确认监控能识别前缀变化导致的 miss。
- 按实际模型费率分别计算普通输入、30 分钟写入、12 小时写入和 cached input，不能把总 cache-write tokens 再重复收费。
数据、限流与错误边界
缓存保存的是 KV 状态而不是原始 token，官方说明提示词缓存兼容 Zero Data Retention；但组织、区域和模型仍应按数据控制文档核对。缓存不能跨组织共享，也不能跨区域处理边界复用。cached tokens 仍计入 tokens-per-minute 限制，所以缓存命中不是提升限流额度。应用也不能手工清空缓存，只能等待生命周期和服务策略处理。
验收与对账
准备至少 10 次相同稳定前缀、不同末尾问题的请求。验收要求包括：首次请求出现预期写入，后续请求能看到 cached tokens；40 分钟后 30m 方案不被误判为必然命中，12h 方案在同组织同区域下可观察到复用；任意前缀变化都能在诊断中解释；账单把普通输入、两种写入和读取分别计价。若 12 小时方案的复用次数不足以覆盖更高写入费，应回退到 30 分钟或不显式延长。