GPT-6 提示缓存：缓存读取降 90%，以及如何真正命中缓存

你跑的每一个 agent 循环都在重发同样的开场。系统提示词、工具定义、OpenAPI 规范、仓库约定。模型今天已经看过这段前缀一百次了，而你每一次都按全额输入价格付了钱。

规模一上来，这笔账单就很扎眼。OpenAI 称其中位数研究员每天在编码 agent 上花费超过 $600，90th 百分位每天 $7,000。这些人还只是在跑一个实验室的内部工具，不是在跑面向客户的生产 API。

2026 年 9 月 22 日，OpenAI 在发布 GPT-6 Sol 和 GPT-6 Luna 的同时，推出了一个正是针对这件事的提示缓存版本。缓存读取打 90% 折扣，默认命中率更高，两种最常见的会破坏缓存（cache-busting）的改动不再使缓存失效，你可以显式设置断点，还多了 Prompt Caching Dashboard 和一个诊断工具，用来看实际发生了什么。在生产环境里跑这套机制的 GitHub 报告称，在数十亿次请求中，需要重新处理的 prompt token 减少了 50% 以上。

本指南覆盖改了哪些东西、这个折扣在实际金额上值多少、怎么组织 prompt 才能真的命中缓存，以及当有人重构了你的系统提示词之后，怎么测试它还在命中。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

发布了什么

前三项对 agent 最重要。最后一项，对那个需要向上解释上个月账单的工程师最重要。

算术

提示缓存只影响输入 token。输出价格不动，所以一个靠短 prompt 写长答案的 agent 几乎感觉不到变化，而一个读取大块稳定上下文、只输出一句简短结论的 agent 会感觉非常明显。

这个折扣把两个新模型的公开价格变成了这样：

缓存读取（cached-read）这一列，是把 90% 折扣套在公开输入价格上的结果。拿它做预算之前，先去官方的实时定价页面核对一遍。

现在看一个具体负载。假设你跑一个代码审查（code-review）agent：40,000 token 的稳定前缀（系统提示词、工具数据模型、服务的 OpenAPI 文档、你们的 API 约定），加上每次运行约 2,000 token 的 diff，每天 500 次。

对一个形态完全没变的负载来说，Sol 的输入账单大约降了 86%。唯一改变的事情，是前缀在两次调用之间是否保持 byte-identical。

值得放在旁边对比一下：Claude Opus 5.5 的缓存读取标价是每百万 $0.20，输入是 $4.00，缓存写入则是每百万 $5.00。读取价格和 Sol 落在同一个位置，而 Anthropic 对写入缓存收取明确的溢价。OpenAI 的这次发布没有给出 Sol 或 Luna 的缓存写入价格，这是本文结尾几个悬而未决的问题之一。如果你想比的是整体账单而不是单个数字，我们的 2026 年 9 月模型价格战解析把三次发布放在了一张表里。

为什么缓存未命中通常是你自己的问题

提示缓存是按前缀匹配的。缓存以你请求中最前面那一段连续的 token 为键，所以第一个与上一次调用不同的字节，会让它之后的一切全部失效。一个放错位置的字符，就能让你失去整个 40,000-token 的折扣。按它们在真实代码中出现的频率大致排序，最经典的几种是：

• 往系统提示词里注入时间戳、请求 ID 或 trace ID。
• 把用户名、组织 ID 或 locale 放在静态指令的前面，而不是后面。
• 把检索到的上下文插在工具定义之前，于是每次新的检索都会整体挪动前缀。
• 工具数组来自 set 或字典，导致 JSON 键顺序在不同进程之间乱掉。
• 为了多样性，每次请求轮换 Few-shot 示例。

还有两种以前在名单上，现在不在。改变 reasoning effort 不再破坏缓存，所以一个在简单轮次用 low、在困难轮次升到 max 的 agent，在升级过程中依然保得住热前缀。改变工具可用性也不再破坏缓存，所以把危险工具挡在权限检查之后，不再强制它上面的所有内容走一次冷读。这两种模式在 agent 框架里极其常见，而在此之前，它们恰好会在最贵的那些轮次上悄悄把缓存清零。

把 prompt 排成稳定在前、易变在后

这条纪律能扛过未来每一次价格变动：按变化频率给上下文排序，最稳定的放最上面。

1. 对所有用户都完全相同的系统或开发者指令。
2. 工具和函数的 schema，按固定顺序序列化。
3. 大段的共享参考资料：OpenAPI 文档、风格指南、数据库 schema。
4. 很少变化的 Per-tenant 或 per-project 上下文。
5. 每次查询都会变的检索片段。
6. 用户输入这一轮，以及任何带时钟的东西。

第 1 到第 3 层就是你的缓存。如果某个时间戳必须出现在 prompt 里，把它放进用户轮次，不要放进系统消息。如果你的工具列表是动态拼装的，就把它排序并冻结 JSON 键顺序，让两个进程序列化出的结果完全一致。

