你的编码 Agent 为回答一个问题刚刚打出了四十次模型调用，而这笔账单正藏在你没看的地方。Claude Code 把它埋进会少算的 JSONL 记录里；Codex 写的是累计计数器；Cursor 把它塞进一个 SQLite 二进制块；Aider 则打印一次就忘掉。值得安装的开源跟踪器，是与你的 Agent 已经留下的那条轨迹相匹配的那一款——所以在 ccusage、codex-usage-tracker、CodeBurn 与 LiteLLM proxy 之间做选择，本质上是在选「遥测的形状」，而非比对功能清单。选对了，你还会顺手解锁那几个真正能压低账单的开关：命中 prompt 缓存、模型路由，以及毫不手软地重置上下文。
速览
四款开源工具，对同一个问题给出四种答案——你的 Agent 把 token 花到哪去了。下表先列基本信息；之后的柱状图与矩阵则呈现这些工具被采用的程度有多悬殊，以及每一款究竟是为哪个 Agent 而造。
| 跟踪器 | 许可证 | 主打 Agent | 读取的轨迹 |
|---|---|---|---|
| ccusage | MIT | Claude Code（与 Codex） | 磁盘上的 JSONL 记录 |
| codex-usage-tracker | MIT | Codex CLI | Codex JSONL → SQLite 索引 + MCP |
| CodeBurn | MIT | Cursor（及另外 24 款） | 各 Agent 的本地存储（如 state.vscdb） |
| LiteLLM proxy | MIT* | Aider（及任意客户端） | 实时 API 请求（改写 base-URL） |
快照：2026-06-09。star 数与工具清单变动很快，请对照各仓库核实。*LiteLLM 除其 enterprise/ 目录（单独的商业许可）外均为 MIT。
核心论点：四个 Agent，四条轨迹
每个编码 Agent 都会记录自己花了多少，但没有哪两款记的方式相同——而正是这一点，决定了哪款工具能读懂它。Claude Code 把 JSONL 记录流式写到 ~/.claude/projects/；解析器毫秒级就能读完，但这个文件是有损的（下文细说）。Codex 把 token_count 事件写到 ~/.codex/sessions/，每个事件都带一个累计总量加一个当轮增量，所以跟踪器只要跟着计数器走即可。Cursor 把一切都藏进一个本地 SQLite 数据库（state.vscdb、cursorDiskKV 表、bubbleId: 键）——未公开、靠逆向得来，且会随版本漂移。而 Aider 干脆不留任何结构化账本：它把成本打印到终端，并写一份纯文本 Markdown 历史，作为用量数据流来说无法解析。
所以本文这四款工具并不是「最好的四款 token 跟踪器」。选它们，是因为每一款都演示了一种不同的遥测形状：一个 JSONL 解析器（ccusage）、一个带「可被 Agent 查询」接口的逐 Agent SQLite 索引器（codex-usage-tracker）、一组逐 Agent 的磁盘读取器（CodeBurn），以及一个彻底放弃读盘、转而计量实时流量的代理（LiteLLM）。把形状对上你的 Agent，剩下的都是细节。
ccusage——JSONL 解析器的事实标准
它读什么，怎么跑
ccusage（ryoppippi/ccusage，约 1.58 万 star,MIT）是本地优先的 Agent 成本报表事实标准，而它是一个纯粹的磁盘解析器：只读你 Agent 已经写下的 JSONL 日志，从不碰网络。标准安装就是一条命令——npx ccusage@latest，或推荐的 bunx ccusage——另有 pnpm dlx 和 Nix flake 可选。它的主场是 Claude Code 的 ~/.claude/projects/ 记录，但一个专门的 ccusage codex 命令也能读 Codex，且项目宣称覆盖约十五款 Agent CLI，所以对多数人来说，它是唯一需要安装的跟踪器。
它给你的报表
真正让它胜出的是输出：daily、weekly、monthly、session 与 blocks（Claude Code 的 5 小时计费窗口）视图，每种都把 input、output、cache-creation、cache-read 四类 token 分开计，并有 --breakdown 标志给出逐模型成本。一个 beta 版的 statusline 模式则把实时总量摆在你眼前。对于日常问题——「这周花了多少，花在哪个模型上」——它一条命令就能回答，无需配置文件。
陷阱：它继承了一个有问题的数据源
ccusage 的准确度，完全等同于它所读取的那个文件——而对 Claude Code 来说，那个文件在撒谎。Issue #866 把问题说得很清楚：Claude Code 把 input_tokens 记成了某个非最终的流式事件的值，于是大约四分之三的条目显示为 0 或 1——输入少算 100–174 倍；同时它从 output_tokens 中漏掉了 thinking token，在 Opus 上输出少算 10–17 倍。某个高强度的一天，报告者看到 ccusage 显示约 $50，而真实 API 成本接近 $446。缓存数字是准的，其余则不然。关键在于这是 Claude Code 上游的数据质量 bug，而非 ccusage 的缺陷——独立的 cccost 项目得出了同样的结论，并通过拦截 fetch() 来取得真值。把 ccusage 的 Claude Code 数字当作下限就好；想知道为什么 thinking token 最容易缺失，可读 推理模型。
codex-usage-tracker——逐 Agent 的持久化层
相较纯解析器它多了什么
codex-usage-tracker（douglasmonsky/codex-usage-tracker,MIT，体量虽小但仍在积极维护）专为一个 Agent 而造，做了两件 ccusage 不做的事。其一，它把 Codex 会话 JSONL（位于 ~/.codex/sessions/）里的 token_count 事件解析进一个持久的 SQLite 索引，落在 ~/.codex-usage-tracker/usage.sqlite3——这是一个你可以查询的真正数据库，而不是一次性报表。（Codex 让这件事很省心：每个事件都同时带一个累计总量和一个预先算好的当轮增量，所以跟踪器是跟着计数器走，而不是靠猜。）它还呈现出一个裸解析器会跳过的指标，包括上下文用量与缓存命中比。安装就一行：pipx install codex-usage-tracking。
MCP 的妙处——Agent 读自己的账单
第二个差别才是有意思的：codex-usage-tracker 自带一个 MCP 服务，暴露 usage_summary、usage_query、session_usage、usage_recommendations 等工具。这意味着花销数据可以从 Agent 内部触及——Codex 能在会话中途调用一个工具，问「我今天花了多少，花在哪」。ccusage 已经能为 Codex 做普通报表；当你想要一个持久的逐 Agent 数据库、并希望这些数字能被 Agent 自身（而不只是你的 shell）查询时，才选 codex-usage-tracker。
CodeBurn——跨 Agent 的磁盘读取器
每个 Agent 一个读取器，一共二十五个
CodeBurn（getagentseal/codeburn，约 7.8k star,MIT）是覆盖面最广的本地磁盘跟踪器，横跨 25 款编码工具，无需代理、无需 API key——它直接从磁盘读取每个 Agent 的会话数据，并用 LiteLLM 的费率表为每次调用定价。它的 README 本身就是一场「Agent 们存储方式有多不同」的导览：Cursor 存在 state.vscdb,Gemini CLI 存在会话 JSON,Warp 存在 warp.sqlite,Forge 存在 ~/.forge/.forge.db,Copilot 存在 VS Code 的 workspaceStorage 记录里——此外还有 Claude Code、Codex、Cline、Goose 等等。安装是 npm install -g codeburn，你就得到一个横跨当前所有在跑工具的终端仪表盘。
它适合哪里——又不适合哪里
对 Cursor 而言，CodeBurn 是最干净的答案，尤其是在那个广受欢迎的 cursor-stats 扩展（Dwtexe/cursor-stats,GPL-3.0）于 2026 年 3 月被归档、不再更新之后。相较 ccusage，这是一笔「广度换深度」的交易：CodeBurn 覆盖的 Agent 多得多，而 ccusage 更老练、在 Claude Code 与 Codex 上久经考验，逐模型报表也更细。CodeBurn 唯一帮不上忙的地方是 Aider——Aider 不留任何可供读取器解析的结构化存储，而这恰好是下一款工具填补的空白。还有，正因为它读的是每个 Agent 的本地存储，CodeBurn 也继承了每个 Agent 的准确度，就像 ccusage 继承了 Claude Code 的准确度一样。
LiteLLM proxy——计量流量，而非磁盘
它如何工作
LiteLLM 代理（BerriAI/litellm，约 4.98 万 star，核心为 MIT）彻底放弃了读盘。你把它当作一个自托管网关来跑，再用 base-URL 改写把客户端指过来——Claude 类客户端用 ANTHROPIC_BASE_URL,OpenAI 类用 OPENAI_BASE_URL（更老的客户端用 OPENAI_API_BASE）。此后每一个请求都流经代理，后者把逐请求的 token 用量与算出的成本记入它的 LiteLLM_SpendLogs 表，执行逐 key、逐团队的预算，并能导出到 Langfuse 或任意 OpenTelemetry/OpenLLMetry 后端做仪表盘。
为什么它是 Aider 的正解
因为它就坐在请求路径上，代理读的是提供方实际返回的 usage 对象，而不是从一份记录里反推数字——所以它是这里唯一能看到真值（含缓存与推理 token）的方案。这让它天然契合 Aider:Aider 不留任何可解析的轨迹，但它本来就引入了 LiteLLM 来做模型调用与成本打印；把它指向一个代理，就在不改一行代码的前提下，补上了它原本缺的持久仪表盘与逐团队记账。诚实地说，代价在运维：你现在要在热路径上跑一个服务——多一跳、多一点延迟，还多一个要维持运行的进程。如果你只想为一个 Agent 快速读一下，这套机器就太重了；但如果你要的是横跨每个 Agent、每个团队的同一本真值账本，它是唯一能交付的选择。
横向对比
准确度——谁真正看见了真实数字
这是四者分歧最大的地方。磁盘读取器——ccusage 与 CodeBurn——准确度仅取决于 Agent 写下了什么，这正是 ccusage 的 Claude Code 总量可能差出一个数量级（issue #866）、而缓存数字却仍然正确的原因。codex-usage-tracker 处境略好，因为 Codex 写的是诚实的累计计数器，所以它的计数很扎实——尽管最终的金额取决于你给它的价格表。LiteLLM 代理是唯一看到提供方真实 usage 对象（含缓存与推理 token）的那个，因为它读的是线缆上的响应，而非事后写下的日志。如果要求是「数字必须分毫不差」，这种不对称就足以拍板。
覆盖面——每款跟踪器能读哪些 Agent
覆盖面与专注度彼此拉扯。codex-usage-tracker 按设计就是最窄的——只管 Codex——以广度换来了持久索引和 MCP 接口。ccusage 对它最看重的两个 Agent 很宽（Claude Code 与 Codex 都是一等公民，共约 15 款 CLI），却忽略了 Cursor 和 Aider。CodeBurn 是广度冠军，覆盖 25 款 Agent，如果你在 Cursor、Gemini CLI、Warp、Copilot 等之间来回切换，它就是显而易见的选择——只是它同样没有读 Aider 的读取器。LiteLLM 代理覆盖任何你能改写指向它的客户端，所以它能逮住磁盘读取器漏掉的那些 Agent；例外是 Cursor，只有在自带 key（BYOK）模式下才够得到外部代理。
搭建成本——从一条命令到跑一个服务
摩擦几乎与准确度完全同步——真值是用搭建成本换来的。ccusage 与 CodeBurn 最省事：分别是 npx/bunx 和 npm i -g，只读、按需运行，跑完什么都不留。codex-usage-tracker 也就略多一点——一个 pipx install，在后台建一个本地 SQLite 索引。LiteLLM 代理则是另一个量级：一个你要搭起来、做好安全、保持在线、并让每个客户端都用环境变量指过去的服务。前三款磁盘工具你六十秒内就能试上；代理则是一个小小的基础设施决策。
该选哪一个
| 你的情况 | 选 ccusage | 选 codex-usage-tracker | 选 CodeBurn | 选 LiteLLM proxy |
|---|---|---|---|---|
| 我主要用 Claude Code | 可以——一条命令读你的记录（只是要知道总量偏低）。 | 不行——它只管 Codex。 | 能用（Claude Code 是它 25 款之一），但 ccusage 在这里更深。 | 仅当你需要精确的真值、且愿意跑一个服务时。 |
| 我用 Codex，想把花销放进 Agent 里 | ccusage codex 能出快速报表。 |
可以——SQLite 索引外加 Agent 自己能调用的 MCP 工具。 | 覆盖 Codex，但没有 MCP 接口也没有持久索引。 | 除非你还想要跨团队的预算，否则杀鸡用牛刀。 |
| 我在 Cursor、Gemini、Copilot、Warp 之间来回切 | 大多读不到。 | 不行。 | 可以——这正是它的全部卖点：25 款 Agent，一个仪表盘。 | 只有你能改写指向的那些；Cursor 需要 BYOK。 |
| 我用 Aider | 不行——Aider 不留 JSONL 可读。 | 不行。 | 没有读 Aider 的读取器。 | 可以——Aider 本就用 LiteLLM，代理补上它缺的仪表盘。 |
| 我要一本跨 Agent、跨团队的真值账本 | 仅限本地、逐 Agent。 | 仅限本地、单个 Agent。 | 仅限本地，无团队汇总。 | 可以——花销日志、逐 key/逐团队预算、精确计数。 |
如何真正省下 token
跟踪器告诉你账单是多少；下面这些才是把它压下去的开关。最要紧的三个是通用的——保持 prompt 前缀稳定，好让缓存读取一直便宜；把廉价的活路由到廉价的模型；并毫不手软地重置上下文——只是每个 Agent 暴露它们的方式不同。读 成本、质量、延迟 看看为什么这三者就是全部的取舍，读 Claude Code、Codex、Cursor 与 Aider 对比看看每个 Agent 的脾性。
Claude Code
在不相关的任务之间用 /clear，会话膨胀时用 /compact——上下文里的每个 token 都会在下一轮被重新发送，所以臃肿的上下文是一笔反复发生的费用，而非一次性开销。让你的系统提示和 CLAUDE.md 保持稳定：缓存读取的计费只是新鲜输入的一个零头（大约便宜 10 倍），而改动前缀会把缓存作废。把廉价的子任务推给更便宜的模型，而不是什么都跑在 Opus 上。
Codex CLI
在 ~/.codex/config.toml 里为日常工作挑一个更便宜的推理模型或更低的推理强度。盯住 codex-usage-tracker 呈现的缓存命中比：比值偏低意味着你在不断打散 prompt 前缀，每一轮都在付全价。用 /clear 来防止上下文——以及随之累计的 token_count——一路往上爬。
Cursor
Cursor 在 2025 年年中已不再按请求计费；现在它是按一个与真实 API token 成本挂钩的「美元额度池」扣费。所以开关有两个：哪个模型处理请求（把下拉框降到能过关的最便宜那个），以及每个请求带多少上下文——小改动就关掉 MAX/长上下文模式，因为更大的窗口意味着更多输入 token 从你的额度池里扣走。
Aider
对 Anthropic 模型打开 --cache-prompts，让系统提示、仓库映射和只读文件被缓存。跑一个「架构师/编辑」分工——用一个强力的 --architect 模型来规划，用一个便宜的 --editor-model 来落实 diff——这样昂贵的模型只负责思考。大批量发送前用 /tokens 查看当前上下文，换任务时用 /clear 把它清掉。
常见问题
ccusage 为什么会少算 Claude Code 的花销？
因为 Claude Code 的 JSONL 记录是个有损数据源，而 ccusage 忠实地报告了里面的内容。据 ccusage issue #866，该记录把输入 token 记成某个非最终的流式事件的值（于是大多数条目读出来是 0 或 1），并从输出计数里漏掉 thinking token——输入少算 100–174 倍，Opus 上输出少算 10–17 倍，而缓存数字仍然准确。这是 Claude Code 上游的 bug，不是 ccusage 的毛病。想要真值，你需要能看到真实 API 响应的东西：像 cccost 那样的 fetch 拦截器，或一个 LiteLLM 代理。
CodeBurn 是不是换皮的 ccusage?
不是。两者都读磁盘上的数据，但瞄准的问题不同。ccusage 是一个专注的 JSONL 解析器，更老练、在 Claude Code 与 Codex 上久经考验，在约十五款 CLI 上有细致的逐模型、逐窗口报表。CodeBurn 是广度路线：为 25 款 Agent 各自的本地存储分别写一个读取器——Cursor 的 SQLite、Gemini 的 JSON、Warp 的数据库等等——经 LiteLLM 定价，汇总到一个仪表盘里。要在 Claude Code/Codex 上求深度，用 ccusage；在许多 Agent（尤其是 Cursor）之间切换时，用 CodeBurn。
到底有没有适合 Aider 的跟踪器？
作为磁盘读取器是没有的——Aider 不留结构化的用量账本。它把逐轮和整段会话的 token/成本打印到终端，有一个看当前上下文的 /tokens 命令，也写一份人类可读的 .aider.chat.history.md，但这些都不是可解析的数据流。若想给 Aider 一个持久仪表盘，就把它路由经过一个 LiteLLM 代理——它内部本就在用 LiteLLM——再从代理的日志里读花销。
如果我的 Agent 已经显示 token 计数，还需要跟踪器吗？
会话里的计数器回答的是「这一轮」；跟踪器回答的是「这一周，按模型，横跨每一段会话」。它把历史聚合起来，按模型、按窗口拆分成本，并且——通过代理——给你能用于结算的可信数字。而对 Claude Code 来说尤其如此：它应用内和 JSONL 里的数字可能是错的（issue #866），所以一个真值数据源是唯一能让你知道真实数字的途径。
LiteLLM 代理这套路子，值得为它多养一个组件吗？
取决于你在优化什么。如果你想要精确的真值花销、想要横跨多个 Agent 和一个团队的同一个仪表盘——而且你能跑起来并守住一个服务——那么值得，代理是这里唯一能交付它的方案。如果你只是想本地快速看一眼某个 Agent 近期的成本，那么一个磁盘读取器（ccusage、codex-usage-tracker 或 CodeBurn）摩擦小得多，也够用了。别为了回答一条命令就能回答的问题去跑一个代理。
延伸阅读
在本站：
- Claude Code、Codex CLI、Cursor Agent 与 Aider——这些跟踪器盯着的那些 Agent，以及每一个在 token 上的脾性。
- LangSmith、Braintrust、Helicone 与 Arize Phoenix——应用层的对应物：生产 LLM 可观测性与成本上，同样的「代理 vs SDK」之分。
- AFK 编码——当你并行跑多个 Agent 时，账单会叠加，而跟踪器正是你保持诚实的手段。
- 成本、质量、延迟——每个省 token 的开关其实都在和这个三方取舍谈判。
- Token 与分词——这些工具一开始数的到底是什么。
- 如何选模型——模型路由这个开关，最大的省钱空间通常藏在这里。
项目来源：
- ccusage——解析 JSONL 的 CLI（关于 Claude Code 少算，见 issue #866）。
- codex-usage-tracker——Codex JSONL → SQLite 索引 + MCP 服务。
- CodeBurn——横跨 25 款编码工具的逐 Agent 磁盘读取器。
- LiteLLM——以花销日志和预算计量实时流量的代理/网关。