Skip to main content
Claude 上下文缓存(Prompt Caching)适合反复使用的长前缀,例如系统提示、参考文档、代码库或多轮对话历史。在稳定前缀的最后一个内容块上加 cache_control,首次请求会写入缓存,有效期内的后续请求直接读取缓存。
上下文缓存通过 Claude 消息接口 POST /v1/messages 使用。经 /v1/chat/completions 调用 Claude 时,不保证 cache_control 会生效。

适用场景

  • 长系统提示:角色设定、规则手册、Few-shot 示例。
  • 文档问答:同一份合同、论文或手册上的多次提问。
  • 代码助手:把仓库关键文件作为固定上下文。
  • 多轮对话:缓存截至上一轮的对话历史。

5 分钟缓存

在需要缓存的内容块上添加 cache_control。省略 ttl 时有效期为 5 分钟:
system 必须写成内容块数组。字符串形式的 system 无法添加 cache_control。

1 小时缓存

需要同时添加 anthropic-beta 请求头,并把 ttl 设为 1h:

缓存消息内容

cache_control 也可以放在 user 或 assistant 消息的内容块上,用来缓存长文档或多轮对话前缀。把稳定内容和当前问题拆成不同的内容块,只在稳定内容块上添加 cache_control:
单次请求最多可以设置 4 个缓存断点。

用量字段

响应的 usage 中会分别返回普通输入、缓存写入和缓存读取的 token 数:
三项输入互不重叠,总输入 token 为 input_tokens + cache_creation_input_tokens + cache_read_input_tokens。首次请求通常 cache_creation_input_tokens > 0;再次发送相同前缀时,应看到 cache_read_input_tokens > 0。

计费

具体单价以 模型价格 为准,每次请求的缓存用量和扣费可以在 使用日志 中查看。

缓存命中条件

缓存前缀通常至少需要 1024 token(部分模型为 2048 或 4096)。前缀不足时,cache_control 会被忽略,且不会报错。
缓存前缀中的文字、空格、换行、图片和内容块顺序都必须保持一致。不要在稳定前缀中放时间戳、随机 ID 等动态内容。工具定义、system、messages 依次构成前缀,任何一处变化都会让其后的缓存失效。
有效期从最后一次访问开始计算,每次命中都会刷新有效期。
如果请求触发模型拒答(stop_reason 为 refusal),即使报告了缓存写入,该缓存也不会在下次请求中被读取。

最小可复现示例

下面的脚本生成一个足够长的稳定前缀,连续发送两次相同请求。第二次响应应出现 cache_read_input_tokens > 0:
预期结果:

排查清单

缓存没有命中时,按顺序检查:
  • 是否通过 /v1/messages 调用
  • system 是否写成内容块数组,cache_control 是否放在具体内容块上
  • 缓存前缀是否达到模型的最低 token 数
  • 两次请求的稳定前缀是否逐字节相同
  • 1 小时缓存是否同时设置了 ttl: "1h" 和 anthropic-beta 请求头
  • 两次请求间隔是否超过有效期
  • stop_reason 是否为 refusal