Claude Code 用量为什么会莫名飙高：长会话的五个成本来源与对应手段

约 20 分钟难度：进阶理解章

结论

「我今天没干什么，为什么用量这么高」这个问题，答案通常是同一个：Claude Code 每次请求都带上完整对话历史，而且每次 Claude 用工具都是一次新请求，那次请求也带着这批工具结果。

所以在一个开了一整天的会话里问一句一行的问题，代价是整个会话的历史长度。有 prompt caching 兜底，历史按缓存价重读，但仍然计入用量。

推论也很直接：不相关的任务之间 /clear，是省钱手段里投入产出最高的一个，而且 /clear 本身不花钱。

先搞清楚你在看什么数字

/usage 顶部的 Session 区块显示本次会话的 token 统计：

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Total code changes:    0 lines added, 0 lines removed
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

关于这个数字有三件事必须知道：

它是本地算出来的。Claude Code 拿 token 数按标准列表价乘出来，不反映促销价或合同折扣，所以和实际账单可能不一样。权威账单看 Claude Console 的 Usage 页。
Max 和 Pro 订阅用户不用看它。用量已包含在订阅里，这个美元数字对计费没有意义。订阅用户该看的是同一屏上的 plan usage bars 和用量分解。
/clear 之后归零。v2.1.211 之前这些总数会跨 /clear 一直累积到进程结束——如果你的印象是「这个数字只涨不降」，那是旧版本行为。

API duration 和 wall duration 的巨大差距（6 分钟 vs 6.5 小时）本身就是信息：说明会话开了很久但实际请求很少。这种会话正是「一句话的代价是整个历史」的典型场景。

订阅计划上 /usage 还会把最近用量归因到 skills、subagents、plugins 和各个 MCP 服务器，每项显示占比。某个行为占到 10% 以上时会被标出来，比如 long context 或 cache misses。按 d / w 在 24 小时和 7 天之间切换。

这些数字是从本机的会话历史算出来的，其他设备和 claude.ai 上的用量不在内。

/context 是另一个命令，看的是当前上下文里什么在占空间。排查「是不是某个 MCP 服务器把上下文吃掉了」用它。

长会话里用量爬升的五个来源

这五条是分开的机制，对应的手段也不同。

1. 长上下文

每次请求带完整对话，每次工具使用又是一次带着工具结果的请求。这是最主要的来源。

手段：/clear。或者 /compact 带自定义指令保留关键部分。

2. 缓存未命中

休息时间超过缓存生命周期后，第一条消息会未命中缓存，重新处理完整上下文。

缓存生命周期分档：

订阅计划：1 小时
开始动用 usage credits 之后：降到 5 分钟
API key 或云厂商：默认 5 分钟

这解释了一个常见困惑：午饭前后同样问一句话，午饭后那次的代价明显更高。因为中间隔了一小时以上，缓存过期了。

Pro 和 Max 计划上，长时间中断后恢复一个大会话时，Claude Code 会提供「从摘要恢复」的选项，让后续请求不必携带完整历史。

3. 定时任务

定时任务按自己的间隔触发，会话空闲时也会触发，每次都发送完整上下文。

一个配了定时任务的长会话是在持续产生用量，即使你没在用。

4. agent teammate

每个活跃的 teammate 都在消耗 token，直到它退出或会话结束。

teammate 在 plan 模式下运行时，agent team 的 token 用量大约是标准会话的 7 倍——每个 teammate 维护自己的上下文窗口、作为独立的 Claude 实例运行。

所以「活干完了就关掉 teammate」不是礼节问题，是成本问题。

5. 压缩本身

/compact 要读取它要总结的对话，所以压缩一个大上下文本身就是一次大请求。

推论：如果你想要的是「从头开始」而不是「保留连续性」，用 /clear，它不花钱。为了省钱去 /compact 一个巨大的上下文，方向是反的。

省钱手段，按收益排序

不相关任务之间 `/clear`

前面说过了，这是收益最高的一条。陈旧上下文在之后的每一条消息上都在浪费 token。

想保留会话以后再回来：先 /rename 起个能找到的名字，再 /clear，之后用 /resume 回去。

模型选型

Sonnet 处理大多数编码任务都够，成本低于 Opus。把 Opus 留给复杂架构决策和多步推理。

会话中途用 /model 切换，默认值在 /config 里设。简单的 subagent 任务在配置里指定 model: haiku。

「Opus 忘了切回来」是 API 计费和云厂商计费下超支的两大常见原因之一（另一个是长会话没清）。

把冗长操作交给 subagent

跑测试、抓文档、处理日志文件都会产生大量输出。交给 subagent，冗长输出留在 subagent 的上下文里，只有摘要回到主对话。

