一次 Claude Code 任务到底多少钱

月度数字藏住了任务

月平均值是诚实的会计、无用的方向盘。在同一个开发者的同一个月里，任务级的成本差异远大于人级差异——同一个任务形状不同，成本能差一个量级，跟努力程度无关。三种形状几乎覆盖 agent 的一切：

1. 外科手术式修 bug。轮次少、上下文紧、文件早读过——缓存干了大部分活。最便宜的形状，也是让 agent 用起来「感觉免费」的那种。
2. 脚手架或新功能。轮次多，但上下文按可预测的节奏增长，稳定前缀（指令、规范、已写文件）缓存效果好。中等成本，且非常可预测。
3. 深度重构或马拉松会话。几百轮、上下文一轮轮滚雪球，缓存命中率对账单的影响超过模型牌价。预算就是死在这的。

上下文滚雪球

让第三种形状变贵的机制：agent 在链路上是无状态的。第 15 轮要把此前的对话整个重发——系统提示、读过的文件、工具结果一个不少。每轮输入随历史增长，哪怕每 token 单价不变，长会话的单轮成本也在爬坡。切成有边界的小任务，各自的上下文只付一次；一个无限延伸的大会话，等于把全部上下文反复付费。会话形状本身就是成本决策。

同一个任务为什么账单不同

两个人跑同一个重构，账单差很远。按影响排序的常见原因：缓存行为（稳定前缀被廉价重读 vs 易变前缀每次冷读重付）、会话纪律（开新的有边界的会话 vs 一个滚动的巨型会话）、模型路由（每一步都上旗舰 vs 只在硬骨头时上）。这些都不写在牌价上——只写在逐请求明细里，那是唯一能裁决「这个为什么贵」的地方。

按任务计量，按任务决策

如果你的网关支持给请求打标或按项目分 Key，任务就成了你的成本单位：这次重构花了这么多、这条 bugfix 通道每周花那么多。正是这个颗粒度让月度预算站得住（见上一篇）——你不再争论一个魔法平均数，而是在读一本按任务的账。没有打标能力时，切分会话+按项目分 Key 是可用的替代。