AI Coding Token 用量入门：先看懂消耗，再用 ccusage 复盘

一个只改了 20 行的 Bug，可能比生成 500 行代码更耗 Token

你让 AI Coding 工具修一个小 Bug。它先搜索仓库，读了十几个文件，运行测试，拿到一大段日志；接着提出一个猜想，发现不对，又换了方向；最后改动两个文件，重新跑完测试。Git Diff 里只有 20 行。

如果按代码行数看，这是一项小改动。如果按模型经历的过程看，它却是一次不短的调查。

理解 Token 用量，首先要抓住这一点：Token 记录的是有多少内容流经模型，而不是最后有多少代码留在 Git 里。

这个认识比学会任何统计工具都重要。Claude Code、Codex、Cursor 本身已经提供了相当直观的用量信息。ccusage 也没有掌握什么更“专业”的秘密数据，它只是读取受支持 Coding CLI 留在本机的记录，再换一种方式整理历史。

所以，这篇文章不会从安装 ccusage 开始。我们先回答四个更基础的问题：

• 为什么一句很短的需求，最后会产生大量 Token？
• Claude Code、Codex、Cursor 自带的统计分别能看出什么？
• ccusage 什么时候有价值，什么时候没有必要用？
• 发现一次用量高峰后，怎样把它变成下一次工作的具体改进？

一、一次任务，通常不止调用一次模型

你输入的那句话，只是模型输入的一小部分。每次调用模型前，AI Coding 工具还可能组装这些材料：

• 系统指令和工具定义；
• AGENTS.md、CLAUDE.md、Cursor Rules 等项目规则；
• 与当前任务有关的对话历史；
• 文件、搜索结果、诊断信息、截图和终端输出；
• 上一次工作留下的摘要或记忆。

模型生成回答、推理、工具调用或代码修改。工具执行后，结果返回给 Agent，Agent 再决定下一步，于是又发生一次模型调用。一次用户请求，很容易展开成下面的循环：

组装上下文 → 调用模型 → 执行工具 → 加入结果 → 再次调用模型

最容易被忽略的是：后面的调用往往还会再次处理前面的部分上下文。Prompt Cache 可以降低重复内容的价格，Compact 可以把较早的历史压缩成摘要，但一次很长的 Agent 工作过程，并不会因此变成“只调用了一次模型”。

常见的四类 Token

这四项是计量维度，不是四个固定的本地文件。不同供应商、不同产品展示它们的方式也不完全一样。同一段文字经过不同模型的分词器，Token 数还可能不同。因此，Token 不是一种跨模型绝对等价的“工作量单位”。

别把四种“快用完了”混在一起

大家常说“我的 Token 快没了”，实际可能在说四件不同的事：

当前上下文快满了，不代表订阅额度也快用完了。本地估算成本很高，不代表订阅用户一定会多付这笔钱。当前对话很短，也可能已经碰到套餐限制，因为其他会话或产品共享了额度。

所以看到任何数字，先问一句：它回答的是上面哪一个问题？

二、先看工具自己提供了什么

如果你想知道“现在这段任务发生了什么”，原生统计通常是最好的入口。产品自己最了解当前会话、正在使用的模型、上下文窗口，以及它特有的套餐规则。

Claude Code：看上下文，也看会话和套餐

Claude Code 有两个很实用的入口：

• /context 会把当前上下文的组成画出来，帮助你发现占比很大的工具、记忆或其他上下文来源。
• /usage 会显示当前会话的 Token 和估算成本；对于订阅用户，它还会显示套餐用量条、活动统计和本地用量拆解。/cost 是它的别名。

你还可以把上下文百分比、会话估算成本等信息放到自定义 Status Line 上。Claude Code 官方文档说得很清楚：美元数字由客户端根据 Token 和标准价格估算，可能与最终账单不同。新版本还区分“当前上下文中的 Token”和“会话累计 Token”，所以比较数字前一定要先看字段含义。具体可查阅 Claude Code 成本与用量说明、命令说明和 Status Line 字段。

如果你想知道当前会话是不是过于臃肿、某条 Rule 或某个 MCP Server 是否占了太多上下文，或者 Claude 套餐窗口还剩多少，优先看这里。

Codex：看当前上下文和速率限制

在 Codex 中，/status 会显示当前对话的 ID、上下文用量、活动模型和速率限制。Codex CLI 还可以用 /statusline 把上下文统计、Token 计数、速率限制、模型、Git 分支和 Session ID 等字段放到终端底部。

