OpenAI 缓存留12小时，你的账会更便宜吗
Hello，我是飞飞。
你给 AI 发过的那一大段项目说明，隔几小时再用，还能按缓存价算吗？OpenAI 这次给了一个更长的选择：12 小时。
但它的写入价，也到了三十分钟档的两倍。光看“多留一阵”，还算不出钱能省多少。
我没试过这次更新，也没有新的调用记录。这篇先核机制，再拿四月的写作流程对照。那篇旧文曾说，缓存优化后成本降到约 33 美元。这笔账也得重算。
多留有多贵
截至 10 月 21 日，OpenAI 缓存指南明确支持：GPT-5.6 及之后的相应模型，在 Responses API 用 prompt_cache_options.ttl 选 12h。
它表达的是最低缓存时长。默认 30m，即三十分钟；12 小时也不等于到点保证删除。更早模型的 prompt_cache_retention: "24h" 是另一套参数，别照着旧教程只改数字。
官方价格页把写入单独列了出来。按普通输入价作一份，三十分钟缓存写入花 1.25 份，12 小时写入花 2.5 份。后续读取另按模型的缓存输入价结算。
留得更久，首次写入也更贵。 这才是我想先算的一笔。
不妨设同一段固定说明，普通输入成本为 1。选缓存读取为普通输入一折的模型。只比较这段说明的输入成本，输出、新问题和工具费用先固定。
| 使用情况 | 三十分钟档 | 12 小时档 |
|---|---|---|
| 写完就不用了 | 1.25 | 2.5 |
| 半小时内完整复用两次 | 1.45 | 2.7 |
| 分三个时段使用，短缓存每次均失效 | 3.75 | 2.7 |
第三行假定三个时段仍在同一段 12 小时覆盖里，且每次都能完整匹配。短档是三次写入，长档是一次写入、两次读取。真实缓存可能留得更久，这张表是算例。
算例还有一道边界：这里算的是缓存读取计费。官方说的最低时长，保证的是相应缓存读取价格的资格，不能直接读成每次都从同一块硬件复用计算，更不能保证首字延迟一定下降。要省费用就查用量，要看快了多少就另记响应时间。
按这张表的一折读取价，短档写两次花 2.5 份。长档一写一读花 2.6 份，仍没占到便宜。
到第三次调用，且短档又失效时，长档才在这个算例里占优。也就是说，上午、下午、晚上各用一次，还得同时满足表里的条件。
连续调用都落在短档覆盖里，延长时限就更没必要。这笔钱，要靠跨时段复用补回来。
如果你上午只调用一次，晚上就换项目，长缓存会先多收一笔写入钱。时长加上去，复用次数没跟上，账反而难看。
旧账先算清
四月的原文写得很具体：我用 Claude Max 5x，每月 100 美元。连着两天跑博客流水线，从早上九点到晚上十一点。第二天下午三点，撞上五小时窗口的限流。
我当时开始盯输入、输出和缓存。旧记录里，总输入约 26.4M token，缓存读取占 19.2M，约 73%。这个比例能对上。
钱却有一处明显对不上。
旧文列的裸算公式是：26.4M 输入乘每百万 3 美元，加 1.8M 输出乘每百万 15 美元。结果应当是 106.2 美元，这一项成立。
但“约 33 美元”那项，光列出的非缓存输入 7.2M、缓存读取 19.2M，再加输出，就已经是：
7.2 × 3 + 19.2 × 0.30 + 1.8 × 15 = 54.36 美元
54.36 美元也只是把剩下的 7.2M 全按普通输入价算。它里面有多少普通输入、多少缓存写入，旧记录没拆开。有写入的部分要换成对应写入价，不能再整笔叠加一次。
因此，这个数也只能用于检查旧算式，无法复原真实账单。
33 美元这个结果，我收回。 这笔加法过不了，就没资格拿来报喜。
还有一个容易漏的对照条件：旧文说命中率从约 30% 到 73%，但没有给两段时期完全相同的任务量。写作、检索、配图的比例变了，输入和输出也会变。命中率提高值得记录，单靠这个百分比，还算不出省钱幅度。
钱从哪儿扣，也得看清。我付的是 Max 包月费。旧文按 API 单价折算的数字，不能写成信用卡少扣了多少钱。缓存比例是旧记录，成本估算是另一回事。
旧文还记录，撞限流从一周六次降到两次。这是当时多项调整后的观察。把改善全算给缓存，也缺少单独对照。
我会留哪一段
这恰好能接上四月的老流程。
当时我把 CLAUDE.md 从 12KB 缩到 4KB。项目结构、常用命令、约束留下，具体任务挪进会话。这个做法现在仍有参考价值：先分清哪些材料会反复用，哪些只服务眼前这一问。
拿我写文章这套流程说，账号风格、引用规则、输出格式，一天会用很多遍。某篇文章的新闻材料和临时修改意见，却很快会变。
如果以后用 API 接这套流程，我会考虑给稳定说明较长时限。今天的热点和当前问题放在后面。具体是否值得开，得看它跨时段被复用多少次。
这里还有一句旧建议要改。我四月写过，常驻 skill 全部显式加载，避免前缀变化。
现在我不会直接把“全加载”当通用省钱法。为了命中而塞入用不上的说明，会增加首次输入和写入成本；任务真正需要的材料也可能被挤远。加载哪些，仍应由任务决定。
缓存诊断文档要求核对开头内容是否完全相同，以及模型、工具等设置是否兼容。它还把工具改名、前面插入时间戳，列为可能的失配原因。
稳定说明还得达到可缓存长度。GPT-5.6 及之后是至少 1,024 token，并且要有可匹配的缓存断点，也就是服务能存下、下次能找到的那段结尾。仅仅两次开头相同，仍不保证命中。
所以，长时限能解决“放了一阵再用”。它没法让两段已经不同的开头，自动变成同一段。
永久说法先放下
资讯线索里还提到：登录 Codex 和 Work，缓存可以永久保留。
本次查阅的官方缓存指南和产品文档里，我没找到足以核实这句话的说明。API 页面也不能替应用产品的具体计费行为作保证。这一项先记为未核实。
即便以后确认某个产品长期给缓存优惠，我也不会由此推断“它永远记得我的约束”。缓存关心的是计算和计费；工作能否接上，还得看下一轮究竟带了哪些材料。
我这套流水线每阶段都有交接文件。研究资料要传给 writer，改完要回写副本。旧对话还在，也得确认当前任务拿到的是定稿。省下一次重复处理，替不了这次交接。
下次就记这几栏
我还没有新版 API 的对照结果。真要补这笔账，我会选固定的写作说明，锁住模型和服务档位，分别记录连续调用、隔数小时继续调用的情况。
每条请求记时间、总输入、缓存读取、三十分钟写入、12 小时写入、输出和实际费用。再用总缓存读取除以总输入，算这批请求的 token 命中率。别把每条百分比直接取平均。
工具或说明改过，就把这批请求单独分组。诊断可以帮助找失配原因，按缓存读取价结算了多少，仍看用量。
任务结果也要保留。我写文章要看引用能否回查、格式是否合规、改稿次数是否增加。命中提高了，漏要求却让返工变多，这种便宜就没省到手。
这次最有用的变化，是固定资料可以跨更长间隔复用。它适合我这种中间停下来审稿、过几个小时继续的节奏，值得测。
而我给自己的要求也很具体：下次说省了多少钱，先让输入、写入、读取和输出加得起来。四月那张表，已经提醒过一次了。