OpenAI 与 Claude 提示缓存对比：原理、TTL、价格、不命中的原因与检查方法

提示缓存（prompt caching）会复用请求中与之前某个请求开头完全相同部分（前缀）的计算结果，让这部分输入处理得更便宜、更快。OpenAI API 和 Claude API 都提供这一功能，但如何启用、缓存保留多久、写入缓存要花多少钱、如何确认它是否生效，两家差别很大。如果用同一套假设为两边做设计，就可能出现一边缓存正常命中、另一边每次请求都在支付写入费用却从未命中的情况。

本文依据 OpenAI 的“Prompt caching”“Prompt cache diagnostics”“Pricing”以及 Anthropic 的“Prompt caching”“Cache diagnostics”“Pricing”“Rate limits”等文档原文，对比 OpenAI 与 Anthropic 的提示缓存，说明两者规格有何不同、如何让缓存命中、以及如何确认确实命中。所有数字均已于 2026 年 10 月 3 日对照原始页面核实。关于降低 API 费用的整体思路（选择模型、批处理、控制输出等），请参阅另一篇文章“AI 使用费与 token 节省指南”。

1. 什么是提示缓存：复用完全相同的前缀

语言模型每次读取输入时，都会为每个 token 计算中间值（KV，即键和值张量）。提示缓存会把从提示开头到某个位置为止的这些值保存下来，当下一个请求以完全相同的 token 开头时，就跳过这部分计算。OpenAI 的指南说明，保存的是 KV 值，而不是 token 本身。

关键在于只有从最开头起完全一致的部分才能复用。在下面两个请求中，能复用的只有指令和文档。

请求 1：[指令 5,000 tokens][文档 20,000 tokens][问题 A]
请求 2：[指令 5,000 tokens][文档 20,000 tokens][问题 B]
        └────────────── 到这里完全相同 ──────────┘└ 不同 ┘
→ 指令 + 文档共 25,000 tokens 可以复用

请求 3：[今天的日期][指令 5,000 tokens][文档 20,000 tokens][问题 C]
        └─ 不同 ──┘
→ 即使后面完全一样，也一个 token 都无法复用

两家的文档都写明，缓存不会改变输出内容。它不是把之前的回答存起来重放，只是省去读取输入的工作。因此，即使是每次提问都不同的聊天，或每次读取不同文档的智能体，只要有共同的前缀（指令、工具定义、对话历史），缓存依然有效。

2. OpenAI 与 Anthropic 提示缓存对照

2026 年 9 月 22 日，OpenAI 发布了面向 GPT-6 的缓存改进，GPT-5.6 及以后的模型机制发生了变化（保留 30 分钟、显式断点、缓存写入收费等）。下表中 OpenAI 一栏描述的是 GPT-5.6 及以后的模型。GPT-5.5 及更早模型的差异放在表格之后说明。

来源：OpenAI“Prompt caching”“Prompt cache diagnostics”；Anthropic“Prompt caching”“Cache diagnostics”“Rate limits”（2026 年 10 月 3 日核实）

GPT-5.5 及更早的模型只有隐式缓存，断点按固定间隔自动放置，并且写入缓存不额外收费。保留时间用 prompt_cache_retention 设置：据指南所述，in_memory 为“空闲约 5 到 10 分钟，最长 1 小时”，24h 为“通常约 30 分钟，最长 24 小时”。迁移到 GPT-5.6 或以后的模型时，要把这个设置换成 prompt_cache_options.ttl。

各模型的单价见我们的价格对比文章“Claude vs ChatGPT 价格对比”。GPT-6 系列（Astra、Sol、Luna）请参阅“GPT-6 Sol 与 Luna 解读”，各厂商的当前模型请参阅“AI 模型知识截止日期一览”。

3. 缓存何时命中：前缀、最小长度、TTL 与作用范围

共同前缀与请求的顺序

