最近几个月我先后用了好几个平台的 Coding Plan——GitHub Copilot、百炼、Kimi，还有公司提供的 API，以及一些第三方中转平台。用着用着，发现公司 API 的缓存命中率特别低。低到什么程度？我想知道具体数字，于是就 vibe coding 了一个 Token Tracker。
Token Tracker 分成三个部分：Server 端、客户端插件和前端。
Server 端负责接收客户端发过来的 Token 使用信息，记录到数据库，同时维护缓存数据。客户端目前只写了一个 Opencode 的插件，作用是每次对话结束后把 Token 使用详情发到 Server 端。前端用来展示数据，主要包含：
- 总的 Token 消耗量
- 当日的 Token 消耗量
- 历史一段时间的变化趋势
- 所有记录的明细列表
- 缓存命中率
核心思路很简单：收集数据 → 分析数据 → 优化使用习惯。
缓存命中率
缓存命中率是我最关注的指标。通过这几天的记录，不同平台的缓存命中率差别非常明显。
大概说一下我观察到的数据：
| 平台 | 缓存命中率 |
|---|---|
| 其他平台（DeepSeek、Kimi等） | 约 80-90% |
| 公司 API | 约 65% |
公司 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 付费时需要关心的数字。
代码和部署记录都开源了：