79000星项目的成本迷思
RTK（Rust Token Killer）是GitHub上拥有超过79000星的热门工具，它通过压缩AI编程智能体的终端输出来减少token消耗。一条声称RTK可将Claude Code的token消耗削减60%的推文获得了313000次浏览。但波兰数据库公司Quesma的联合创始人Bartosz Kotrys和Jacek Migdal决定用严谨的基准测试来验证这些说法。他们花费超过1500美元的API费用，在Terminal-Bench 2.1上运行了1740次对照实验，覆盖Claude Code搭配Fable 5.0和OpenCode搭配DeepSeek V4 Pro两种主流配置，用五次重复的实验设计来消除随机波动。
实验设计与基准选择
研究团队选择Terminal-Bench 2.1而非更新的3.0或4.0版本，原因很实际：成本只对成功完成的任务有意义，而2.1版本上智能体能通过大部分任务，更新版本仍有大量任务无法完成。他们测试了85个Fable任务和89个DeepSeek任务，每个任务分别在有RTK和无RTK两种条件下各运行五次，使用相同的模型路由、平台和任务超时设置。RTK的工作原理是重写终端命令的输出：例如ls -la会保留文件名、大小和权限信息，但移除所有者和日期字段。它只处理Bash工具调用，对Read、Grep、Glob等独立工具的输出不产生作用。
核心发现：成本差异微乎其微
结果令人失望。在Fable 5.0上，RTK版本的总成本从731美元下降到698美元，降幅约5%，但通过率从84%下降到83%。在DeepSeek V4 Pro 0813上，RTK版本的总成本从51美元上升到54美元，反而增加了5%，通过率从71%下降到69%。当研究团队将所有花费（包括失败尝试）除以通过任务数来计算真实成本时，Fable便宜了3%，而DeepSeek贵了7%。若采用任务级等权分析，Fable平均贵了1%，DeepSeek平均贵了17%。两个模型的结果方向相反，但差距都很小，与社交媒体上声称的60%至90%节省相去甚远。
RTK节省计数器为何失真
RTK内置一个名为rtk gain的指标，计算原始命令输出与过滤后输出之间的字节差除以4。在DeepSeek的445次RTK尝试中，该指标报告节省了349.2百万token，相当于89%的输出压缩率。然而这个指标存在根本缺陷。在一个train-fasttext任务中，模型两次运行head -1 train.txt，RTK将这两次调用与读取整个文件进行比较，各报告节省120.5百万token，仅这两次调用就占据了全部节省计数的69%，尽管模型本来就只请求读取第一行。rtk gain衡量的是被移除的输出量，而非实际节省的费用——它假设剩余的智能体行为会与基线完全相同，但压缩输出实际上可能改变模型的后续决策。
一次真实的无限循环事故
实验中还记录了一个有趣的故障案例。在一次DeepSeek的git-multibranch任务中，智能体运行了一条带有rtk find 0.45.0版本不支持的标志的find命令。RTK插件将其重写为rtk find，而该命令本身又返回错误Use find directly。这导致智能体陷入一个反复尝试、反复被重写、反复失败的循环，在超时前累计产生339次连续错误，耗时约12分钟。虽然任务最终仍然通过，但成本是相应基线尝试的9倍。RTK在0.46.0版本中修复了这个问题，但这一案例说明终端输出压缩工具本身就可能成为智能体行为的不稳定因素。
工具输出在整体成本中的真实占比
一个关键的背景数据是：在没有RTK的情况下，终端输出仅占Fable输入token的7%，占DeepSeek输入token的26%。考虑到Claude Code中大约一半的Bash调用已经使用head、tail或wc自行限制输出，而RTK的钩子只在51%的OpenCode终端调用中被触发，RTK能够影响的范围远小于社交媒体宣传所暗示的。对于Fable来说，即使完全消除终端输出，理论上的成本上限也只降低7%，这解释了为什么实际测试中观察到的改善如此微小。