在两个平台上，缓存都只有在断点之前的前缀完全一致时才会命中。Claude 按 tools → system → messages 的顺序从头读取请求，所以只要改动一个工具定义，后面的系统提示和对话历史的缓存就会全部失效。OpenAI 同样说明，工具定义、输出格式（text.format）、推理强度（reasoning.effort）等设置也属于前缀的一部分。

实际上两边的排布原则相同：把不变的内容（工具定义、指令、文档）放在前面，把每次请求都会变的内容（日期、各用户的数据、问题）放在最后。对话要以追加的方式延续，不要改写历史。

断点的放置：自动还是手动

OpenAI 的隐式模式（GPT-5.6 及以后）会把断点放在最新一条符合条件的消息（用户消息、连续工具结果中的最后一条等）的末尾。在仅显式模式下，只有你加了 prompt_cache_breakpoint 的位置才是断点，一个都不加的话，就不会使用缓存，也不会产生写入费用。

Claude 的自动缓存在顶层加一个 "cache_control": {"type": "ephemeral"} 即可启用，它会把断点放在最后一个可缓存的块上，并随着对话增长向后移动。如果在单个块上加 cache_control，就可以自己选择断点。

// Claude：在不变的系统提示末尾设置断点（显式断点）
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "很长的指令和文档……",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "今天的问题……" }]
}

// OpenAI（Responses API）：在不变的指令之后设置断点，仅显式模式
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "很长的指令和文档……",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "今天的问题……" }
  ]
}

最小长度：太短的前缀不会被缓存

对 GPT-5.6 及以后的模型，OpenAI 的最小长度是可见输入 1,024 tokens（OpenAI 在后台添加的隐藏指令不计入）。Claude 则因模型而异。

来源：Anthropic“Prompt caching”，Cache limitations（2026 年 10 月 3 日核实）。Bedrock 上以 AWS 文档中的数值为准。

如果 Claude 的提示低于最小长度，加上 cache_control 也不会报错，只是悄无声息地不缓存。此时 usage 中的 cache_creation_input_tokens 和 cache_read_input_tokens 都是 0。换模型时最小长度也会变化，因此在旧模型上能缓存的前缀，换模型后可能就不再缓存（OpenAI 的指南也有同样的提醒）。

TTL：注意从何时开始计时

OpenAI（GPT-5.6 及以后）的缓存会在“最后一次写入或复用后至少保留 30 分钟，并可能保留更久”。Claude 默认 5 分钟，选择 1 小时则写入价格变为输入价格的 2 倍。两个平台上，每次使用缓存时 TTL 都会免费刷新。

Claude 有一个陷阱：TTL 从请求开始时计算，而不是从响应结束时计算。按文档中的例子，如果生成响应用了 4 分钟，下一个请求必须在该响应结束后约 1 分钟内开始，才能命中 5 分钟缓存。对于输出很长的智能体，5 分钟比看上去要短。

缓存的作用范围与存放位置

OpenAI 的缓存按组织划分，不同处理区域（数据驻留设置）之间不共享。指南还说明缓存存放在各台机器上，每分钟超过约 15 个请求时，请求可能会被路由到其他机器。从 GPT-5.6 起，OpenAI 会自动处理路由，prompt_cache_key 也变成了按客户拆分缓存报告的可选设置，而不再是提高命中率的手段（在 GPT-5.6 之前的模型上，用同一个键把请求引导到同一台机器很重要）。

Claude API 的缓存按工作区划分。同一组织内，不同工作区即使提示完全相同也不共享缓存。在 Bedrock 和 Google Cloud 上则按组织划分。此外，缓存要等第一个响应开始后才可用，所以如果同时并行发送大量前缀相同的请求，在第一个请求写好缓存之前，其他请求也都会变成写入。

4. 价格与回本点：读取几次缓存才划算

由于写入缓存比普通输入更贵，写入后从未被读取的缓存比不使用缓存还要贵。设写入倍率为 w、读取倍率为 r、写入后的读取次数为 n，回本所需的读取次数可由下面的公式得出。

使用缓存 = w + n × r
不用缓存 = 1 + n          （把同样的前缀原样发送 n + 1 次）
划算条件 ：n > (w − 1) ÷ (1 − r)

