为什么“节省 90% Token”不等于 Coding Agent 总成本降低 90%

[yohjisakamoto]

最近把几个“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
https://github.com/Tura-AI/tura

披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。

[jimages]

应该成本的大头在 cache read 上面，input out 本身成本占比相对来说不高，高的是 cache read

[cybort]

你操纵不了缓存，这也是模型公司改收费机制的原因，如果用户找到窍门省钱，就该进一步涨价了

[weiliw528]

建议 testllm 测测看

[yohjisakamoto]

@jimages 对 是这个道理的

[yohjisakamoto]

@weiliw528 啥意思？

[yohjisakamoto]

@cybort 不至于，cached token 没人敢涨价，蒸馏技术现在实际模型的训练成本几乎没了，基本就是个运行成本。底层模型早晚是个薄利多销的云服务

[germain]

这两年因为几个大厂的 AI 不断涨价，人们把精力过于放在 token usage 优化上而忽略了任务成功率和输出质量上。少走一次弯路可以省 1 倍的 token 😂

[wqhui]

@germain 按不同难度任务的实现耗费 token 价格计算

[lel020]

什么模型？目前 cache 价格 10%到 1%都有，我感觉不同价格的 cache 应当有不同的最佳策略，
显然缓存越便宜，缓存命中率就越重要，
另外还有些 agent 压缩上下文是 0 缓存命中的，那么减少压缩也应当比较有利，

[yohjisakamoto]

@lel020 cache 没有 1%的 一般都是 10% 或者 20%，你可以看下 blog 中的有个 论文，我的 report 基本复刻了论文 codex 一般 70%左右的费用在 cached token CC 一般 80%多。 我报告里的架构大概早 30%左右

[yohjisakamoto]

@yohjisakamoto 刚查了一下还真有 1% 2%的 我测试的模型李最便宜的是 10%的抱歉我没说好。

[wuxkwnjjwoxk]

RTK 之前用，现在不用了，其实也省不了多少，会把权限配置搞得很麻烦而且某些压缩过的内容或者自动加上的 RTK 前缀会让 ai 反复怀疑自己，鬼打墙了一样重复尝试 RTK 命令，省的未必有多花的多

[yohjisakamoto]

@wuxkwnjjwoxk 是其实 ponytail 还好不至于有太大问题。RTK 用的过程中就明显感觉 agent 变蠢了。还真有人信这个东西能省 token 我也真是醉了。我发这个帖子被好几个人骂了。

[ttsh]

因为重构项目多数都是一直读，然后 messages 上下文一直都被重新发送和压缩吧，所以缓存占比很高