这些信息适合支持一个即时决定：继续当前任务、压缩上下文，还是另开一个干净会话。OpenAI 的官方 Codex 命令文档列出了 /status 和可配置的 Status Line。

不过，它仍然是面向当前工作的产品视图，不是个人月度账本。当前上下文占用了多少，并不能直接解释过去四周哪个项目消耗最多。

Cursor：用可视化找上下文问题，用 Dashboard 看账户用量

Cursor 提供了两个不同视角：

• 编辑器里的 Agent Context 可以展示当前上下文如何分配。从 Cursor 3.3 起，Context Usage Breakdown 可以继续拆解 Rules、Skills、MCP、Subagents 等类别，很适合排查一段对话为什么越来越“重”。可参考 Cursor 3.3 的 Context Usage Breakdown 更新。
• Cursor Dashboard 的 Usage 和 Billing 页面用于查看账户或团队的活动、模型使用、资源消耗与费用；具体可见范围取决于套餐和角色。可参考 Cursor Dashboard 文档。

它们比终端表格更直观，而且很多时候已经够用。如果你问的是“这段 Cursor Agent 上下文为什么这么满”或“这个账户用了多少 Cursor”，先打开 Cursor 自己的界面就对了。

三、这些数字并不都来自同一个地方

很容易产生一种错觉：所有用量面板都只是在读取同一个“本地数据库”。真实情况并不是这样。

实际可以把观测分成三层：

1. 产品的实时状态。 当前上下文、活动模型、这段对话和产品特有的额度。原生界面最擅长回答这一层。
2. 本机历史记录。 CLI 保存在这台电脑上的 Session、Transcript 或 JSONL 日志。第三方本地工具可以把它们重新按日期、模型、项目或会话整理。
3. 供应商账户与账单。 跨设备用量、合同折扣、订阅包含额度、发票和组织级核算。这里应该以供应商后台为准。

三层之间有重叠，但不能互相替代。

例如，Claude Code 的 /usage 可以利用本地会话历史做近期拆解，但套餐信息属于 Claude 账户；Codex 能显示实时上下文和速率限制，同时也会留下可供后续分析的本地 Session 日志；Cursor 的账户 Usage Dashboard 是产品侧统计，并不是 ccusage 在读取 Cursor 编辑器的本地数据库。

可以把选择原则压缩成一句话：

用原生工具指挥当前任务，用本地历史研究自己的工作方式，用供应商账单确认钱。

四、那么，ccusage 到底解决什么问题？

当问题带有明显的时间维度时，ccusage 才开始体现价值：

• 哪一天或哪个会话明显偏大？
• 换了项目或模型之后，用量趋势变了吗？
• 同一时间段里，我使用的几种受支持 Coding CLI 有什么差异？
• 能不能导出一份格式相对统一的本地数据，自己继续分析？

根据当前官方文档，ccusage 会读取受支持 Coding CLI 已经生成的本地用量文件，在本机完成解析，再提供按日、周、月和会话聚合的 Token 与估算成本。Claude Code 和 Codex 都在支持列表中；其中 Codex 日志支持被明确标为实验性，因为其日志格式仍会演进。Cursor 目前不在支持列表里。可查阅 ccusage 的工作原理与数据源列表以及 Codex 数据源说明。

所以，ccusage 的准确定位是：历史视角 + 本地格式适配器。它并不是夹在 Agent 和模型之间的计量网关。

它也不天然比原生统计“更准”，只是回答了不同的问题：

初学者先记两个命令就够了

不用背一整页命令。在已经产生受支持本地记录的电脑上，先看：

npx ccusage@latest daily
npx ccusage@latest session

第一条找出异常日期，第二条把高峰对应到具体会话。如果这两种视图都没有帮你做出任何判断，再多的参数也不会让分析突然变得有价值。

ccusage 只看当前电脑上保留下来的受支持文件。因此，没有数据可能意味着日志已被清理、存储位置改变、工作发生在另一台电脑、工具尚未支持，或者解析器还没跟上新格式。“报告里是 0”不一定等于“实际用量是 0”。

五、一次完整调查：那个“很贵的小 Bug”

回到开头只改了 20 行的 Bug。

第一步：看当前会话

