OpenAI 12 小时提示词缓存

如果你的智能体每天要反复调用同一套指令、工具定义和参考资料，而两次调用之间隔了几个小时，默认的 30 分钟缓存早就过期了，这部分内容每次都要按写入价重新计费。OpenAI 在 10 月 20 日的 API 更新日志里新增了一个选项：Responses API 可以把提示词缓存的保留时间设为 12 小时，适用于 GPT-5.6 及以后的模型。提示词缓存指的是把请求开头不变的部分存下来，之后前缀相同的请求直接复用，并按较低的缓存价计费。12 小时档的写入价是普通输入价的 2.5 倍，默认的 30 分钟档是 1.25 倍，读取价两档相同。

要点

新选项：Responses API 的 prompt_cache_options.ttl 可以设为 "12h"，与默认的 "30m" 并列。指南写明，这一选项适用于 GPT-5.6 及以后的模型。
价格：写入按普通输入价计算，30 分钟档为 1.25 倍，12 小时档为 2.5 倍。读取价与保留时长无关，多数模型为 0.1 倍，GPT-6.1 Sol 为 0.05 倍。
GPT-6.1 Sol 的数字：定价页标准档每百万 token 的输入价为 2.00 美元，缓存读取 0.10 美元，30 分钟写入 2.50 美元，12 小时写入 5.00 美元。

背景

提示词缓存不是新功能，变的是保留时长。OpenAI 的更新日志记录，2025 年 11 月 13 日推出的扩展保留最长可达 24 小时，通过 prompt_cache_retention 设置，适用于 GPT-5.5 及更早的模型。2026 年 7 月 9 日随 GPT-5.6 推出的是显式的提示词缓存控制；9 月 8 日起，Responses API 中的 Prompt Cache Diagnostics 正式可用，用来查看缓存为什么没有命中。

GPT-6.1 Sol 是上面这组价格对应的模型。OpenAI 在公告里举的例子是常驻智能体 dots，本站此前也报道过 dots 的发布。

事实部分

表中的数字取自定价页标准档的 GPT-6.1 Sol 一行。页面有短、长上下文切换，长上下文的数字我没有核对。

项目	30 分钟（默认）	12 小时（新增）
写入价，相对普通输入价	1.25 倍	2.5 倍
GPT-6.1 Sol 写入，每百万 token	2.50 美元	5.00 美元
读取价，每百万 token（两档相同）	0.10 美元	0.10 美元

指南里还有几条规则，决定一次请求实际怎么计费：

可以混用：请求级的 ttl 作用于隐式断点，以及没有单独设置 ttl 的显式断点；单个断点可以用 prompt_cache_breakpoint.ttl 覆盖。同一请求中，每个 token 只计一次费，按覆盖它的最长写入档计算。
升级要重新付费：已经有效的 30 分钟缓存改为 12 小时，这些 token 会按 12 小时写入重新计费，之前的写入费不抵扣。
读取会续期：一次 30 分钟档的读取，会把有效期顺延到读取后的 30 分钟。已经处于 12 小时有效期内的条目不会重新计时，也不会再收一次写入费。
保留不等于保证：指南写明，缓存条目“不会被无限期保存”，选 12 小时也“不设删除期限”。最短保留时间决定的是能否享受缓存读取价，不保证每次请求都复用已存的状态，也不保证延迟更低。
流量与机器：缓存状态存在具体的机器上。流量超过每分钟 15 次时可能出现溢出路由，请求落到没有对应条目的机器上，就无法复用。
适用范围：指南只在 Responses API 下说明 12 小时档。定价页的 Flex/Batch 标签也列出了 12 小时写入价（GPT-6.1 Sol 为 2.50 美元），但指南没有写 Batch 上如何设置保留时长。

盈亏怎么算

我们按定价页标准档的数字算了一笔账。假设同一段前缀被调用若干次，相邻两次之间都超过 30 分钟，又都在 12 小时之内，每次调用都带上整段前缀。下表是每百万 token 的合计费用（美元）：

调用次数	30 分钟档	12 小时档
1	2.50	5.00
2	5.00	5.10
3	7.50	5.20
6	15.00	5.50
12	30.00	6.10

