claude code token 计费

很多人第一次看 Claude Code 的用量记录会愣一下：明明只是让它改一个函数，消耗却比自己手敲进对话窗口大得多。原因不在模型，而在这类编程客户端的工作方式——它每轮都要把文件、目录、历史回执重新塞进上下文。这篇按「钱花在哪一步」来讲，给一套看用量、对账单、判断该不该换计费方式的顺序。

很多人第一次翻 Claude Code 的用量记录会愣一下：明明只是让它改一个函数，消耗却比自己手敲进对话窗口大得多。问题不在模型本身，而在这类编程客户端的工作方式——它每轮都要把文件内容、目录结构、历史回执重新塞回上下文，再发一次请求。

所以看账单的正确姿势不是盯总价，而是按「钱花在哪一步」拆开看。下面给一套顺序：先认清三块开销，再看缓存与工具调用怎么算，然后自己按用量记录倒推一遍，最后判断该不该换计费方式。全程不写死任何数字，具体金额到站内页面核对当时的价目。

一轮任务里 token 到底花在哪几步

一轮任务大致有三块开销：一是对话历史重发，二是读取的文件与目录内容，三是工具调用的请求参数和返回结果。聊天窗口里你只发一句话，编程客户端却要把整个工作现场一起发出去，这就是差距来源。

判断方法很朴素：对着用量记录看输入与输出的比例。如果输入远大于输出，说明主要成本在重发上下文，而不是模型在生成答案。这时优化方向是缩短会话、减少无关目录被读进来。

• 同一件事，让客户端自己翻仓库和直接把文件贴进对话，消耗结构完全不同；前者多出大量读取类输入
• 上下文越长，后续每一轮的重复输入越贵，这是编程客户端比聊天窗口烧钱的根因
• 如果一次任务只改一个文件、没让它探索目录，输入输出比例会明显更健康
• 连续追问多轮要小心：每一轮都在为前面所有轮次付费

缓存命中和工具调用，在账单上是什么样

缓存写和缓存读通常是分开计价的，两者单价与普通输入并不相同，别把它们当成同一项去算平均值。忽略这个区别，倒推出来的花费会明显偏低。

缓存写

把上下文首次存进缓存的动作，单价通常高于普通输入

缓存读

复用已有缓存的动作，单价通常低于普通输入，命中率越高越省

工具调用

一次任务里几十次小调用的参数与返回都会计入 token，叠加起来不可忽略

缓存命中依赖前缀稳定。中途改系统提示、换工作目录位置、插入一段新的说明，都可能让前缀变化、命中率掉下来。要验证的话，盯两次结构相似任务的缓存读占比，差异明显就说明前缀不稳。

自己核一遍：从用量记录倒推出花费

1. 拆项统计把用量记录按输入、输出、缓存写、缓存读四类分开加总，不要先合并成一个总数，否则后面乘单价时会错位。
2. 核对单价拿官方价目页对照当天的单价，编程客户端和普通 API 走的是同一套 token 单价口径，到 /price-watch 核对当时的数字即可。
3. 换算成单次任务成本用总花费除以任务次数，得到「一次任务大约多少钱」，比盯着百万 token 单价更有判断力。
4. 用工具复核到 /tools/token-price-calculator 和 /tools/model-cost-calculator 做换算，避免手算把缓存读写混进去。

倒推时最容易犯的错是把缓存读当成普通输入。四类分开统计、各自乘对应单价再相加，结果才接近账单。如果账面对不上，先怀疑是不是漏了工具调用那一块。

什么时候该换计费方式，什么时候不用折腾

换不换的核心不是单价高低，而是你的用量形态。高频、长会话、反复改同一个仓库的人，按量计费容易失控；零散、每次都是独立小任务的人，订阅额度多半用不满，反而按量更合适。

换之前先确认额度口径：是按请求数、按 token 还是按折算价，三者差别很大。同一档订阅，在这三种口径下适合的人群完全不同。到 /coding-plans 和 /plans 对着当时的档位数字比，别凭印象决定。

• 先连续记一周自己的任务次数和时长，再谈换不换
• 把「额度口径」问清楚，比问「多少钱」更重要
• 换过去之后留一周观察期，对比同样的活花掉多少
• 如果主要是上下文重发导致的消耗，先优化用法可能比换方案更划算