倍率以输入价格为 1。根据 OpenAI“Prompt caching”“Pricing”和 Anthropic“Pricing”计算（2026 年 10 月 3 日核实）。只比较前缀部分，不含输出和每次请求的问题。

OpenAI 的指南也给出了 0.1 倍模型的同样计算：写入一次、读取一次共 1.35 倍，而不用缓存处理两次则是 2 倍。Anthropic 的价格页面同样写明，5 分钟缓存读取 1 次即可回本，1 小时缓存需要读取 2 次。无论读取多便宜，1 小时缓存都无法靠一次读取回本，因为 2 倍的写入成本太高。

输入单价相同的模型对比：请求间隔会让结果逆转

按 2026 年 10 月 3 日的官方价格，GPT-6.1 Sol 和 Claude Sonnet 5.5 的输入价格都是每百万 token $2，5 分钟写入价格也同为 $2.50。不同的是读取价格（Sol $0.10、Sonnet 5.5 $0.20）和 TTL。我们计算了以不同间隔发送 10 次 100,000 tokens 前缀时的前缀费用。

价格来自 OpenAI“Pricing”（Standard，272K 以内）和 Anthropic“Pricing”（均于 2026 年 10 月 3 日核实）。100,000 tokens = 0.1（以 100 万 tokens 为单位）。命中时第 1 次为写入、其余 9 次为读取；未命中时 10 次都是写入。OpenAI 还可能因机器路由等因素未命中，因此命中的几行是条件有利时的数值。

例如，GPT-6.1 Sol 每 3 分钟一次的费用为“0.1 × $2.50（写入 1 次）+ 0.1 × $0.10 × 读取 9 次 = $0.25 + $0.09 = $0.34”。从表中可以看出三点。

• 间隔在 5 分钟以内时，两者差距很小（$0.34 vs $0.43），只取决于读取价格。
• 间隔在 5 到 30 分钟时，OpenAI 的 30 分钟 TTL 占优。用 Claude 的 5 分钟 TTL，每次请求都变成写入，花费 $2.50，比不用缓存还贵。改用 1 小时后降到 $0.58。
• 间隔超过 TTL 时，缓存反而亏钱。每 2 小时一次时，不用缓存的 $2.00 最便宜。在 Claude 上不要加 cache_control；在 OpenAI GPT-5.6 及以后的模型上，使用仅显式模式且不放断点，就能避免写入费用。

尤其要注意，OpenAI GPT-5.6 及以后默认启用缓存，停留在隐式模式下，连再也不会发送的输入也可能要付写入费。如果你的业务会发送大量一次性的长输入，请查看 usage 中的 cache_write_tokens，再决定是否切换到仅显式模式。

缓存与其他计费方式的叠加

• Batch：OpenAI 的价格表中 Batch 和 Flex 也有缓存输入和缓存写入价格（GPT-6.1 Sol 的 Batch：输入 $1、缓存读取 $0.05、缓存写入 $1.25）。Anthropic 表示缓存倍率可与批处理的 50% 折扣叠加，但由于批处理请求是并行且无固定顺序处理的，它把缓存命中描述为“best effort”（尽力而为）。
• 长输入：在 OpenAI 上，输入超过 272K tokens 时，输入、缓存读取、缓存写入的价格都会翻倍（倍率不变）。在 Anthropic 上，Claude 4.6 及以后的模型在 100 万 tokens 以内价格相同。
• 预热：两家的预热写入都按普通写入价格计费。Claude 的 max_tokens: 0 不产生输出费用。

5. 提示缓存不生效的常见原因

综合两家关于常见陷阱的说明和诊断功能返回的原因列表，缓存未命中的原因大致可分为三类。

OpenAI 的常见问题