调用两次时，12 小时档只多 0.10 美元，基本持平；从第三次起它就更便宜。调用 12 次时，它的合计约为 30 分钟档的五分之一。

有两个前提要记住。第一，如果两次调用间隔不到 30 分钟，30 分钟档靠续期就能一直覆盖，12 小时档只会多付写入费。第二，表里只算了前缀。在显式断点模式下，最后一个断点之后的内容按普通输入价计费，不产生缓存写入费。

note.com 上 DenDen 的算术得出的结论相同：两次持平，三次以上 12 小时更省。DenDen 的算例把读取价按 0.1 倍计，所以 12 次时写成 15 对 3.6（以标准输入价为 1）。GPT-6.1 Sol 的读取价是 0.05 倍，应以上表为准。

各方说法

OpenAI 开发者账号的主帖把这项功能讲给常驻智能体：“Persistent agents, like dots, reuse context throughout the day.”（常驻智能体如 dots，全天都在复用上下文。）帖子还说，即使请求相隔数小时，也能以较低的缓存输入价计费。这是厂商的用例说明，没有给出命中率。

OpenAI 的 Tibo（@thsottiaux）在 UTC 时间 10 月 21 日 01:10 发的“Day 16”帖子说得更远：对 Codex 与 Work 的登录用户，缓存会被“永久保留”（keep cache forever），回到旧会话或隔几个小时再继续也没有额外成本，并且“保证命中缓存”（guaranteed to hit the cache）。这是 Tibo 针对 Codex 与 Work 的产品说法，不是 API 条款。PANews 的英文标题 Retained Permanently 转述的就是这句话，正文也归给了 Tibo。API 指南的说法更窄：缓存条目不会被无限期保存，也不承诺命中。两者适用的对象不同，读的时候要分开。

AI Weekly 的快讯（作者 Alexis Dufresne）引用了同一份更新日志、指南和定价数字。它的编者按把盈亏点归结为一件事：每个缓存块在 30 分钟过期之前被复用的频率。DenDen 的分析还提醒，缓存读取同样计入每分钟 token 限额（指南也这样写），所以这一档降低的是单价，并不会放宽限额。

在我们能查到的来源里，没有找到独立的实测命中率、延迟数据或批评文章。在 Hacker News 上检索 prompt caching，近一周的结果里没有关于这次更新的讨论。

编辑判断

这项功能最适合长期运行、每天反复调用同一段长指令、工具定义或参考资料的智能体，两次调用之间隔几个小时。OpenAI 举的常驻智能体 dots 就是这个形状，定时运行的批处理流程也属于这一类。

以下情况不划算：调用很密，间隔不超过 30 分钟，默认档已经够用；每次请求的前缀都不同，没有可复用的部分；只调用一两次。

最需要盯住的是写入费。12 小时档的写入价是 30 分钟档的两倍，只有复用足够多次，这部分溢价才赚得回来。我们的判断是：它适合“复用多、间隔长”的稳定前缀，并不是普遍意义上的“缓存更便宜”。

还有两件事指南没有写明：Chat Completions 与 Batch 的参数，以及零数据保留（ZDR）的组织能否使用 12 小时档。上线前要先查清楚，不要靠推断。

怎么试

确认模型是 GPT-5.6 或更新的版本（例如 gpt-6.1-sol），接口用的是 Responses API。
把不变的部分（指令、工具定义、参考资料）放在请求开头，这段前缀至少要有 1,024 token。
在不变部分的末尾设置 12 小时断点。下面的 JSON 是指南示例的缩写，省略号换成你自己的内容：

{
  "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" }
        }
      ]
    },
    {
      "role": "user",
      "content": [{ "type": "input_text", "text": "……当前问题……" }]
    }
  ]
}

看响应里的 usage.input_tokens_details.cache_write_tokens_details。它把写入拆成 ttl_30m_tokens 和 ttl_12h_tokens，两者之和等于 cache_write_tokens。如果 ttl_12h_tokens 为 0，说明这次写入没有走 12 小时档。
按指南的公式核对账单：普通输入 token 按输入价计，缓存读取 token 按读取价计，ttl_30m_tokens 按 1.25 倍输入价计，ttl_12h_tokens 按 2.5 倍输入价计，相加后除以 1,000,000。