原生 Context 视图显示，终端输出和仓库文件占了大部分上下文。这解释了当前对话为什么很拥挤，却还不能说明这项任务相对平时是否异常。

第二步：看本地历史

Session 视图显示，它是本周用量最高的几个会话之一。重新查看过程，真正的轨迹是：

模糊的 Bug 描述
  → 大范围搜索仓库
  → 返回完整测试日志
  → 第一个猜想错误
  → 再次搜索
  → 很晚才补充验收条件
  → 重跑测试

模型并不是突然神秘地“浪费了一大笔 Token”。用量是在重复上下文和额外轮次中逐步累积起来的。

第三步：决定下次怎么改

有价值的改进应该足够具体：

• 一开始就给出失败测试和验收条件；
• 大日志只返回与失败有关的部分；
• 切换到无关任务时新开会话；
• 在质量允许时，把机械性的后续工作交给更小或更低推理强度的模型；
• 只比较相似任务，不拿两个完全不同的任务硬比。

第四步：到正确的地方核对费用

如果账户按 API 计费，就去供应商 Usage 页面核对估算值；如果使用订阅，就看套餐用量，不要把按 API 标价算出来的本地数字当成发票。

到这里，用量数据才真正改变了工作方式。这才是分析的目的。

六、看到高峰，先别急着怪模型

不同的现象，应该引出不同的问题：

高用量不一定是坏事。一次线上事故值得投入更多模型工作。低用量也不一定是好事：一个很便宜、却交付了错误代码的回答，工程成本一点也不低。

更有意义的分母是结果：通过验证的修复、被接受的改动、已经解决的事故，或者可重复使用的资产。Token 只有和工作结果放在一起，才会变成管理信息。

七、隐私与准确性边界

本地 Session 记录可能包含 Prompt、源代码、文件路径、终端输出，以及命令意外打印出来的密钥。要把它们当作敏感工程数据处理。ccusage 说明其分析过程在本地进行且只读，但当你导出 JSON 或把数据上传到看板时，边界已经改变。只导出真正需要的字段，分享前重新检查内容。

同时记住这些限制：

• 本地历史只覆盖工具能看到的电脑和仍然保留的文件；
• 模型价格与产品规则会变化；
• Web Search 等工具调用可能产生 Token 之外的费用；
• 订阅消耗与按 API 标价计算的估算值回答的是不同问题；
• 即使用户需求相同，不同 Agent 也可能携带不同的系统提示、工具和上下文。

要做相对公平的比较，至少让任务类型、成功标准、时间范围和统计来源尽量一致。

八、每周十分钟就够了

你不需要先做一个永久看板。每周花十分钟：

1. 某个实时会话明显变长、变重时，先看工具自带的 Usage 或 Context。
2. 用本地历史找出一个异常日期或会话。
3. 回看任务，给原因起一个准确的名字：必要上下文、噪声日志、重复尝试、需求变化、输出过长，还是并行工作。
4. 只记下一个下次要尝试的改变。
5. 只有问题涉及套餐额度或实际付费时，才进入供应商后台。

一条有用的记录可以很短：

任务：支付回调 Bug
结果：已修复并通过回归测试
用量上涨原因：完整集成日志返回了两次；验收规则补充得太晚
下次：先过滤日志；修改前列出预期的回调状态

它比一张没有解释的彩色月报更有价值。

验证清单

读完后，你应该能够：

• 解释为什么一句 Prompt 会触发多次模型调用；
• 区分上下文占用、会话累计、套餐额度和账单用量；
• 使用 Claude Code、Codex 或 Cursor 的原生视图诊断当前任务；
• 说明 ccusage 读取的是受支持 CLI 的本地记录，而不是拦截模型流量；
• 知道当前 ccusage 支持 Claude Code 和 Codex，但不支持 Cursor；
• 把一个异常数字追溯到具体的任务行为；
• 在需要财务准确性时，回到供应商账单页面；
• 保护本地 Transcript 和导出的用量数据。

目标不是把每一个 Token 都压到最低，而是看清上下文、迭代和模型选择什么时候在产生有效工作，什么时候只是在重复自己。

权威资料

• Claude Code：成本与用量管理
• Claude Code 命令说明
• Claude Code Status Line 用量字段
• OpenAI Codex 官方命令文档
• Cursor Context Usage Breakdown
• Cursor Dashboard 与用量页面
• ccusage 工作原理、支持数据源与限制
• ccusage 的 Codex 数据源说明