RTK 报告显示节省了 token,但我们的成本基准测试结果并不一致。
RTK reports token savings, but our cost benchmarks disagree

原始链接: https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/

RTK(Rust Token Killer)是一款旨在通过压缩终端输出以降低 AI 编码成本的常用工具。然而,通过 Terminal-Bench 2.1 对 1,740 次测试进行的严谨分析表明,RTK 并不能持续节省成本,在某些情况下反而会增加开支。 研究结果指出了以下几个关键问题: * **指标误导性**:RTK 的“收益”指标追踪的是压缩字节数,而非实际计费的 Token 数。报告中显示的大额节省通常源于那些本身输出就有限的命令。 * **影响微乎其微**:终端输出在总上下文中所占比例较小,且现代 AI 模型已经能够通过 `head` 或 `tail` 等命令熟练地控制输出。 * **“回合”惩罚**:RTK 有时会迫使智能体进入不必要的循环或产生更长的序列来达到相同结果。由于额外一次智能体交互的成本通常高于压缩节省的费用,该工具可能会无意中推高总账单。 * **结论**:虽然 RTK 对旧版模型或许有用,但如今它已基本沦为一种小众优化手段。对于现代前沿模型,它无法提供可靠的经济效益,因此不建议作为通用的成本节约方案使用。

近期一则 Hacker News 的讨论对诸如 RTK 等所谓“节省 Token 的技巧”提出了质疑,贡献者们认为许多此类旨在提升生产力的方法实为无效的“江湖骗术”。 一位用户 `aeneas_ory` 指出,开发者不应依赖这些捷径,而应利用本地代码嵌入模型(local code embedding models)进行语义索引。通过对代码库进行索引,开发者可以执行语义搜索,从而减少让大语言模型(LLM)解析整个文件或代码仓库时通常所需的“暴力”Token 消耗。尽管这种方法在索引时会产生更高的前期 CPU 开销,但该用户声称,与传统的基于 grep 的方法相比,它显著提高了 Token 利用效率和实际耗时。 另一位评论者 `vrighter` 则提出了反驳观点,他认为通过向 LLM 提供预处理或压缩过的语义数据,开发者本质上是提供了模型在训练阶段并未接触过的内容,这可能会影响模型的性能。总体而言,该讨论反映出一种日益形成的共识:复杂的“技巧”往往不如有针对性的、基于搜索的检索策略有效。
相关文章

原文

RTK (Rust Token Killer) filters and compresses terminal output before the AI agent reads it. With over 79k GitHub stars today, RTK is one of the most popular tools to make AI coding cheaper.

One X post saying RTK could cut Claude Code tokens by up to 60% reached 313K views.

Yet JetBrains’s SkillsBench run found no savings. The README has a disclaimer:

RTK cuts up to 90% of the bash output your agent reads. […] it is not the same as cutting your bill by 90%.

So “less terminal output” is not the same as “cheaper AI coding”. It can help, be a no-op, or backfire (more turns or lower quality). In this post, we present our findings after several days and over $1,500 spent on tokens.

How RTK works

RTK can rewrite Git, test, package and file commands the agent runs through its shell tool (Bash in Claude Code, bash in OpenCode). Each rewrite returns a terser version of the same output.

For example, RTK keeps file names, sizes and permissions (644 means rw-r—r—), but drops the owner and date:

$ 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

Testing RTK on Terminal-Bench 2.1

RTK compresses terminal output, so we tested it on Terminal-Bench 2.1, a benchmark with heavy terminal interaction. We stayed on 2.1 rather than the newer 3.0 and 4.0: agents pass most 2.1 tasks, while 3.0 and 4.0 are still a challenge. Cost only matters for tasks that pass.

We ran Claude Code with Fable 5.0, and OpenCode with DeepSeek V4 Pro 0813 through OpenRouter. Each task was scheduled five times without RTK and five times with it, on the same model route, platform and task-specific timeout.

After removing four Fable security tasks that got refusals, the final comparison covers 85 Fable tasks and 89 DeepSeek tasks, or 1,740 attempts.

The first chart was promising

With RTK, costs fell by 5% for Fable and rose by 5% for DeepSeek.