• 共同前缀之后没有断点：隐式模式会把断点放在最新消息的末尾，所以在“固定指令 + 每次不同的用户消息”的结构下，变化的部分也会被写入，下一个请求就会未命中。请在固定部分之后放一个显式断点。
• 中途切换到仅显式模式：仅显式模式只查找你放置的断点，因此不会命中在隐式模式下写入的缓存。
• 往同一条消息里追加内容：如果一条原本以“内容 A”结尾的消息变成“内容 A + 内容 B”，之前的断点就落在消息中间，导致未命中。新内容请作为新消息添加。
• 中途更改推理强度：在 GPT-6 系列模型上，保留请求中的 reasoning.effort 不变，在输入之后追加一个 configuration_update，就能在不破坏缓存的情况下更改强度。
• 执行压缩（上下文压缩）：前缀会改变，因此命中率下降。不过指南也指出，由于输入变少，总费用仍可能下降，建议比较总费用。

Claude 的常见问题

• 断点放在每次都会变的块上：只有断点位置才会写入，而读取只会向前回溯查找之前的写入位置。如果断点放在每次都变的块上，就会每次都付写入费却从不命中。自动缓存也会把断点放在最后一个块上，所以会掉进同样的陷阱。请在最后一个不变的块上放置显式断点。
• 一轮中新增 20 个或以上的块：查找之前写入的范围是从断点往回最多 20 个位置。如果对话一下子增长太多，之前的写入就会落在这个窗口之外。请在提示更靠前的位置额外保留一个断点。
• 中途改写系统提示：在受支持的模型上，保持顶层 system 不变，在 messages 中添加一条 "role": "system" 的消息，就能在不破坏缓存的情况下追加指令。
• 在快速模式（speed: "fast"）和标准模式之间切换：这会使系统提示和对话的缓存失效。

6. 如何检查缓存命中：usage 与诊断功能

先看 usage：input_tokens 的含义不同

在两个平台上，响应中的 usage 都会显示从缓存读取了多少、写入了多少。需要注意的是，input_tokens 在两个平台上的含义正好相反。

来源：OpenAI“Prompt caching”，Monitor cache performance；Anthropic“Prompt caching”，Tracking cache performance（2026 年 10 月 3 日核实）

如果把 Claude 的 input_tokens 当成全部输入来做除法，命中率和费用都会严重偏离。把两家的数字放进同一个仪表盘时，要先用上面的公式统一合计再比较。OpenAI 的指南建议，把“token 命中率”计算为从缓存读取的 token 总数除以输入 token 总数，并按用户、按天等维度汇总。

费用方面，OpenAI 为“(输入 − 读取 − 写入) × 单价 + 读取 × 单价 × 0.1 + 写入 × 单价 × 1.25”，Claude 为“input_tokens × 单价 + 读取 × 单价 × 0.1 + 写入 × 单价 × 1.25（1 小时部分为 2）”（读取倍率按模型换成 0.05 等）。OpenAI 的用量页面有“Prompt Caching Dashboard”，Anthropic 的 Rate limits 文档则引导你到 Usage 页面查看缓存命中率。

读取为 0 时按顺序检查的事项

1. 写入是否也为 0？ 在 Claude 上，如果两者都是 0，说明提示低于最小长度，或者缺少 cache_control。在 OpenAI 的仅显式模式下，如果一个断点都没放，也不会发生写入。
2. 是否每次请求都出现写入？ 说明断点放在每次都会变的位置，或者前缀中有内容每次都在变。用下面介绍的诊断功能找出变化之处。
3. 距离上一次请求过了多久？ 检查是否超过了 Claude 的 5 分钟（含生成响应的时间）或 OpenAI 的 30 分钟。

OpenAI 的诊断：prompt_cache_diagnostics

在 OpenAI 的 Responses API 中，对 GPT-5.6 及以后的受支持模型，只要在 prompt_cache_options.comparison_response_id 中传入之前某个响应的 ID，就会把那次请求与本次请求的比较结果放进 prompt_cache_diagnostics。文档写明这不额外收费，也不会单独计入速率限制。

