# OpenAI 账单里冒出一栏 30m write，提示词缓存写入到底什么时候才回本？ **URL:** \ **Category:** 人工智能\ **Tags:** 问与答, API\ **Created:** [2026 年10 月 31 日 11:48 UTC](https://www.shiqidu.com/t/topic/1868 "2026-10-31T11:48:05Z")\ **Posts on this page:** 1\ **Page:** 1
作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\ 发布日期： [2026 年10 月 31 日 11:48 UTC](https://www.shiqidu.com/t/topic/1868/1 "2026-10-31T11:48:05Z")
把 Responses API 返回的 usage 拆开对账，会发现输入 token 分成了三块：普通输入、`cached_tokens`（缓存读取）、`cache_write_tokens`（缓存写入）。价目表上对应的是 cached input、30m write、12h write 这几列。对 GPT-5.6 及以后的模型，一段前缀第一次被写进缓存时，这部分 token 改按写入价算，不再按普通输入价算。 ## 倍率和单价 [提示词缓存指南](https://developers.openai.com/api/docs/guides/prompt-caching)里的规则是这样的：默认 30 分钟档的写入，按普通输入价的 1.25 倍计。在 Responses API 里可以把最短保留期设成 12 小时，这一档的写入价是 2.5 倍。之后的读取跟选了哪档保留期无关，大多数模型是 0.1 倍，GPT-6.1 Sol 和 GPT-6.1 Terra 是 0.05 倍。指南还专门说明，写入价不是附加费：同一个 token 只按普通、缓存读、缓存写三种价里的一种计，不会在普通输入价上再叠一层。 拿 [GPT-6.1 Terra 的模型页](https://developers.openai.com/api/docs/models/gpt-6.1-terra)对一下，每百万 token：输入 $1，缓存读取 $0.05，30 分钟写入 $1.25，12 小时写入 $2.50，输出 $5。单次请求输入超过 272K token 时，整单的输入和缓存价按 2 倍、输出按 1.5 倍算。GPT-5.5 及更早的模型，指南写的是没有额外的写入费，[价目表](https://developers.openai.com/api/docs/pricing)上这些模型的 write 列也都是空的。 ## 拿一段 8k 前缀算一笔 比如一个应用的系统提示加工具定义固定是 8,000 token，跑在 Terra 上，30 分钟内有 10 次请求都带着这段前缀： - 不走缓存的话，10 × 8,000 × $1 / 1M = $0.08。 - 走缓存的话，写入一次 8,000 × $1.25 / 1M = $0.01，后面 9 次读取共 9 × 8,000 × $0.05 / 1M = $0.0036，合计约 $0.0136。 只看倍率，写入多出来的那 0.25 倍，第二次请求命中一回就赚回来了：1.25 + 0.05 = 1.3，比不缓存的 2 便宜。12 小时档写入是 2.5 倍，要到第三次请求才划算。读取 0.1 倍的模型结论一样，30 分钟档复用一次就回本，12 小时档也要到第三次请求才划算。 所以固定前缀那部分基本亏不了。30m write 那一栏偏高，多半是因为写进去的东西后来没人读。 ## 写进去却没被读的部分 隐式模式（`prompt_cache_options.mode` 为 `implicit`）下，断点放在最新一条符合条件的消息末尾，通常就是用户刚发来的那条。前面的固定内容能被后续请求读到，用户这条每次都不同，却也照样按 1.25 倍写了进去。多轮对话还好，下一轮会接着用。单轮的批处理、打分、分类就吃亏了，每个请求的后半截都是一次性的，等于白多付 25%。 指南给的做法是换成显式模式：`mode` 设为 `explicit`，在固定内容末尾的内容块上加 `prompt_cache_breakpoint: { "mode": "explicit" }`。最后一个断点之后的内容按普通输入价算，不产生写入费。几个细节： - 显式模式下一个断点都不放，这次请求既不缓存也不写入。 - 每个请求最多产生四次缓存写入。 - 顶层 `instructions` 里放不了断点，想缓存的开发者说明要放进 developer 消息的 `input_text` 块。 - GPT-5.6 及以后的模型，前缀不到 1,024 个可见输入 token 不会进缓存。 保留期用 `prompt_cache_options.ttl` 设，取值 `"30m"`（默认）或 `"12h"`，单个断点也能用自己的 `ttl` 覆盖。一天里反复用、但两次调用常隔半小时以上的参考资料，放在最前面给 12h，会话上下文给 30m 就够。要留意从 30 分钟档换到 12 小时档的情况：一段已经按 30 分钟写过的前缀，改成 12 小时后会重新按 12 小时的价格收一次写入，之前那笔不抵扣。读取就不一样了：读一次 30 分钟档的缓存，有效期会往后续到读取后至少 30 分钟，也不会再收写入费。 如果想让用户的第一个问题也能命中，Responses API 还可以设 `prompt_cache_options.prewarm` 为 `true` 提前把前缀写进去。预热的这次请求不生成输出，可写进去的 token 同样按所选保留期的写入价计费。启动时预热一次值不值，就看这段前缀之后会不会真的被读到。 对账时看 usage 里 `cache_write_tokens_details` 下的 `ttl_30m_tokens` 和 `ttl_12h_tokens`，这两个数加起来就是 `cache_write_tokens`，算钱时别再重复加一遍。 DeepSeek 是另一套计费，命中率的问题站里[这篇](https://www.shiqidu.com/t/topic/1859)聊过。Codex 切到 Terra 后报错的情况，可以看[这里](https://www.shiqidu.com/t/topic/1808)。 大家的账单里，write 那一栏一般占输入费用的几成？