RTK 宣称节省 token，但我们的成本实测结果并不认同

RTK（Rust Token Killer）在 AI agent 读取之前过滤并压缩终端输出。如今 RTK 在 GitHub 上已获得超过 79k stars，是降低 AI 编程成本最流行的工具之一。

一篇帖子称 RTK 最多可将 Claude Code 的 token 用量削减 60%，获得了 313k 次浏览。

然而，JetBrains 在 SkillsBench 上的测试发现 RTK 并未带来成本节省。其 README 中还附有免责声明：

RTK 可将 agent 读取的 bash 输出削减最多 90%。[……] 但这并不等同于账单降低 90%。

因此，“更少的终端输出”并不等于“更便宜的 AI 编程”。它可能有帮助，可能毫无作用，甚至可能适得其反（导致轮次增加或输出质量下降）。本文报告了我们数天测试、花费超过 1,500 美元 token 费用后得出的结果。

RTK 的工作原理

RTK 可以重写 agent 通过其 shell 工具（Claude Code 中为 Bash，OpenCode 中为 bash）执行的 Git、测试、包管理和文件命令。每次重写都会返回相同内容的更精简版本。

例如，RTK 会保留文件名、大小和权限（644 对应 rw-r—r—），但会丢弃所有者和日期信息：

$ ls -la /app/warriors
-rw-r--r-- 1 root root  824 Sep 13  2025 g2-clear.red
-rw-r--r-- 1 root root  487 Sep 13  2025 paper.red

$ rtk ls -la warriors/
644  g2-clear.red  824B
644  paper.red  487B

在 Terminal-Bench 2.1 上测试 RTK

RTK 会压缩终端输出，因此我们在 Terminal-Bench 2.1 上进行了测试。该基准主要涉及大量的终端交互。我们选用了 2.1 版本，而非较新的 3.0 或 4.0 版本：智能体能够通过 2.1 的大多数任务，但 3.0 和 4.0 仍具挑战性。成本仅对通过的任务有意义。

我们使用 Fable 5.0 运行 Claude Code，并通过 OpenRouter 使用 DeepSeek V4 Pro 0813 运行 OpenCode。每个任务在无 RTK 和有 RTK 的条件下各执行五次，均在相同的模型路由、平台和特定任务超时设置下完成。

剔除四个因触发安全拒绝而失败的 Fable 任务后，最终对比涵盖 85 个 Fable 任务和 89 个 DeepSeek 任务，共计 1,740 次尝试。

第一张图表结果看似乐观

启用 RTK 后，Fable 的成本降低了 5%，而 DeepSeek 的成本上升了 5%。

Download as PNGClaude Code · Fable 5.0baseline$596$731(84% pass rate)RTK$546$698(83% pass rate)OpenCode · DeepSeek V4 Pro 0813baseline$26$51(71% pass rate)RTK$31$54(69% pass rate) Passed attempts Other attempts

启用 RTK 后通过率有所下降：Fable 下降 1%，DeepSeek 下降 2%。两者差距均很小。

若将所有支出（包括失败尝试）除以通过次数，Fable 使用 RTK 后成本降低 3%，DeepSeek 成本增加 7%。

另一种方法是同等加权每个任务，因为一个昂贵任务可能抵消多个廉价任务。我们比较了每个任务基线尝试的平均值与其 RTK 尝试的平均值，然后对这些变化量求平均。

Download as PNGRTK cost change vs baselineTotal bill changeAverage change per task95% confidence interval

在这一任务级指标下，Fable 成本增加 1%，与零差异无显著区别。DeepSeek 的任务成本平均上升 17%。

即使考虑失败情况，这一趋势也未改变。在全部十次尝试均通过的 36 个 DeepSeek 任务中，成本增幅仍为 18%。

单一任务决定了整个基准的测试结果

Fable 使用 RTK 带来的几乎全部节省都来自一个任务：winning-avg-corewars。两种配置下所有尝试均通过，但使用 RTK 时，完成所需的轮数约为前者的一半。在其他所有任务中，节省幅度均不足 1%。

DeepSeek 在同一个任务上得到了相反的结果。两种配置都通过了所有尝试，但 RTK 花了更多轮次、成本也更高。即使剔除该任务，RTK 的成本依然偏高。

rtk gain 作为成本指标毫无意义

RTK 文档把 rtk gain 定义为命令原始输出与过滤后输出的字节差除以 4，而不是实际计费的 token 数。

在 445 次 DeepSeek RTK 尝试中，RTK 报告节省了 3.492 亿 token，降幅 89%。

但报告的 token 节省量大，并不意味着任务更便宜。

Download as PNG