这是 subagent 除了「分工」之外的第二个价值，而且这个价值更容易量化。

用 hook 做预处理

hook 可以在 Claude 看到数据之前先过滤。Claude 读一个一万行的日志找报错，和一个 hook 先 grep 出 ERROR 行再给它，上下文差异是几万 token 对几百 token。

官方给的例子是一个 PreToolUse hook 改写测试命令，只保留失败信息：

#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')

if [[ "$cmd" =~ ^(npm test|pytest|go test) ]]; then
  filtered_cmd="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered_cmd\"}}}"
else
  echo "{}"
fi

注意这里用的是 updatedInput 改写命令本身，不是过滤输出。这个 hook 的用法比想象的更灵活。

验证方法：/hooks 看它在不在 PreToolUse 下，或者用 claude --debug 跑一次 npm test，debug 日志里会出现 modified tool input keys: [command]。

把 CLAUDE.md 里的专项指令搬进 skill

CLAUDE.md 在会话开始时加载进上下文。里面写着 PR review 或数据库迁移的详细流程，那些 token 在你做完全不相关的工作时也在占位。

skill 是按需加载的，只在被调用时进上下文。把专项流程搬过去，基础上下文就小了。

CLAUDE.md 控制在 200 行以内。

优先用 CLI 工具而不是 MCP 服务器

gh、aws、gcloud、sentry-cli 这类 CLI 工具比对应的 MCP 服务器更省上下文，因为它们不增加任何 per-tool 列表开销。Claude 直接跑命令就行。

MCP 的 tool search 默认延迟加载工具定义，已经把这个开销压得很低了，但 CLI 仍然是零开销。

用 /mcp 看配了哪些服务器，把不用的关掉。

调整 extended thinking

thinking token 按输出 token 计费，默认预算可以达到每请求数万 token。

简单任务不需要深度推理时可以降：/effort 或 /model 里调 effort level、/config 里关掉 thinking、或者对固定 thinking 预算的模型设 MAX_THINKING_TOKENS=8000。

自适应推理的模型会忽略非零预算，那些模型上要用 effort level 而不是设预算。

写具体的 prompt

「改进这个代码库」触发大范围扫描。「给 auth.ts 里的 login 函数加输入校验」让 Claude 用最少的文件读取完成工作。

这条听起来像老生常谈，但它在成本上的影响是数量级的。

复杂任务上避免走错路

走错方向产生的 token 是纯浪费。四个习惯：

复杂任务先用 plan 模式。Shift+Tab 切过去，让 Claude 先探索并提出方案给你确认，避免方向错了之后昂贵的返工。
早点纠偏。方向不对立刻按 Escape 停下。用 /rewind 或双击 Escape 回到之前的检查点。
给验证目标。测试用例、截图、期望输出。Claude 能自己验证时，它在你需要提出修正之前就发现了问题。
增量测试。写一个文件、测一次、再继续。问题在便宜的时候被发现。

空闲时也有开销

Claude Code 在空闲时也会用一点 token：

对话摘要：为 claude --resume 功能总结之前对话的后台任务
命令处理：/usage 这类命令本身会产生请求

这些通常每会话低于 $0.04。

一个数量级参考

企业部署的平均成本大约是每开发者每活跃日 $13、每人每月 $150-250，90% 的用户保持在每活跃日 $30 以下。

这组数字的用途是判断自己是否异常。远超这个范围时，大概率是前面五个来源里的某一个，而不是「Claude Code 就是这么贵」。

要估自己团队的开销，从小规模试点开始，用上面的工具建立基线再推广。

变式练习

在一个开了几小时的会话里跑 /usage，看 API duration 和 wall duration 的比值。比值越极端，越说明你在为历史付费。
同一个任务做两次：一次在干净会话里，一次在挂了半天的会话里。对比 /usage 的数字。这个对比做过一次，/clear 的习惯就养成了。
跑 /context 看当前上下文构成。如果 MCP 工具或 CLAUDE.md 的占比让你意外，那就是你的优化起点。

还没确认的点

OpenTelemetry 导出的具体指标名与配置细节。官方 costs 页提到它是唯一能把 per-user token 和成本指标近实时导入自己观测栈的方案，但指标清单在 monitoring 页，本文没有核实。
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 的确切作用范围。这个变量在其他资料里被提及，官方 costs 页没有列出，未核实。
「agent team 约为标准会话 7 倍」这个数字的测量条件。文档说的是 teammate 在 plan 模式下运行时，其他模式下的倍数没有给出。
prompt caching 的缓存命中判定细节。缓存生命周期的分档确认了，但「什么样的上下文变化会导致缓存失效」没有查到明确说明。

参考

这一节有错或讲不清？提个 Issue 直接改文档请作者催更