Spotify 节省 90% token 的办法，在我的日志里只是 0.6% 的舍入误差
对文件读取和答案完整性的测量说明，是否采用节省 token 的钩子，应由自身工作负载决定，而不是照搬基准测试的标题数字。
🚨 **两篇刷屏文章说，Spotify 通过拦截大文件读取，让 Claude Code 的 token 用量减少了 90%；但套到我自己的日志上，这个钩子只能省下 0.6%。**问题出在做事方式上：只凭一张截图就装上节省 token 的钩子，却不测量它究竟影响了什么。这会耗掉小团队花钱也买不回来的资源——工程师的注意力，而且可能让智能体表现更差。先测量，再采用；这篇文章会说明该测什么。守住这条纪律，才能避免把别人的基准测试、工作负载和取舍，原封不动搬进自己的团队。
这些数字背后的全部代码和数据都已公开：GitHub 上的 shared-code。
🚨 86% 的步骤，2% 的新输入
智能体的大部分步骤都在读取，但在我的实际开销中，这些读取几乎只是舍入误差。
Subquadratic 的 Alexander Whedon 在播客中提出，前沿智能体 86% 的步骤都是读取。没问题，但那说的是步骤。我统计的是自己日志中的 token：Claude Code 的读取占新输入的 2.1%，Codex 则为 6.1%。后台审查中，这个比例达到三分之一，但因为 Codex 会分段读取，350 行的拦截阈值也只能触及后台审查中新输入 token 的约 3%；何况 codex exec 根本没有可安装这种钩子的接口。在审查里，用摘要替代全文最危险，因为审查者的职责恰恰是发现没人专门问起的东西。
已经读过的内容还会在每一轮重新进入上下文，占满窗口，让压缩更早发生。重发 token 便宜，不等于上下文窗口免费。
下面这句话可能会让人不高兴：如果你这周因为一张截图就装了拦截读取的钩子，你优化的只是一个舍入误差，却让每个大文件多等 10 到 30 秒。动手之前，先按交互式、后台等使用场景分别统计自己的读取占比。基准测试能告诉你往哪里看，却不能告诉你该给哪类场景加一条新规则。
🔍 Codex 读得更快，6 次只有 2 次全对；Claude Code 则是 6 次中 6 次全对
面对完全相同的问题，快速、便宜的读取漏了行，也漏了答案；慢而完整的读取每个问题最高花了 $1.12，但答对了全部内容。
三个需要大量读取的问题，各跑两次，对比 Claude Code 2.1.266 和 Codex CLI 0.153.4。Codex 使用 gpt-5.3-codex-spark；Claude 的五次运行使用 claude-fable-5-1，一次使用 claude-opus-5。这里讨论的是运行框架如何读取，不是哪个模型更聪明。Claude Code 也会限制输出：在我的日志里，大约每 150 次 Read 结果中有 1 次遇到限制，每 200 次 shell 输出中也有 1 次。
Codex 的输出上限把一个 797 行的文件截成了 491 行，最终只回答出 12 个方法中的 6 个。两次都是这样。Claude Code 一次性读取的 1,118 行完整返回了；按 API 等价价格计算，那次运行花费 $1.12。漏行的快速读取，只是一个延迟数字好看的缺陷。在你自己的代码仓库上测时间，也核对答案。只有答案完整回应了用户的要求，执行得更快才有意义。
⚙️ Mazmanov 做的东西，比刷屏文章说的更好
90% 是真的，但范围很窄：它指的是三项读取测试中，主模型少看到的文件文本量，没有成本、任务或正确率数据，而唯一的质量结果是漏掉了一个缺陷。
Dimitri Mazmanov 的文章介绍了一个钩子：拦截超过 350 行的整文件读取，把文件发给 Gemini 2.5 Flash，整理成要点。README 中的基准测试报告，三个读取场景的 token 减少了 82% 到 94%。负责生成摘要的模型漏掉了一个隐蔽的线程安全缺陷；那条获得 277 分的 Hacker News 讨论说：“没有提到正确率或任务成功率。”
它做对了几件事：强制执行比文字指令有效，因为 CLAUDE.md 里的规则会随着会话变长而逐渐失效，而钩子可以直接拒绝；即使重发 token 很便宜，缩小上下文占用仍然有帮助，因为可以更晚再压缩；直接把代码写入磁盘，则能减少最贵的那类 token——输出 token。
规则确实变了。前缀缓存让首次读取比后续复用更贵，而成本低十倍的读取模型让委派成为可能。这使读取成本变成了一个需要按使用场景分别衡量的问题，刷屏文章却又把它说成了一个放之四海而皆准的常数。照搬配置之前，先问清标题里的数字到底测了什么。标题描述的结果可以是真的，却仍然不适合作为你这台机器的决策依据。
🛠️ 日志支持时，再安装钩子
只有在无人值守的使用场景中，而且大文件读取占付费开销超过十分之一时，才采用这种钩子；其他地方就别装。
读取后应该很少需要编辑文件，执行摘要的模型必须便宜得多或运行在本地，而且你要抽样把答案与完整文件核对。交互式会话、信息密集的文件、审查和调试都应跳过，因为这些工作的要点，就是发现那行没人特意要求查看的内容。先从日志里取出数字，逐项核对这些条件。如果取不出来，你就在凭猜测判断这个钩子会在哪里伤害工作质量。
🧭 你的阈值在日志里，不在截图里
两种运行框架的典型读取量相差八倍，一个常数不可能同时适用，更不用说它并没有针对你的情况调过。
这周可以用 GitHub 上的 shared-code，把文件内容字节数与运行框架计数器对照，分开统计交互式与后台工作，再看超过阈值的整文件读取占新输入的多少。我之前已经写过，输入 token 的成本大头在别处：Opus 4.7 的输入 token 比 GPT-5.5 多 58%，以及关于 claude-mem 消耗 token 的帖子。陷阱就在这里：一张漂亮的图表，把一个实现选择变成了表态站队，而在写钩子之前，没有人先问省下的量到底够不够大、有没有实际意义。