cache_control,首次请求会写入缓存,有效期内的后续请求直接读取缓存。
上下文缓存通过 Claude 消息接口
POST /v1/messages 使用。经 /v1/chat/completions 调用 Claude 时,不保证 cache_control 会生效。适用场景
- 长系统提示:角色设定、规则手册、Few-shot 示例。
- 文档问答:同一份合同、论文或手册上的多次提问。
- 代码助手:把仓库关键文件作为固定上下文。
- 多轮对话:缓存截至上一轮的对话历史。
5 分钟缓存
在需要缓存的内容块上添加cache_control。省略 ttl 时有效期为 5 分钟:
1 小时缓存
需要同时添加anthropic-beta 请求头,并把 ttl 设为 1h:
缓存消息内容
cache_control 也可以放在 user 或 assistant 消息的内容块上,用来缓存长文档或多轮对话前缀。把稳定内容和当前问题拆成不同的内容块,只在稳定内容块上添加 cache_control:
用量字段
响应的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

