从「尽力保留几分钟」到「至少保留 12 小时」，变的不只是时长，而是谁来承担缓存失效的风险
按 OpenAI 开发者文档目前的写法，新档位只对 GPT-5.6 及之后的模型、且只在 Responses API 里提供，开关是 prompt_cache_options.ttl，可选值两个：
"30m"：默认值，缓存最短保留 30 分钟，写入按普通输入价的 1.25 倍计。"12h"：最短保留 12 小时，写入按普通输入价的 2.5 倍计。prompt_cache_breakpoint.ttl 单独覆盖请求级设置，起缓存的门槛是 1,024 个可见输入 token，OpenAI 隐藏的系统内容不算在内。GPT-5.5 及更早的模型仍走老参数 prompt_cache_retention，其中 24h 的描述是「通常保留约 30 分钟、最长 24 小时」。注意这里的措辞差别：老档位的 24 小时是上限，能留多久看服务器负载；新档位的 12 小时是下限。数字看着变小了，承诺反而变硬了。
把普通输入价记作 1，可以粗算出两道门槛。第一道是和完全不缓存比：12 小时档写一次多付 1.5，之后每命中一次省 0.9，所以只要这段前缀在 12 小时内被复用两次以上，就已经回本。
第二道是和默认的 30 分钟档比，这才是开发者真正要做的选择。12 小时档写入比 30 分钟档多付 1.25；而 30 分钟档一旦过期，下一次请求就得以 1.25 的价格重新写入，相比命中缓存的 0.1 要多出 1.15。换句话说，只要一天里有两次以上「间隔超过半小时」的请求，12 小时档基本就比默认档便宜。
这恰好是长时运行智能体最典型的节奏：跑一段、等外部任务回来、被人审一下、再接着跑。以前这类间隙会把缓存冲掉，开发者只能靠定时发「保温请求」续命，或者干脆接受重算；现在可以直接花一次溢价把前缀钉住。反过来，对话式产品里用户几秒一句，30 分钟档足够，开 12 小时只是白付写入费。
API 侧是明码标价的 12 小时，Codex 与 Work 的登录用户却被描述为「永久缓存」：回到几天前的旧会话、或者离开几个小时再回来，都不再因为缓存失效被重新计费或重新消耗额度。按 Tibo 的说法，这类场景会保证命中缓存。
这一区别说明 OpenAI 在用两套逻辑经营缓存。API 客户按 token 付钱，缓存时长是可以定价的商品；订阅用户按月付钱，缓存失效带来的额外消耗会直接反映在额度掉得快不快上，最终变成「Codex 不经用」的口碑问题。对订阅产品来说，把缓存成本吃进去，比让用户在额度条上感受到它要划算得多。
永久缓存在存储侧的代价并不小——每个长会话的前缀都要在某处常驻。OpenAI 没有公开具体实现，也没说「永久」是否有容量或会话数上的隐性边界，这一点还需要观察实际使用反馈。
过去几年，各家比的是上下文窗口有多长；智能体开始一跑就是几小时后，账单里占大头的往往不是生成，而是一遍遍重读同一段几万 token 的系统提示和工具列表。谁能让这部分以一折甚至更低的价格常驻，谁的智能体在总成本上就更有底气。
横向看，Anthropic 目前公开的缓存选项是 5 分钟和 1 小时两档，OpenAI 此次直接把可承诺的最短时长推到 12 小时，在长任务场景里拉开了一个量级。不过 12 小时档目前绑定 GPT-5.6 之后的模型和 Responses API，仍停在 Chat Completions 上的老项目享受不到，迁移成本本身也是这笔账的一部分。
28 天连更还剩一半，前 16 天里 OpenAI 发的东西有相当比例都落在「让智能体跑得更久、更省」这条线上。缓存时长从默认几分钟提到可选半天，大概不会是这条线上的最后一步。