Token Tracker - 追踪 Coding Agent 的 Token 使用情况 🤖 本文由作者提供想法和校验，DeepSeek V4 Pro协助编写、整理和发布。

最近几个月我先后用了好几个平台的 Coding Plan——GitHub Copilot、百炼、Kimi，还有公司提供的 API，以及一些第三方中转平台。用着用着，发现公司 API 的缓存命中率特别低。低到什么程度？我想知道具体数字，于是就 vibe coding 了一个 Token Tracker。

Token Tracker

Token Tracker 分成三个部分：Server 端、客户端插件和前端。

Server 端负责接收客户端发过来的 Token 使用信息，记录到数据库，同时维护缓存数据。客户端目前只写了一个 Opencode 的插件，作用是每次对话结束后把 Token 使用详情发到 Server 端。前端用来展示数据，主要包含：

• 总的 Token 消耗量
• 当日的 Token 消耗量
• 历史一段时间的变化趋势
• 所有记录的明细列表
• 缓存命中率

核心思路很简单：收集数据 → 分析数据 → 优化使用习惯。

缓存命中率

缓存命中率是我最关注的指标。通过这几天的记录，不同平台的缓存命中率差别非常明显。

大概说一下我观察到的数据：

公司 API 的命中率差了将近 20 个百分点，这是 API 层面直接带来的差异。我猜测可能是公司中转做了一些处理——比如对请求做了额外的包装、校验或者日志记录——导致缓存命中条件被破坏了，可能是供应商的问题。

如果这部分可以优化，应该能降低不少成本。毕竟缓存命中的成本一般是非命中的10%甚至更低。

这里没有 GitHub Copilot 的数据——因为我已经退订了。

缓存命中率这个指标为什么重要？它反映了你对 Coding Agent 的利用效率。命中率高，意味着你之前的上下文被有效复用了，Agent 不用重新处理同样的信息。命中率低，说明每次对话都像是"从头开始"，浪费了大量 Token 去重复建立上下文。

当然，很大一部分优化是工具自己做的——比如 Opencode 的上下文管理策略。但我们自己的使用习惯也会影响命中率。比如：

• 规划做得清晰，一次对话专注于一个任务，上下文连贯性好，命中率就高
• 频繁切换话题或重置对话，命中率自然低

这个指标在未来一长段时间里应该都会比较重要。随着各家模型按 Token 计费的趋势，缓存做得好不好，直接影响到成本和效率。

Token 输入输出比

另一个有意思的发现是关于输入输出比。我的实际数据大约是 100:1——输入 Token 远多于输出 Token。

为什么会这样？因为在 Coding 的过程中，制定规划可能需要多轮对话。一次对话的上下文可能累积到几十 K 甚至上百 K。一段时间内累计的上下文达到一兆级别，但实际输出的代码并没有那么多。

举个例子，跟 Agent 讨论一个架构方案，来回确认需求、调整设计、澄清细节，这个过程的输入是大段的上下文 + 你的反馈，但 Agent 的输出只有几段文字。等到真正写代码了，Agent 输出的也只是一个文件或一个函数。

这个数据有什么实际意义？如果用的是 DeepSeek 这类按用量付费的 API，可以根据自己的使用习惯做一个大概的成本估算，不至于对输入成本完全没有概念。

部署方案

部署用的是 Vercel + Neon 的免费方案。

Vercel 托管前端和 Server 端（Next.js），Neon 提供 PostgreSQL 数据库。个人使用基本够用，但也谈不上富裕。主要是 Neon 免费方案的数据库空间限制比较紧，如果数据量大起来可能需要清理旧数据，或者考虑升级。

如果你打算部署的话，建议还是个人使用就好，或者有专用服务器的话直接用服务器部署会更宽裕。

总结

Token Tracker 现在看来更多是一个个人工具——记录自己的 Token 消耗，观察缓存命中率的变化，用数据来指导自己的使用习惯。

但它反映了一个正在发生的趋势：AI Coding 工具越来越像一种"基础设施消费"，我们需要开始关注它的效率指标，就像我们关注 CPU 利用率和内存占用一样。缓存命中率、输入输出比，这些都是在为 Token 付费时需要关心的数字。

代码和部署记录都开源了：

• 用量展示：https://token.imcbc.cn/
• Server 端仓库：https://github.com/caibingcheng/token-tracker
• Opencode 插件：https://github.com/caibingcheng/token-tracker-opencode