在 train-fasttext 中，模型两次请求 head -1 train.txt。RTK 把这些 limited 读取与整个文件做对比，每次都记为节省了 1.205 亿 token。这两次调用占了整个对比中节省计数器的 69%，尽管被请求的命令本来就不可能返回整个文件。

把 rtk gain 当作省下的钱，前提是假设尝试的其余部分保持不变。但 RTK 会改变 agent 后续的轮次，而 rtk gain 并不计入这些轮次的成本。

这正是社交媒体上那些帖子的误区所在：rtk gain 统计的是被移除的输出，而不是省下的钱，它会让一次成本更高的尝试看起来像是被优化了。

RTK 的 bug 也会坑你

一次 DeepSeek 的 git-multibranch 尝试陷入了死循环。agent 用了一个 rtk find 0.45.0 不支持的 flag 运行 find。插件把它改写成 rtk find，然后报错“Use find directly”。每次重试都被再次改写。RTK 在 0.46.0 中修复了这个问题，不过是在我们跑完测试之后。

Download as PNGAgentfind→Pluginrtk find→ErrorUse find directly连续 339 次报错约 12 分钟

agent 在超时前累计了 339 次连续报错。任务最终还是通过了，但成本是对应基线尝试（也通过了）的约 9 倍。这只是一次离群尝试，剔除后整体趋势不变。

终端输出只占账单的一小部分

不使用 RTK 时，工具输出大约占 Fable 输入 token 的 11%、DeepSeek 的 40%。

Download as PNGInput without RTKFable 5.07%4%Remaining inputTerminal 7%Other tools 4%DeepSeek V4 Pro 081326%14%Remaining inputTerminal 26%Other tools 14%

在 RTK 的测试中，Claude Code 31% 的终端调用和 OpenCode 51% 的终端调用使用了 RTK。

RTK 仅重写 Shell 命令：其在 Claude Code 中的 Hook 匹配 Bash 工具，而在 OpenCode 中的插件作用于 bash 调用。两个平台都将文件读取和搜索暴露为独立的 Read、Grep 和 Glob 工具，这些工具会绕过 RTK。Claude Code 约一半的 Bash 调用已通过 head、tail 或 wc 自行限制了输出量。

在智能体编码中，上下文在每轮之后会被缓存，因此后续读取终端输出主要体现为缓存读取。对于 Fable，缓存读取的成本是普通输入 Token 的 1/10；对于 DeepSeek，则是 1/30。

Download as PNGCache reads with RTKFable 5.0DeepSeek V4 Pro 0813Share of input tokens94%98%Share of total bill30%26%

在 DeepSeek 中，RTK 将终端输出字符减少了 9%，但提示词 Token 却增加了 9%。未缓存输入下降了 1%，而缓存输入上升了 9%。使用 RTK 时，模型输出（包括推理部分）占总成本的 56%；不使用时则为 57%。

额外轮次可能抵消节省

当智能体执行更多轮次时，任务成本通常也会随之上升。

Download as PNGClaude Code · Fable 5.0Turns, log scaleCost ($), log scaleOpenCode · DeepSeek V4 Pro 0813Turns, log scaleCost ($), log scale

在 DeepSeek 的 RTK 测试中，58 个任务经历了更多轮次，其中 44 个任务成本更高。在 28 个经历更少轮次的任务中，23 个成本更低。

使用 RTK 时，DeepSeek 的平均每轮输入减少了 7%，但总轮次增加了 18%。单轮输入减少并未转化为总输入量的降低。

多执行一轮智能体操作带来的成本，可能高于压缩节省的成本。这与Tokenflation（Token 膨胀）问题是同一类现象的不同表现形式。JetBrains 在 SkillsBench 上也观察到了类似规律：RTK 在低强度任务中增加了轮次，但在高强度任务中未能降低成本。

RTK 并不能让 AI 编码更便宜

在 Terminal-Bench 2.1 上，Fable 的节省效果依赖于单一任务，且在不同任务间表现不一致。我们不建议将 RTK 作为通用的成本节省工具。

从单次会话记录来看，当前的前沿模型已能高效使用终端（Fable 的上下文输出中仅有约 7% 来自终端）。模型自身也会主动使用 head -n 或 tail -n 等技巧。RTK 可能在旧模型上帮助更大。如今它更像是一种细分场景的优化，而非普遍性的成本节省手段。

测试环境：RTK 0.45.0、Claude Code 2.1.220、OpenCode 1.18.25 和 Harbor 0.20。如需后续研究，可索取运行轨迹。订阅以获取后续文章，包括我们计划发布的 Headroom 基准测试。感谢 Piotr Migdał 的审阅与反馈。