from openai import OpenAI

client = OpenAI()

STATIC_PREFIX = [
    {"role": "developer", "content": SYSTEM_INSTRUCTIONS},   # never changes
    {"role": "developer", "content": OPENAPI_DOCUMENT},      # changes on deploy
]

response = client.responses.create(
    model="gpt-6-sol",
    reasoning={"effort": "low"},
    tools=SORTED_TOOL_SCHEMAS,
    prompt_cache_key="review-agent:v7",
    input=STATIC_PREFIX + [
        {"role": "user", "content": f"Review this diff:\n{diff}"},  # volatile, last
    ],
)

print(response.usage)

这次发布里的显式断点，让你可以标记缓存前缀在哪里结束，而不是依赖平台去推断。当第 4 层很大时这最有用：一块 per-tenant 内容，对一个客户稳定、对下一个客户不同，这时你会希望边界是刻意划出来的，而不是落在启发式算法随便挑的那个 token 上。

给缓存键本身加上版本，就像上面 review-agent:v7 那样。当你刻意改动前缀时，把版本号往上抬，这样你就能在指标里看到那段冷却期，而不是纳闷成本为什么跳了。

去验证它，不要假设它

每个响应里的 usage 对象会告诉你有多少输入 token 来自缓存。读它、记它、并对它做告警。大致长这样：

usage = response.usage
cached = usage.input_tokens_details.cached_tokens
total_in = usage.input_tokens

print(f"cache hit rate: {cached / total_in:.0%}  billed fresh: {total_in - cached}")

上面代码片段里的字段名来自当前的 OpenAI API 结构，而不是发布公告，所以上线前请对照参考文档核对。原则不变：响应会告诉你真相，把这个数字放到看板上。

新的 Prompt Caching Dashboard 和诊断工具提供 fleet-level 的视角，你会在这里看到 GitHub 报告的那种模式：在数十亿次请求中，超过 50% 的 prompt token 不再需要重新处理。那是平台级的测量结果，想知道你自己的数字，唯一的办法就是自己测。

这种失效是无声的。缓存不再命中时不会有任何报错。同事为了调试往系统提示词里加了一个请求 ID，前缀就冷了，唯一的信号是三周后账单上慢慢浮现的一行。

所以这更该被当成一个回归测试，而不是监控问题。把模型接口当作你依赖的任何一个 API 来对待：在 Apifox 里保存请求，在测试场景里断言第二次调用时 usage.input_tokens_details.cached_tokens 超过某个下限，然后在 CI 里按计划运行它。两次连续调用，一次预热、一次断言，就是完整的测试；这样一来，一次杀死缓存的 prompt 重构会在 pull request 上失败，而不是在账单上失败。

关于延迟的脚注

缓存减少了首 token 之前要做的工作，所以它通常既省钱，也能改善首 token 时间。但别指望它能拯救那些 reasoning 模式。

第三方机构 Artificial Analysis 测得，GPT-6 Sol 和 GPT-6 Luna 的“max”推理变体首 token 时间分别是 102.15 秒和 124.23 秒。这不是你在 low effort 下会看到的数字，也不是厂商数据，所以当作方向性参考。结论无论如何都成立：没有任何缓存折扣能把两分钟的思考预算变成可交互的。在承诺一个响应时间之前，按 effort 档位分别测延迟。我们的 GPT-6 Astra API 指南对 effort 档位有更详细的说明。

这次发布没有回答的问题

在把设计押在这上面之前，有四件事值得先确认：

• Sol 和 Luna 的缓存写入是否收费，费率是多少。
• 没有流量时缓存前缀能存活多久，以及 GPT-5.6 时代的保留策略是否原样沿用。
• GPT-6 Astra 的缓存读取价格是否也降到了同样的 90% 折扣——发布材料只覆盖了新模型。
• 显式断点确切的参数名——公告是按能力描述的，而不是按字段名。

这些都不妨碍你先把 prompt 结构做好。Stable-first 的排序、带版本的缓存键，以及对缓存 token 的断言，在任何一种答案下都划算。

简短版

按易变性给 prompt 排序，把时钟挡在系统消息之外。给缓存键加版本，让刻意的改动看得见。读每个响应里的 cached_tokens，并在 CI 里给它设一个下限。现在可以自由地升降 reasoning effort、开关工具了，因为两者都不再让你失去前缀。关于这套机制本身，我们的「提示缓存是怎么工作的」一文介绍了基本原理。

这些模型的价格还会再变，它总是会变。而 prompt 结构的纪律，是下一次发布把所有数字都重置之后，仍然继续回报你的那部分。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。

获取专属报价与部署方案

详细的私有化部署系统架构与安全白皮书

针对您公司规模的专属报价单

免费的 1v1 专属产品演示 (Demo) 机会

获取部署方案

* 提交后，我们的客户经理将在 1 个工作日内与您联系

林俊锋 企业微信

@Apifox 专属顾问

扫码备注: 私有化 + 公司名