// 在第二次请求中加入比较对象
{
  "model": "gpt-6.1-sol",
  "input": [ ……与第一次请求相同的前缀……, { "role": "user", "content": "下一个问题" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(第一次响应的 ID)" }
}

// 未命中时返回的示例（文档中的例子：工具被重命名）
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

type 有四种：cache_hit、cache_miss、comparison_response_not_found（没有比较记录或已过期）和 unavailable（无法得出结论）。未命中时，reason 是以下九种之一。

来源：OpenAI“Prompt cache diagnostics”，Fix a cache miss（2026 年 10 月 3 日核实）

Claude 的诊断：diagnostics

在 Claude API 上，需要在每个请求中都加入 diagnostics 字段，因为 API 只为带有该字段的请求保存用于比较的指纹（哈希值和估算的 token 数）。第一轮传入 "previous_message_id": null，之后传入上一次响应的 id。

// 第二轮及以后
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(上一次响应的 id)" },
  "system": "...",
  "messages": [ ... ]
}

如果响应中的 diagnostics 为 null，表示没有发现差异（或没有进行比较）；{"cache_miss_reason": null} 表示比较尚未完成；如果给出了原因，它指出的是请求最先出现分歧的位置。原因共有六种：model_changed、system_changed、tools_changed、messages_changed、previous_message_not_found 和 unavailable。*_changed 类原因会附带 cache_missed_input_tokens，即损失量的估算值。

Claude 的文档建议把诊断结果和 cache_read_input_tokens 结合起来看。

来源：Anthropic“Cache diagnostics”，Reading diagnostics alongside usage（2026 年 10 月 3 日核实）

两种诊断功能有很多共同点：都只返回找到的第一个差异，所以修正之后要再比较一次。不同之处在于，Claude 的诊断只能在 Claude API 上使用（Amazon Bedrock、Google Cloud、Claude Platform on AWS、Microsoft Foundry 都不行），并且只与同一工作区的请求比较。OpenAI 的文档没有提到需要事先标记作为比较对象的请求。在 Claude 上，如果之前的请求也没有带 diagnostics，就会得到 previous_message_not_found。

7. 缓存命中率数字：厂商示例与第三方数据

网上流传的缓存命中率数字，含义会因由谁、在什么条件下发布而大不相同。下面分开整理。

厂商给出的数字

• OpenAI 指南中的示例：一次性的评分任务（用 LLM 当评分者）在固定的评分标准之后放置显式断点，达到了“约 70% 的 token 命中率”；反复调用工具的智能体达到了“90% 以上”。指南提醒这些只是可能的结果示例，上限取决于具体的工作负载。
• OpenAI 公告（2026 年 9 月 22 日）中的客户评价：Manus 团队表示，重新考虑断点放置后，他们在 OpenAI 模型上的命中率在不到一周内从“约 85% 提升到稳定超过 90%”。关于 GitHub Copilot 的评价称，过去几个月里，需要重新处理的输入比例比之前的基准减少了 50% 以上。两者都是 OpenAI 在自家页面上发布的客户引言，并非独立测量。
• Anthropic：文档中没有实际的命中率数字。Rate limits 页面有一个计算示例：“命中率为 80% 时，每分钟 200 万 token 的输入限制实际上可处理每分钟 1000 万 token”，但这是基于假设的算术，不是测量结果。

第三方数据：不能直接用来判断孰优孰劣

Requesty 是一家把请求路由到多个 AI API 的服务商，它汇总了经过自家网关的请求，公布了2026 年 4 月的命中率：Anthropic 直连 77%（表中为 77.50%），OpenAI 36%（36.40%）（“Prompt-cache hit rate per provider, April 2026”，5 月 9 日更新）。表面上看 Claude 的命中率是 OpenAI 的两倍多，但有四个理由说明这些数字不能用于本文的比较。

1. 数据早于 OpenAI 的改动：OpenAI 在 9 月 22 日才引入 30 分钟保留和显式断点，4 月的数据是在那之前的。
2. 工作负载不同：这些结果来自不同用户的应用，通过网关以不同间隔发送不同的提示，而不是把同一个提示分别发给两家。在 Claude 上只统计了用户自己加了 cache_control 的请求。
3. 分母问题：页面写的是“cached_tokens ÷ input_tokens”，但正如第 6 节所述，Claude 的 input_tokens 不包含缓存的 token。页面没有说明是如何换算的。
4. 页面前后矛盾：经由 Google Cloud（Vertex）的 Claude，一处写的是 24%，另一处写的是 14%。

截至 2026 年 10 月 3 日我们的检索，没有找到在相同条件下比较两种缓存的第三方测量。归根结底，要知道缓存在你的应用里是否有效，唯一的办法是用自己的用量数据去测。用第 6 节的公式计算命中率和费用，如果未命中，就用诊断功能找出原因。

总结

OpenAI 与 Claude 的提示缓存基本思路相同：复用完全相同的前缀，读取按输入价格的 0.1 倍左右计费。区别在于，OpenAI（GPT-5.6 及以后）默认启用，缓存至少保留 30 分钟，写入收 1.25 倍；Claude 则只有加上 cache_control 才缓存，保留 5 分钟（可选 1 小时），写入收 1.25 倍（1 小时为 2 倍）。

价格方面，由于写入要额外付费，从未被读取的缓存就是亏损。5 分钟和 30 分钟缓存读取 1 次即可回本，Claude 的 1 小时缓存需要 2 次。请求间隔在 5 到 30 分钟时，OpenAI 的 30 分钟 TTL 更有优势，在 Claude 上选择 1 小时可以避免逆转。如果请求间隔比 TTL 还长，不用缓存反而更便宜。

确认缓存是否生效，要看 usage 中的读取量和写入量。Claude 的 input_tokens 只包含断点之后的部分，所以要先算出合计，再算命中率。未命中时，OpenAI 的 prompt_cache_diagnostics 和 Claude 的 diagnostics 会告诉你请求与之前哪里不同。其他省钱方法请参阅“AI 使用费与 token 节省指南”。

FAQ

Q. OpenAI 提示缓存的 TTL 是多少？

A. GPT-5.6 及以后的模型为最后一次写入或复用后至少 30 分钟。prompt_cache_options.ttl 只接受 "30m"，指南说缓存可能保留得更久。GPT-5.5 及更早的模型用 prompt_cache_retention 选择：in_memory 为空闲约 5 到 10 分钟（最长 1 小时），24h 最长 24 小时。

Q. Claude 提示缓存的 TTL 能延长吗？

A. 可以，"cache_control": {"type": "ephemeral", "ttl": "1h"} 即为 1 小时。写入价格是输入价格的 2 倍，所以缓存至少被读取 2 次才划算。如果你以不到 5 分钟的间隔持续使用，5 分钟缓存会在每次读取时免费刷新。两者都从请求开始时计时，因此生成长回答所花的时间也会计入 TTL。

Q. 缓存会改变回答吗？

A. 不会。两家的文档都说缓存不影响输出的生成。保存的是读取输入时的中间计算结果，而不是回答本身。和不使用缓存时一样，相同的输入并不总是产生相同的回答。

Q. 可以手动清除缓存吗？

A. 两个平台都不能。OpenAI 表示缓存会按照 TTL 和设置过期，Anthropic 表示缓存在至少 5 分钟未使用后自动删除（如果选择了 1 小时，则为 1 小时）。如果想替换提示内容，只要改变前缀，下一个请求就会写入新的缓存。

参考资料

• OpenAI API 文档：Prompt caching
• OpenAI API 文档：Prompt cache diagnostics
• OpenAI API 文档：Pricing
• OpenAI：Better prompt caching for GPT-6（2026 年 9 月 22 日）
• Claude Platform 文档：Prompt caching
• Claude Platform 文档：Cache diagnostics
• Claude Platform 文档：Pricing
• Claude Platform 文档：Rate limits
• Requesty：Prompt-cache hit rate per provider, April 2026

所有来源均于 2026 年 10 月 3 日核对原文。价格、TTL 和最小长度可能随新模型推出而变化，使用前请在各厂商的价格页面确认。本文的费用计算是基于官方价格的算术，并非我们实际调用 API 测得的结果。