OpenCode 缓存命中率实测

按 2026-09-29 这一周的实测,OpenCode 用 Claude 模型时,连续对话的缓存命中率中位数是 96.5%(7 个用户),全部请求算是 90.3%。没命中的部分主要来自:换上游账号(37%)、连续对话中的新内容(31%)、缓存过期(19%)。

数据周:2026-09-29 – 2026-10-05(UTC)

关键结论

  • 正常值: 96.5%, 7 个用户连续对话的中位数,中间一半在 94.4%–97.5%
  • 全部请求: 90.3%, 含换号、过期、新对话等全部未命中
  • 最大的未命中原因: 换上游账号, 占未命中的 37%

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

数据周:2026-09-29 – 2026-10-05(UTC)

  • 连续对话命中率(用户中位数): 96.5%
  • 中间一半用户: 94.4%–97.5%
  • 达标用户: 7 (一周至少 20 个连续轮次)
  • 全部请求的命中率: 90.3%

为什么 OpenCode 缓存命中率低:未命中原因拆解

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

被路由到另一个上游账号或端点: 占未命中的 37%, 约占全部输入 3.5%
提示缓存保存在处理请求的那个上游账号里。中转站或多账号网关把同一对话的下一条请求发到另一个账号时,整段上下文要重新写入。直连官方不会出现这一项。
连续对话里的新增内容和前缀变化: 占未命中的 31%, 约占全部输入 3.0%
每一轮新增的内容第一次出现时只能写入、不能读取,这部分无法避免;系统提示、工具列表或历史被改写时,前缀也会失效。
间隔超过 5 分钟,缓存已过期: 占未命中的 19%, 约占全部输入 1.8%
两次请求之间停了 5 分钟以上,上一次写入的缓存可能已经过期。
新对话,或闲置超过 1 小时: 占未命中的 13%, 约占全部输入 1.3%
新对话的第一条请求,或闲置超过 1 小时后,只能重新写入缓存。
并行请求(上一条还没结束): 占未命中的 1%, 约占全部输入 0.1%
上一条请求还没结束就发出下一条(子代理、并行工具调用),后一条读不到前一条正在写入的缓存。
换了模型: 占未命中的 0%, 约占全部输入 0.0%
每个模型有独立的缓存,换模型后下一条请求要重新读入整段历史。

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

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

  • 本周中位数 96.5%: $0.37 (×1.0)
  • 90%: $0.68 (×1.9)
  • 80%: $1.16 (×3.2)
  • 50%: $2.60 (×7.1)

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

怎么查看 OpenCode 的缓存命中率

  • Anthropic 格式:cache_read_input_tokens ÷(input_tokens + cache_read_input_tokens + cache_creation_input_tokens)。
  • OpenAI 格式:cached_tokens(在 prompt_tokens_details 或 input_tokens_details 里)÷ prompt_tokens / input_tokens。
  • 通过 Wokey 使用时,控制台的请求明细里每条请求都有缓存读取和缓存写入两列。

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

  • 换账号:缓存属于上游账号,下一条被发到另一个账号就要整段重写。这是中转站最常见的原因,直连官方不会有。
  • 协议转换:把 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 用户;不同用户的使用习惯差别很大;全部请求的命中率里包含网关自身的路由损失(见"被路由到另一个上游账号"一项)。

常见问题

OpenCode 的缓存命中率多少算正常?

本周 7 个用户的连续对话命中率中位数是 96.5%,中间一半用户在 94.4%–97.5%;把所有请求都算上是 90.3%。

为什么我的 OpenCode 缓存命中率低?

本周没命中的部分主要来自:换上游账号(37%)、连续对话中的新内容(31%)、缓存过期(19%)。页面上按原因列出了对应的做法。

缓存命中率低会更快用完 Claude 订阅额度吗?

会。按我们对 Claude 订阅额度的实测,缓存读取几乎不占额度,缓存写入和未缓存输入占用的额度差不多。同一段上下文命中时几乎不花额度,没命中就要整段重新计入。各档额度见 Claude 订阅额度实测页(/claude-usage-limits)。