# Claude Code Token 使用审计：上下文、缓存、MCP 与会话成本

> 不要只盯着一个总数判断 Claude Code 为什么消耗快。先确认计费路线，再拆分上下文、缓存写入与读取、MCP 和会话累积，最后用干净会话做对照。

- URL: https://blog.laozhang.ai/zh/posts/claude-code-usage-limit-issues
- Published: 2026-08-04
- Updated: 2026-08-04
- Author: AI Free API Team (https://blog.laozhang.ai/zh/about)
- Category: Claude Code
- Tags: Claude Code, Token 使用量, 上下文窗口, Prompt Caching, MCP

---
Claude Code 用量掉得快，不等于“套餐偷偷缩水”，也不等于“一定是缓存 bug”。同一个终端里可能同时出现订阅套餐进度、本机会话估算、API Console 用量和云厂商账单。它们的口径不同，先把数字归到正确所有者，后面的优化才有意义。

保留问题会话，先记下 `claude --version`，再依次运行 `/usage`、`/context`、`/mcp`。记录模型、effort、认证与计费路线、session ID、上下文占比、input/output、cache creation/read、套餐使用条或 API 估算，以及完整报错。不要在支持材料里放 API key、私人对话、客户代码或完整文件内容。

本文依据 Claude Code 的[成本说明](https://code.claude.com/docs/zh-CN/costs)、[上下文窗口说明](https://code.claude.com/docs/zh-CN/context-window)、[提示缓存说明](https://code.claude.com/docs/zh-CN/prompt-caching)和 [MCP 文档](https://code.claude.com/docs/zh-CN/mcp)，于 2026 年 8 月 4 日核对。界面或字段不一致时，以你安装的版本为准。

## 先把四种数字分开

`/usage` 的 Session 区块能显示当前会话的 token 构成和本机计算的美元估算。这个估算按标准标价计算，适合比较会话，不等于最终账单。Pro 或 Max 的使用量包含在订阅中，本机出现美元数字也不能证明发生了额外扣费。

| 观察面 | 能证明什么 | 不能证明什么 |
| --- | --- | --- |
| `/usage` 套餐进度 | 本机看到的订阅窗口和近期归因 | 所有设备的完整活动或 API 发票 |
| `/usage` Session | 当前会话 token 组合与本机估算 | 实际结算金额 |
| `/context` | 当前窗口被指令、文件、对话和工具占了多少 | 谁为这些 token 付费 |
| statusline | 连续显示上下文和会话估算 | 权威账单 |
| Claude Console | API workspace 的用量与费用 | 订阅套餐剩余额度 |
| 云厂商账单 | Bedrock、Google Cloud 或 Foundry 路线的费用 | Claude 订阅消耗 |

如果路线不清楚，暂停计算成本。检查当前登录、环境变量、base URL 和供应商。需要完整分流时，阅读 [Claude Code API Key 与订阅计费指南](https://blog.laozhang.ai/zh/posts/claude-code-api-key-vs-subscription-billing)。

## 在现场建立一张审计台账

![Claude Code 计量项、证据强度与计费所有者审计台账](https://blog.laozhang.ai/posts/zh/claude-code-usage-limit-issues/img/audit-ledger.webp)

不用导出整个聊天，只需要保存能比较的字段：

- 时间与时区，用来对齐 Console 或云账单；
- Claude Code 版本、模型和 effort；
- 认证路线、工作目录与 session ID；
- `/context` 的总占比和主要分类；
- input、output、cache creation、cache read；
- `/usage` 中技能、subagent、插件和 MCP 的近期归因；
- 准确的限制提示、`429`、`529` 或上下文警告；
- 最近是否切模型、改 effort、连接 MCP、执行 `/compact`、升级或恢复旧会话。

当前 `/usage` 可以把近期套餐用量归因到技能、subagent、插件和单个 MCP server，并在长上下文或缓存未命中占比较明显时提示。但这些数据来自本机历史，适合诊断，不应被包装成所有设备的完整账单。

## 判断是上下文变重，还是缓存反复重建

上下文和缓存不是同一件事。Claude Code 每轮都要带上当前会话所需的指令、文件、对话和工具结果。即使缓存完全正常，一个跨越多个任务的长会话也会逐轮携带更多内容。

先看 `/context`。启动时可能已经加载 CLAUDE.md、memory、MCP tool 名称和 skill 描述；随后文件读取、工具返回和对话继续增长。若最大项来自旧任务，最有效的动作通常是另开一个明确范围的新会话，而不是继续压缩同一条历史。

再看缓存字段：

- `cache_read_input_tokens` 高，说明已有前缀在被复用；
- `cache_creation_input_tokens` 高，说明前缀正在写入或重建；
- 普通 input 是未走低价读取路径的输入；
- output 是模型生成的内容，缓存不会让它免费。

切换模型或 effort、改变加载到前缀里的工具、执行 `/compact`、升级、换路线或超过缓存 TTL 后，出现一次重建可能正常。真正值得调查的是：同样路线、模型、工具和短时间间隔下，相似请求连续高 creation、低 read。缓存 TTL 与失效细节见 [Claude Code 缓存未命中成本指南](https://blog.laozhang.ai/zh/posts/claude-code-cache-miss-token-costs)。

## MCP 要分别查工具定义和返回数据

不要用“装了几个 MCP”直接估成本。支持 Tool Search 的当前 Claude Code 会按需发现工具，而不是把全部 schema 预先塞入上下文；但自定义网关、部分云路线、模型、设置或 `alwaysLoad` 可能改变这一行为。

审计时分两层：

1. 用 `/mcp` 和 `/context` 看哪些 server 真正启用、工具是延迟加载还是预加载。
2. 看工具调用返回了多少内容。很小的工具定义也可能带回整张表、整段日志或大量搜索结果，并留在会话历史里。

Claude Code 会在单次 MCP 输出超过 10,000 token 时警告，默认最大输出为 25,000 token。把上限调大只会允许更多内容进入上下文，不会让它更便宜。优先使用筛选、分页、摘要或文件句柄。需要系统清理时，转到 [Claude Code MCP 上下文过载指南](https://blog.laozhang.ai/zh/posts/claude-code-mcp-context-overload)。

## 用一个干净会话做对照

![Claude Code 问题会话与干净对照会话的用量比较](https://blog.laozhang.ai/posts/zh/claude-code-usage-limit-issues/img/control-session.webp)

选择一个小而可完成、又能代表原任务的动作。不要用新的模型或新的路线，否则对照失效。

1. 保持版本、项目、认证路线、模型和 effort 相同。
2. 新开会话，只保留任务真正需要的 MCP。
3. 开始前保存 `/usage` 和 `/context`。
4. 完成一个边界清楚的动作。
5. 再保存同样字段，比较上下文增长、cache creation/read、output、MCP 归因和 API 时间。

如果干净会话明显更轻，旧会话的问题多半是历史累积、过大的工具结果、无关任务或多个 agent 上下文。此时应在任务边界使用 `/clear`，在自然节点用 `/compact`，缩小工具查询，并为常规工作选择合适的模型和 effort。

如果干净会话仍然复现异常，就停止无意义重复，把台账整理成可核对的支持材料：同一版本、路线、模型、effort 和小任务；新会话；无 MCP 变化；带时间戳和 token 分类；复现一次即可。

## 按证据选择最小修复

| 证据模式 | 第一动作 | 不要先做 |
| --- | --- | --- |
| 无关任务让上下文持续增长 | 新开聚焦会话，在任务边界 clear | 直接升级套餐 |
| cache creation 连续偏高 | 固定模型、effort、工具和路线，再验证下一轮 | 每轮都 compact |
| 某个 MCP 占比突出 | 缩小查询和返回，当前任务暂时停用 | 永久关闭所有 MCP |
| output 占主要部分 | 明确输出格式，合适时用更便宜模型 | 把责任归给缓存 |
| 并行 agent 占主要部分 | 减少并发并缩小 spawn prompt | 把子上下文当作免费 |
| 准确错误是 `529` | 看服务状态并有限重试 | 当作个人额度耗尽 |
| API/供应商返回 `429` | 按重试时间和限额处理 | 当作 Pro/Max 套餐用完 |
| 干净对照仍异常 | 带台账升级支持 | 购买更多额度掩盖问题 |

一次审计不需要建立完美的通用 token 模型。只要每个大幅变化都能归到上下文携带、缓存写入或读取、MCP 定义或结果、模型输出、并行 agent、订阅窗口或计费路线，就足以做出下一步决定。