用 Claude Code 写代码的人常卡在同一个地方：月底看账单，发现花的钱和「我大概问了几次」完全对不上。原因多半不是被多收，而是没搞清 Claude Code 到底怎么调官方 API——它是多轮、带工具、带系统提示的连续请求，一轮任务背后可能是几十次调用。这篇把计费口径和成本归属拆开讲，给你一套能自己核账的判断方法，具体单价去站内对应页面核对。
用 Claude Code 写代码的人常卡在同一个地方：月底看账单，发现花的钱和「我大概问了几次」完全对不上。原因多半不是被多收，而是没搞清 Claude Code 到底怎么调官方 API——它是多轮、带工具、带系统提示的连续请求，一轮任务背后可能是几十次调用。
这篇把计费口径和成本归属拆开讲，给你一套能自己核账的判断方法。具体单价、倍率这类会变的数字，一律去站内对应页面核对当时的数值，本文只讲算法和归属。
Claude Code 的一次任务，钱花在哪几步
先建立一个基本认知：Claude Code 不是聊天框。你敲一句「帮我加个登录接口」，它背后是读文件、看目录结构、跑一次测试、改代码、再自检的连续过程。每一步都可能触发一次或多次 API 调用，账单是按调用累加的，不是按你敲的那句话累加。
- 一个任务不是一次请求：读文件、跑命令、改代码、自检各自触发调用，账单按调用累加
- 计价项至少四块——输入、输出、缓存写、缓存读，只看「输入输出」两列会算错
- 工具调用的定义、参数、返回结果都算输入 token，返回越长下一轮越贵
- 判断标准：如果账单条数远多于你手动提问的次数，先怀疑任务轮数，而不是单价
| 环节 | 算不算钱 | 常见误判 |
|---|---|---|
| 你输入的那句话 | 算，但只占一小块 | 以为这就是全部 |
| 读文件、看目录的返回 | 算输入 | 以为读文件免费 |
| 模型改代码的输出 | 算输出 | 低估，输出通常最贵 |
| 跑测试/命令的回显 | 算输入，且会滚进下轮 | 忽略，其实很吃量 |
| 缓存命中的重复上下文 | 按缓存口径算，通常更低 | 以为所有输入一个价 |
判断标准很简单：把一次典型任务的调用次数数出来，乘上平均单次量的单价，再和你一个月的实际用量对。对不上的缺口，通常就藏在上面这张表里被忽略的那几行。当任务很短、每次都是全新文件、几乎没有上下文复用时，缓存这块的差异可以忽略，别为省这点钱把流程搞复杂。
缓存和上下文长度怎么改变单价
缓存是 Claude Code 省钱的關鍵，但它不是白给的。命中缓存的部分通常比常规输入便宜，可第一次写入缓存往往要额外付一次。短会话、一次性任务经常省不回来，长会话、反复改同一个项目才划算。
上下文长度的影响更直接：上下文越滚越长，每一轮都要带上历史，钱是叠加的不是平摊的。一个开了几小时没清理的会话，后期每轮都在为前面所有内容付费，哪怕你只问了一句「继续」。
| 场景 | 缓存是否划算 | 原因 |
|---|---|---|
| 长会话反复改同一项目 | 划算 | 系统提示和文件反复命中 |
| 每次都是全新文件 | 不划算 | 写缓存的钱收不回来 |
| 短任务、问完就关 | 不划算 | 首次写入成本摊不开 |
| 自动化脚本长时间跑 | 看情况 | 重试多反而更贵 |
- 先看总调用次数从后台用量导出或客户端日志里把调用条数拉出来，和你印象里的提问次数比，差距大就是轮数问题
- 再看平均单次输入长度看是否有单次特别大的调用，通常是某个文件或某次命令回显超长
- 最后看缓存命中比例命中低说明会话策略有问题，命中高但总量还涨，说明是任务本身变重了
- 按影响从大到小排先解决调用次数，再解决单次长度，最后才调缓存策略，顺序反了效率低
走官方直连还是中转，成本归属怎么变
计价口径讲完，更实际的问题是钱算在谁头上。官方直连时成本归属清晰：Key 是谁的，账单就是谁的，后台能按 Key 和时间段把用量拆开。适合按项目追账的团队。
走中转时，你看到的是中转方的计价口径，倍率、分组、最低消费都可能叠加，终端单价和官方不一定是一一对应关系。想知道具体差多少，去站内价格追踪页面核对当时的数值，不要凭印象。
- 官方直连
- 成本归属清晰，按 Key 可分账，适合按项目复盘
- 中转接入
- 计价口径由中转方定，需单独核对倍率和分组
- 共享 Key
- 多人共用一把 Key，账目会混，追账基本做不成
- 按人分账
- 每人一把 Key，最容易厘清，但管理成本略高
- 按项目分账
- 一个项目一把 Key，适合小团队，个人项目无所谓
判断标准：只要求能按项目追账，就别用一把全团队共用的 Key。一家 5 人小团队如果图省事共用一把，月底谁也说不清是谁跑出来的量，复盘无从下手。这类共用 Key 的具体风险，站内已有专门文章讲，这里不重复。
事前估、事后核：一套可执行动作
最后给你一套能直接上手的动作，分事前和事后两段。事前估的目的是得到一个成本区间，不是精确值；事后核的目的是找出异常，不是逐条审计。两者结合，你才能对账单有掌控感。
- 选一个典型任务挑一个你团队天天都在做、复杂度中等的任务，别挑最简单的也别挑最复杂的
- 记录调用轮数和大致 token 量跑一次，把轮数和量记下来，乘当时单价得到单任务成本区间，单价去站内页面核对
- 事后按天按项目对账用后台用量导出，重点看有没有异常的峰值日，峰值日往往藏着问题
- 排查顺序固定先看上下文策略有没有变、再看有没有脚本无人看管时反复重试、最后看共享 Key 有没有被别人用
如果账单突然翻倍，别急着怀疑单价涨了。按上面顺序走一遍，绝大多数情况是轮数变多、某段上下文被反复带上、或者一个自动化脚本在后台一直跑。单价和倍率这类会变的数字，一律以站内页面当时显示为准。
下一步：把单价和用量一起对一遍本文只讲算法和归属，具体单价、倍率会随时间和渠道变化，去站内价格追踪页核对当时的数字，再回头套上面的方法估自己的任务成本。→常见问题
Claude Code 是按次收费还是按 token 收费？
走官方 API 时是按 token 按量计费，不是按「问了几次」收费。一个任务会拆成很多次调用，每次调用按输入、输出、缓存各计价项累加，所以次数少不等于钱少，要看总 token 量和上下文长度。
为什么我用 Claude Code 感觉比在聊天框里问贵很多？
聊天框一轮问答就是一次请求，Claude Code 一个任务里会反复读文件、调工具、自检，轮数和上下文都比聊天框高一个量级，而且每轮都要带上之前的历史。贵的是调用次数和上下文累计，不是被多收，想省就先控制任务粒度和会话长度。
用中转站的 Key 跑 Claude Code，账单以谁为准？
以中转站的计价口径为准，它可能按倍率、分组或套餐折算，和官方单价不是简单对应关系。要看清楚计价项、有没有最低消费和有效期，建议小额实测一次再放大用量；官方那边的原始口径可到站内官方 API 价格页对照。
