Claude Code 缓存命中率实测

关键结论

• 正常值: 96.8%, 120 个用户连续对话的中位数，中间一半在 94.9%–98.1%
• 全部请求: 90.9%, 含换号、过期、新对话等全部未命中
• 最大的未命中原因: 换上游账号, 占未命中的 37%
• 各形态之间: 相差 4.0 个点, 命令行、桌面应用、桌面端本地代理

各客户端的缓存命中率多少算正常

数据周：2026-09-29 – 2026-10-05（UTC）

• 连续对话命中率（用户中位数）: 96.8%
• 中间一半用户: 94.9%–98.1%
• 达标用户: 120 (一周至少 20 个连续轮次)
• 全部请求的命中率: 90.9%

Claude Code 各形态的命中率

同一客户端的命令行、IDE 插件和桌面应用发出的请求基本相同，命中率也应接近。

• 命令行: 97.2% (59)
• 桌面应用: 96.2% (39)
• 桌面端本地代理: 96.2% (22)
• VS Code 插件: 96.8% (15)
• Agent SDK（CLI）: 93.3% (7)

Claude Code 各版本的命中率

某个版本改动了请求前缀时，它的命中率会明显低于其他版本；这张表在出问题的那一周就能看出来。

• 2.1.289: 98.8% (17)
• 2.1.288: 96.8% (13)
• 2.1.287: 97.7% (14)
• 2.1.286: 97.3% (38)
• 2.1.285: 97.7% (16)
• 2.1.284: 95.5% (38)
• 2.1.283: 97.0% (10)
• 2.1.281: 94.0% (22)
• 2.1.280: 95.9% (10)

为什么 Claude Code 缓存命中率低：未命中原因拆解

本周全部输入里有 9.1% 没有从缓存读取。下面按原因拆开，每一类给出可以做的事。

被路由到另一个上游账号或端点: 占未命中的 37%, 约占全部输入 3.4%

提示缓存保存在处理请求的那个上游账号里。中转站或多账号网关把同一对话的下一条请求发到另一个账号时，整段上下文要重新写入。直连官方不会出现这一项。

连续对话里的新增内容和前缀变化: 占未命中的 22%, 约占全部输入 2.0%

每一轮新增的内容只能写入、不能读取。连接或断开 MCP 服务器、启用带 MCP 的插件会改变工具定义，整个缓存随之失效。

并行请求（上一条还没结束）: 占未命中的 15%, 约占全部输入 1.4%

子代理和并行工具调用会在上一条请求结束前发出下一条。Claude Code 的 fork 会复用父会话的缓存，普通子代理用自己的系统提示和工具，各自建缓存。

间隔超过 5 分钟，缓存已过期: 占未命中的 12%, 约占全部输入 1.1%

缓存默认保留 5 分钟，每次命中都会免费续期。如果你经常停下来超过 5 分钟，可以设 CLAUDE_CODE_PROMPT_CACHE_TTL=1h（v2.1.242 起支持），代价是缓存写入从输入价的 1.25 倍变为 2 倍。

换了模型: 占未命中的 8%, 约占全部输入 0.8%

每个模型有独立缓存。用 /model 切换后，下一条请求会把整段历史当作未命中重新读入，内容完全相同也一样。

新对话，或闲置超过 1 小时: 占未命中的 6%, 约占全部输入 0.5%

新对话的第一条请求，或闲置超过 1 小时后，只能重新写入缓存。

命中率差几个点，账单差几倍

按 Claude Opus 5.5 官方价，未命中部分按 5 分钟缓存写入计，每百万输入 token 的实际成本：

• 本周中位数 96.8%: $0.35 (×1.0)
• 90%: $0.68 (×1.9)
• 80%: $1.16 (×3.3)
• 50%: $2.60 (×7.3)

用 Claude API 费用计算器按自己的用量算

Claude Code 缓存多久失效（TTL）、怎么收费

• 默认保留 5 分钟，每次命中都会免费续期。
• 可改为 1 小时：设 CLAUDE_CODE_PROMPT_CACHE_TTL=1h（v2.1.242 起；子代理用 CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL），旧版用 ENABLE_PROMPT_CACHING_1H=1。
• 缓存写入按输入价的 1.25 倍（5 分钟）或 2 倍（1 小时）计费；读取一般是 0.1 倍，Opus 5.5 和 Sonnet 5.5 是 0.05 倍。
• 短于最小长度的提示不会被缓存，也不报错：按模型在 512 到 4,096 token 之间。

Anthropic 提示缓存文档 · Claude Code 提示缓存 · Claude Code 环境变量

怎么查看 Claude Code 的缓存命中率

• 在 Claude Code 里运行 /usage：Session 区块的 Prompt cache (main) 一行列出请求数、从缓存读取的输入占比、未命中次数，以及缓存现在是否还有效。
• 状态栏脚本可以读 prompt_cache 字段；OpenTelemetry 导出器按用户和会话上报缓存读取和创建 token。
• 自己算：cache_read_input_tokens ÷（input_tokens + cache_read_input_tokens + cache_creation_input_tokens）。
• 通过 Wokey 使用时，控制台的请求明细里每条请求都有缓存读取和缓存写入两列。

Claude Code 用量与费用

通过中转站使用时，命中率为什么更低

• 换账号：缓存属于上游账号，下一条被发到另一个账号就要整段重写。这是中转站最常见的原因，直连官方不会有。
• 协议转换：把 Anthropic 格式和 OpenAI 格式互相转换时，可能改动前缀或丢掉 cache_control 断点。
• 旧版 Claude Code（v2.1.181 之前）通过自定义 Base URL 时，系统提示开头的署名块每次带不同的 token，按请求体做缓存的网关会全部打不中；升级，或设 CLAUDE_CODE_ATTRIBUTION_HEADER=0。
• 自测：连续发两条前缀相同、超过最小缓存长度的请求，第二条的缓存读取应接近前缀长度。

Wokey 优先把同一对话的后续请求发往同一上游账号。2026-10-04 至 2026-10-10，Wokey 普通用户在 Claude Opus 5.5 上全部请求的命中率为 92.8%，同期 OpenRouter 整体为 87.8%。

对比 OpenRouter 的缓存命中率 · 实时数据：Wokey 公开缓存命中率接口（近 7 天）

怎么测的

• 数据来自 Wokey 网关上真实用户的请求，每周一 05:00 UTC 统计上一周（周一至周日）。
• 客户端按请求的 User-Agent 识别。SDK、HTTP 库和下游中转发来的请求看不出真实客户端，不计入；企业客户不计入。
• 连续轮次：和同一对话的上一条请求同模型、同上游账号，且在其结束后 5 分钟内发出。每个用户的命中率 = 连续轮次的缓存读取 ÷ 输入（输入含缓存读写），取一周至少 20 个连续轮次的用户的中位数。
• 每格至少 5 个达标用户才发布；和上周相比变化超过 3 个百分点时，先人工核对再发布。
• 已知偏差：只覆盖 Wokey 用户；不同用户的使用习惯差别很大；全部请求的命中率里包含网关自身的路由损失（见"被路由到另一个上游账号"一项）。

常见问题