一次 Claude Code 任务到底花多少钱：从标价算到真实账单

用 Claude Code 的人迟早会问一个问题：跑完这一项任务，到底花了多少钱？

这个问题不好回答，因为账单不取决于「任务有多难」，而取决于它跑了多少轮、每轮带了多少上下文、吐了多少输出。同一个任务，跑法不同，成本可以差好几倍。

Opus 5.5 降价之后，单价确实便宜了，但如果跑法不变，省下的钱很容易被多出来的轮次吃掉。这篇把账算清楚，再讲怎么省。

一、先记住四个变量

一次 Claude Code 任务，本质是一个连续的循环：模型读上下文 → 决定调什么工具 → 读工具返回 → 把所有历史和新内容重新打包发回 → 下一轮。

成本由四个要素决定：

• 轮次（Turns）：每一轮都会把截至该轮的所有对话和文件内容重新发送一遍。轮次越多，累计输入越庞大。这是最容易被低估的变量。
• 缓存读取（Cache Reads）：重复发送的历史内容中，有一部分被缓存命中，单价只有新输入的极小一部分。
• 输出 Token：单价最高的类型，是输入的 5 倍。模型的思考过程同样按输出计费——所以想得越多，账单越高。
• 模型单价：决定了每个 Token 的基准价格。

二、Opus 5.5 的单价

每百万 Token：

• 新输入：$4.00（Opus 5 是 $5.00，降 20%）
• 输出（含思考）：$20.00（Opus 5 是 $25.00，降 20%）
• 缓存读取：$0.20（Opus 5 是 $0.50，降 60%）

注意第三条：缓存读取降幅最大，说明官方在鼓励你让上下文保持稳定、提高缓存命中率。这是省钱的主战场。

三、算一笔真实账

代入一个典型场景：任务以 20K Token 的初始上下文启动（系统提示词、规则文件、项目骨架），随着读取代码和工具返回，会话增长到 120K。整个过程平均每轮发送约 70K Token，共 40 轮。

累计输入：40 轮 × 70K = 2.8M Token。

注意这个数字：虽然对话窗口最终只有 120K，但因为每轮重复发送历史，累计处理了 280 万 Token。这就是为什么轮次是成本杀手。

• 如果完全没有缓存命中：2.8M × $4/M = $11.20
• 如果 90% 缓存命中：缓存读取 2.52M × $0.20/M ≈ $0.50；新输入 0.28M × $4/M = $1.12；两项合计约 $1.62
• 再加 6 万输出 Token：0.06M × $20/M = $1.20
• 总计约 $2.82

对比一下：同样的任务，零缓存命中要 $11.20，90% 命中只要 $2.82。差了 4 倍。

结论很直接：省钱的第一优先级不是砍输出，是提高缓存命中率。

四、怎么提高缓存命中率

缓存命中的前提是前缀不变。以下几件事会破坏它：

• 会话中途修改系统提示词
• 中途增删工具列表
• 改动全局参数（比如中途调 effort）
• 频繁切换模型

做法：把系统提示词、工具定义、项目规则在会话开始前一次性定好，中途尽量不动。需要调整的，放到下一轮新会话，而不是在跑着的任务里改。

五、更省钱的顺序

很多人省钱的第一反应是降低 effort 或用便宜模型。这是最后一招，不是第一招。正确的顺序是：

1. 减少返工（收益最大）。给模型可运行的检查——测试命令、lint、构建脚本。它自己能验证，就不用反复来回。一次通过比三次通过省得多。

2. 提高缓存命中率。如上，把会变的东西和不变的东西分开。

3. 按难度选 effort 和模型。简单改动用默认档，复杂重构才拉高。

4. 控制轮次。一次把任务讲清，比中途反复补充省很多。

为什么第一招最有效：返工不只是多一轮，而是多一轮就要重新发送全部历史。一轮返工的代价，可能是十轮正常推进的代价。

六、长会话的两个隐藏成本

• 缓存失效：会话过长、上下文被压缩之后，缓存可能整体失效，之前省的钱一次性吐回去。
• 压缩成本：压缩本身也要消耗 token。

所以长会话不是越长越好。任务做到一个阶段，主动收尾、开新会话、把结论写进文档，往往比继续堆下去更划算。

七、用 /usage 建立自己的基准

每次任务结束，跑一下 /usage，记录三项：缓存读取量、输出量、累计输入量。

然后拿 3-4 个你真实的常规任务，各跑一次，把数据记下来。你会得到一份属于你自己的成本基线。

有了基线之后，任何一次「这次怎么这么贵」都能对照出来：是轮次爆了，还是缓存没命中，还是输出异常多。没有基线，你只能靠感觉，而感觉在成本这件事上通常不准。

八、异常排查清单

账单异常时按顺序查：

1. 轮次是不是远超预期？（说明任务被反复返工）

2. 缓存命中率是不是很低？（说明中途改了系统提示词或工具）

3. 输出是不是异常高？（说明思考开销大，可能任务定义不清）

4. 上下文是不是膨胀过快？（说明读取了过多无关文件）

5. 是不是触发了模型切换？（不同单价会叠加）

收尾建议

今天就做一件事：挑一个你每周都会跑的常规任务，跑完后记录 /usage 的三个数字，写进你的项目文档。

一周之后你就有四个数据点。到那时，你讨论成本就不再靠猜，而是能说清楚「这类任务我这边大概 $2-3，超过 $5 就是异常」。可衡量，才可优化。