Sign in Subscribe
Claude Code

Claude Code 账单为什么和价格页不一样？一次19轮对话，把Prompt Cache账算给你看

中转平台价格页只给两个单价，但Claude Code这类连续会话场景，真正决定账单的是Prompt Cache命中率。这篇用一次19轮对话拆开算账单，附灵眸AI实测命中率长期高于90%的数据和验证方法。

Claude Code 账单为什么和价格页不一样？一次19轮对话，把Prompt Cache账算给你看
Photo by Towfiqu barbhuiya / Unsplash

如果你在国内用 Claude Code，大概率算过这道题："官方说 Opus 输入 $15/M，中转平台报价¥6/M，那我这个月到底要花多少钱？"——答案是，光看这两个单价，你永远算不对。真正决定账单的是 Prompt Cache 命中率，不是价格页上那两个孤立数字。这篇把一次19轮对话的完整账单拆开算给你看，也顺手把我自己在灵眸AI（api.lmuai.ai）上实测的缓存命中率数据放出来对照。

先看结论：命中率比模型选择更影响账单

同一个任务，缓存命中率从60%提到90%以上，成本能再降一半以上。这个差距，价格页永远不会替你算出来，因为价格页只给你两个数字（输入价、输出价），不会告诉你缓存写入和缓存读取分别按什么比例计费，更不会告诉你你自己的对话结构能不能撑起高命中率。

拆解：给一个函数加类型校验，跑了19轮对话

任务场景：给一个中等规模TypeScript项目的表单模块补类型校验，涉及6个文件联动修改。全程用 Claude Code 跑完，共19轮 user-assistant 交互，前3轮用 Opus 做复杂度分析和方案设计，后16轮切到 Sonnet 做具体改写——这是 Claude Code /model 命令做的事，主动降级模型复杂度本身就是省钱的第一步，跟 Cache 命中率是两件独立要做对的事。

说明：下面这张逐轮 usage 表格是按 Prompt Cache 协议机制还原出的示例数据，用来演示计算方法，不是某一次的抓包记录，但比例关系（模型切换时 Cache 重建、命中率上升后趋于稳定）符合协议规则和真实使用中的普遍规律，你可以直接套自己的真实 token 数重新跑一遍。

轮次 模型 input_tokens cache_creation cache_read output_tokens
1 Opus 420 8,100 0 650
2 Opus 180 1,200 8,100 890
3 Opus 210 400 9,300 720
4 Sonnet 350 2,600 9,700 1,100
5-19（16轮均值） Sonnet 290 180 12,900 980

第4轮 cache_creation 跳高是模型切换导致的一次性重建——Opus 和 Sonnet 的缓存前缀不共享，切换即触发一次冷写入，从第5轮起命中率迅速回到高位并保持稳定。

按官方计费口径（缓存写入按输入价1.25倍，缓存读取按输入价0.1倍）分段算完，这19轮里输入token总量看起来不大（约6,000），但缓存读取总量达到23万+，是整个任务里最大的一块开销。按"表面价格"估算成本，基本都会漏掉这部分。

三种命中率场景，成本差多少

场景 说明 相对无Cache的成本比例
无Cache 每轮携带完整历史全量输入 100%（基线）
命中率60%（保守估算） 断点安置不规范、部分字段volatile 约47%
命中率90%+（本文场景） 断点安置合理、前缀无volatile字段 约22%

同一次任务，命中率从60%提到90%以上，成本再降一半以上。两个平台单价写得一样，一个命中率60%一个90%，真实账单能差出一倍以上——这才是接入前真正该问清楚的问题，不是价格页上那两个数字。

我自己在灵眸AI上实测的数字

我这几个月接 Claude Code 走的是灵眸AI（https://api.lmuai.ai），官方口径统计的实测 Prompt Cache 命中率长期高于90%（Claude Code连续会话场景，按 cache_read_input_tokens 占输入token总量的比例统计），量级上跟本文场景里第5轮之后的稳定命中率一致——说明这不是理论上限，是能在真实生产环境里持续维持的水平。

按量计费单价（2026年6月起，¥10起充，人民币价=官方美元价×1.2）：

模型 官方输入价 灵眸AI输入价 官方输出价 灵眸AI输出价 缓存读取价
Claude Opus 系列 $15/M ¥6/M $75/M ¥30/M ¥0.60/M

按30/70输入输出加权，灵眸AI这条线加权单价约**¥22.80/M**，约官方1.8折——这还只是按量档，月套餐档折扣力度更大，¥10起充可以自己小额验证，不用先信我说的。

自己验证：中转层有没有老实转发 Cache 字段

不用信任何平台的自我描述，连发两次相同前缀的请求，看第二次 cache_read_input_tokens 是否明显大于0：

curl "https://api.lmuai.ai/v1/messages" \
  -H "x-api-key: $YOUR_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: prompt-caching-2024-07-31" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-8",
    "max_tokens": 20,
    "system": [{"type":"text","text":"<2000字以上的system prompt>","cache_control":{"type":"ephemeral"}}],
    "messages": [{"role":"user","content":"hi"}]
  }' | jq '.usage'

cache_creation_input_tokens 和 cache_read_input_tokens 这两个字段，官方协议一定会给，某些逆向或转发层可能缺失或恒为0——如果始终为0，说明这层机制在中转环节被吞掉了，实际成本会比价格页数字看起来的更高。灵眸AI 走的是标准 Anthropic 原生协议，这两个字段完整透传。

Claude Code 接入配置

~/.claude/settings.json：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.lmuai.ai",
    "ANTHROPIC_AUTH_TOKEN": "在灵眸AI后台生成的sk-开头密钥"
  }
}

配好之后正常用 /model 切换 Opus/Sonnet 就行，不用改任何调用逻辑，缓存断点由 Claude Code 客户端自己打，灵眸AI 这边只负责老实转发。

单价表之外，真正该看的三件事

  1. 断点是不是被volatile字段污染：session_id、时间戳、动态生成的id混进system或历史消息里，前缀逐字节匹配就会被打破，命中率长期卡在低位，自己却很难察觉。
  2. 模型切换是否会重建缓存：不同模型的缓存前缀通常不互通，一次任务里频繁切换模型，每次都是一次冷启动写入。
  3. 中转层是否老实透传这两个字段：官方协议一定有，验证方法就是上面那个curl命令。

常见问题

命中率90%是不是所有场景都能达到？

不是。本文场景设定的是断点安置规范、任务内部无多意图切换的情况。命中率会随会话结构变化，做预算估算建议用60%这类保守值。灵眸AI 的90%+是官方统计的实测均值，不是承诺每次任务都能达到这个数字。

灵眸AI 和官方直连的价格差是怎么做到的？

按量计费加权单价约¥22.80/M，约官方1.8折，官方协议原生转发，不改字段、不掺假模型。建议接入前自己发一次带 cache_control 的请求验证 usage 字段完整性，而不是直接相信任何平台的宣传页。

这套账单计算方法只适用于Claude系列吗？

计费口径（写入1.25倍、读取0.1倍）是Anthropic协议特有的，其他厂商的缓存机制和计费比例不同，不能直接套用这套数字，但"命中率主导真实成本、单价表只是起点"这个结论具有普遍性。

参考资料

数据核实时间：2026年8月。文中逐轮usage表格为演示计算方法用的构造示例，价格随时可能调整，接入前建议自行核对官网实时页面。想直接体验的可以从这里开始：api.lmuai.ai，新人有免费额度。

Read next