解析 Claude Code 日志，定位令牌消耗

Claude Code 的额度为什么消耗得这么快？作者把排查入口放在本地 JSONL 会话日志上，并推荐用插件 CATO 查看 token 消耗、提示缓存失效原因和上下文构成，再尝试控制这些开销。

但标题比正文走得更远：提供的原文停在功能介绍和安装指引，没有展示日志分析结果，也没有节省比例或前后对照。它值得读的地方是给出了排查路径，至于优化效果，还需要实际验证。

先查额度花在哪里，再决定怎么省

只看对话里输入了多少字，很难解释 AI 编程工具的实际消耗。CATO 提供的排查维度包括 token 用量、提示缓存（prompt cache）和上下文区间分布。提示缓存可以理解为复用此前处理过的输入；排查缓存，就是看这些输入有没有被重复处理。

按原文说明，执行 /cato-import 后再运行 /cato，插件会读取已有的本地 .jsonl 会话记录，以只读方式展示过去 30 天的 token 开销，并按原因归类缓存未命中，包括空闲导致的 TTL 到期、切换模型和子代理（subagents）相关情况。

这里能拿走的是诊断思路，不能直接拿走结论。作者没有给出自己的消耗数字，也没有说明原因归类算法、统计覆盖范围，以及展示的开销如何对应订阅额度。因此，不能据此断言某一项就是你的额度消耗主因。

先把消耗拆开看，比直接寻找一个省 token 的开关更有用。

CATO 想控制的是上下文进入模型的方式

原文列出了几种优化手段：控制上下文和提示缓存、自动压缩上下文（compaction）、压缩嘈杂输出，以及提高代码导航效率。

这些手段针对的是不同问题。自动压缩试图控制持续增长的会话内容；压缩输出针对工具返回的冗长信息；代码导航则试图让查找代码更有针对性。不过，原文没有展开触发阈值、压缩规则，也没有展示压缩前后保留了哪些信息。

CATO 还声称可与 Serena、Graphify、ast-grep 和 GitHub MCP 集成，但没有提供具体调用示例。仅凭这段介绍，无法判断每个集成如何参与优化，也无法比较它们相对直接搜索、读取文件的收益。

作者强调，CATO 完全运行在 Claude Code 内部，不使用 Python，也不会为每次 hook 启动外部进程；插件自身标称 100% 本地离线、零网络调用、零遥测、零外部 npm 依赖。这个范围应限定在插件自身，不能据此认为 Claude Code 的模型请求或 GitHub MCP 交互也能离线完成。

30 秒审计入口，实际能看到什么

原文要求 Claude Code 2.1.290 或更新版本，升级命令是 claude update。安装入口如下：

/plugin install cato --marketplace marcusaguiarmaciel-cmd/cato-plugin

要注意的是 --marketplace 后面的来源，它指定了原文推荐的插件仓库。

安装后，这两条命令用于导入历史记录并查看审计结果：

/cato-import
/cato

第一行负责读取已有会话，第二行展示结果。原文将这一过程描述为即时、只读的历史审计；另外还提供 /cato-doctor，用于检查配置中可能导致 token 浪费的问题。

报告、警告和状态栏支持 English、Portuguese、Spanish。原文在介绍语言选择时中断，没有交代具体选择规则，也没有列出中文支持。所谓「30 秒」是快速上手的宣传描述，正文没有提供计时测试。

我的判断

我认可它先审计、再优化的顺序。相比凭感觉反复清理会话，读取历史记录至少提供了可追查的入口，也能帮助区分上下文增长与缓存复用问题。

但这段材料更接近插件介绍，尚不足以证明省 token 的效果。它没有公开样本量、任务类型、节省比例，也没有比较启用插件和手动控制输出、缩小读取范围等做法的差异。严格说，连可供核对的个人实测案例都没有。

另一个需要核对的点是压缩质量。自动压缩和减少输出可以降低输入量，但是否遗漏调试线索、是否增加后续补查，原文没说清。判断工具是否划算，应同时看 token 消耗和任务完成质量。

能拿来做什么

• 如果你已经使用 Claude Code，可以先用 /cato-import 和 /cato 查看历史分布，记录开销集中在哪些会话，再决定是否需要改变使用方式。
• 如果报告把缓存未命中归因于空闲 TTL、模型切换或子代理，就结合对应会话核对；不要仅凭分类名称认定是配置错误。
• 在前端或 Node 项目中试用输出压缩、代码导航时，选择范围相近的任务，对比 token 用量、补查次数和最终完成情况，再决定是否持续启用。