省 token 不等于省钱：RTK 自称砍掉近九成输出，实测 DeepSeek 那组成本反涨 17%

原文来源：Quesma — 一家数据库公司花 1500 多美元实测 RTK（Rust Token Killer）到底能不能省 AI 编程的钱，结论是省下的 token 和降下来的账单不是一回事。

RTK（Rust Token Killer）现在有 7.9 万 Star，做的事很直白：在 AI Agent 执行 shell 命令时插一层，把 ls、git、测试的输出压成更短的形式。官方口径是能砍掉最多 90% 的 bash 输出，一条"能把 Claude Code 的 token 用量砍掉 60%"的推文甚至拿下 31.3 万次浏览。

问题是，砍掉输出和砍掉账单是两件事。RTK 的 README 里其实留了一句免责声明：它能砍掉最多 90% 的 bash 输出，"但这不等同于把你的账单砍掉 90%"。JetBrains 在 SkillsBench 上的实测也没看到省钱。Quesma 团队于是把这件事测到底——花了好几天、烧掉 1500 多美元的 token，在 Terminal-Bench 2.1 上做了一轮对照实验。

RTK 到底做了什么

RTK 会重写 Agent 通过 shell 工具跑的那些 Git、测试、包管理和文件命令，每次返回一个更精简的同义输出。拿 ls -la 举例，RTK 保留文件名、大小和权限（644 表示 rw-r--r--），但会丢掉所有者和日期。对 Agent 来说，这些信息往往读一次就够了，省掉的成本看起来很低。

问题在于，"看起来很低"和"账单上真的更低"之间，还隔着三层东西：上下文缓存、多出来的轮次，以及模型自身的行为。这篇实测的价值就是把这三层逐层拆开。

实验是怎么设计的

选 Terminal-Bench 2.1 而不是更新的 3.0、4.0，理由很实际：只有 Agent 能通过的任务，谈成本才有意义。2.1 上大部分任务能过，3.0 和 4.0 还很难。

两条技术路线：Claude Code 配 Fable 5.0，以及 OpenCode 配 DeepSeek V4 Pro 0813（经 OpenRouter）。每个任务在相同模型、相同平台、相同超时下跑 5 次不带 RTK、5 次带 RTK。去掉 4 个触发拒绝的 Fable 安全任务后，最终覆盖 85 个 Fable 任务和 89 个 DeepSeek 任务，合计 1740 次尝试。

结果：一涨一跌，都贴着误差线

带 RTK 后，Fable 那组总账单降了 5%，DeepSeek 那组涨了 5%。通过率都略微下滑：Fable 降 1 个百分点，DeepSeek 降 2 个。

换个算法更清楚。把失败尝试的钱也算进去，再除以通过的次数，Fable 便宜了 3%，DeepSeek 贵了 7%。

再换一种——每个任务权重相同，避免一个昂贵的任务压过一堆便宜任务。这一算，Fable 反而贵了 1%，和零没有统计差异；DeepSeek 的任务平均成本涨了 17%。只看 10 次尝试全部通过的 36 个 DeepSeek 任务，涨幅依然是 18%。

Fable 那组几乎全部的"省钱"都来自一个任务：winning-avg-corewars。两种配置都能过，但带 RTK 时轮次少了一半。其余任务的节省不到 1%。同一个任务在 DeepSeek 上结果相反——带 RTK 轮次更多、也更贵。

为什么"省了 token"却没省钱

关键在 rtk gain 这个指标的口径。它算的是原始输出减去过滤后输出的字节数，再除以 4，并不是真正计费的 token 数。

一个例子很说明问题。在 train-fasttext 任务里，模型两次请求 head -1 train.txt。RTK 每次都"节省"了 1.205 亿 token——因为它是拿这个受限读取和整个文件比。这两次调用占了那次对比里节省计数器的 69%，可这两条命令本来就不可能返回整个文件。

另一个常被忽略的事实是缓存。在 Agent 编程里，每轮结束后上下文都会被缓存，后续读取终端输出大多走 cache read。Fable 的 cache read 单价是普通输入 token 的十分之一，DeepSeek 是三十分之一。

也就是说，缓存读占了输入 token 的 94%（Fable）和 98%（DeepSeek），但只占总账单的 30% 和 26%。真正的成本大头是模型输出（含推理），带 RTK 时占 56%，不带时占 57%——基本没动。

还有个更根本的比例问题：不装 RTK 时，工具输出只占 Fable 输入 token 的约 11%，占 DeepSeek 的 40%。而 Claude Code 有将近一半的 bash 调用本来就用 head、tail、wc 自己限制了输出。RTK 只重写 shell 命令，读文件和搜索走的是平台自带的 Read、Grep、Glob 工具，根本绕不过去。（这两个数字口径不同：11% 是"全部工具输出"占输入 token 的比例，而结论一节的 7% 指的是"终端输出"占整个上下文的比例——前者把 Read、Grep 也算进去了。）

多出来的轮次会吃掉节省

真正伤账单的是轮次。DeepSeek 带 RTK 的任务里，58 个任务轮次变多，其中 44 个更贵；28 个轮次变少，其中 23 个更便宜。平均每一轮输入少了 7%，但总轮数多了 18%——小轮次加起来并没有让总输入变少。

一次额外的 Agent 轮次，可能比压缩省下的那点多得多。JetBrains 在 SkillsBench 上看到了同样的模式：低 effort 下 RTK 增加了轮次，高 effort 下没降低成本。

RTK 的 bug 也会咬人

有个 DeepSeek 的 git-multibranch 尝试直接卡进了循环。Agent 跑了一条 find 命令，用了 RTK 0.45.0 的 rtk find 不支持的 flag；插件把它重写成 rtk find，结果报错"Use find directly"，然后每次重试又被重写一遍。Agent 连续攒了 339 个错误、耗了约 12 分钟才超时。任务最后还是过了，但成本是同组基线尝试的约 9 倍。RTK 在 0.46.0 修了这个问题，但那已经是实验之后的事。

结论

Quesma 的判断很直接：在 Terminal-Bench 2.1 上，不建议把 RTK 当成通用的省钱工具。Fable 的节省依赖单个任务、跨任务不成立。

更值得记住的是那组比例——当前前沿模型在用终端这件事上已经相当克制，Fable 的上下文里只有约 7% 是终端输出，模型自己就会用 head -n、tail -n 这类技巧。RTK 大概对更老的模型帮助更大。放到今天，它更像一个特定场景下的微调，而不是普适的成本优化。

对做 AI 编程工具的人来说，这篇实测还有个方法论上的提醒：任何声称"省 token"的工具，都该拿真实账单来验证，而不是拿它自己报的计数。rtk gain 这类指标衡量的是被移除的输出，不是被省下的钱，它完全可以让一次更贵的尝试看起来被优化过。要在自己的生产环境里跑对照，样本要够多，还要把失败尝试的成本算进去。