为什么“节省 90% Token”不等于 Coding Agent 总成本降低 90%
最近把几个“Token 节省”插件放到完整仓库任务里做了一个小型配对实验，结论和常见宣传口径差异很大。
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
- **无插件**：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
- **Ponytail**：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
- **RTK**：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
[完整方法](https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea)
[GitHub 项目](https://github.com/Tura-AI/tura)
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228396)
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
- **无插件**：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
- **Ponytail**：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
- **RTK**：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
[完整方法](https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea)
[GitHub 项目](https://github.com/Tura-AI/tura)
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
---
原文链接：[点击查看](https://www.v2ex.com/t/1228396)
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