RTK报告令牌节省，但我们的成本基准不一致

# RTK报告节省大量token，但我们的成本基准测试显示结果不同 来源：https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/ RTK（https://github.com/rtk-ai/rtk）（Rust Token Killer）在AI代理读取之前过滤并压缩终端输出。截至今日在GitHub上获得超过7.9万星标，RTK已成为降低AI编码成本最受欢迎的工具之一。 一条X帖子声称RTK能将Claude Code的token消耗削减高达60%（https://x.com/jasonzhou1993/status/2038215854584906078），获得了31.3万次浏览。 FuturMinds标题为《Claude Code配合RTK：节省90% token》的视频（https://www.youtube.com/watch?v=CncyYt9ozAQ）显示3.1万次观看；Soba Labs题为《我们如何用RTK将Claude Code token使用量减半》的文章（https://sobalabs.ai/blog/halving-claude-code-token-usage-with-rtk/）；ComputeLeap指南《使用rtk将Claude Code token成本降低60-90%》（https://www.computeleap.com/blog/cut-claude-code-token-costs-rtk-guide-2026/）。 然而JetBrains的SkillsBench测试未发现节省效果（https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/）。其README文档（https://github.com/rtk-ai/rtk#how-savings-work）包含免责声明： > RTK最多可削减代理读取的bash输出量的90%。[...] 这与将您的账单削减90%并非同一回事。 因此"更少的终端输出"并不等同于"更便宜的AI编码"。它可能有所帮助，可能无效，甚至可能产生反效果（更多轮次或更低质量）。本文将展示我们在花费数日、超过1500美元token费用后的研究发现。 ## RTK工作原理 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#how-rtk-works RTK可重写代理通过其shell工具执行的Git、测试、包管理和文件命令（Claude Code中为`Bash`，OpenCode中为`bash`）。每次重写都会返回更简洁的相同输出版本。 例如，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 https://quesma.com/blog/does-rtk-make-ai-cench/#testing-rtk-on-terminal-bench-21 RTK压缩终端输出，因此我们在Terminal-Bench 2.1（https://www.tbench.ai/news/terminal-bench-2-1）上测试了该工具——这是一个重度依赖终端交互的基准测试。我们选择2.1版本而非更新的3.0（https://www.tbench.ai/news/terminal-bench-3-0）和4.0（https://www.tbench.ai/news/terminal-bench-4-0）：代理能通过大多数2.1任务，而3.0和4.0仍具挑战性。成本仅对通过的任务有意义。 我们通过OpenRouter运行了配备Fable 5.0的Claude Code和配备DeepSeek V4 Pro 0813的OpenCode。每个任务在无RTK和有RTK条件下分别调度五次，使用相同的模型路由、平台和任务特定超时时间。 排除四个因安全原因被拒绝的Fable任务后，最终比较涵盖85个Fable任务和89个DeepSeek任务，总计1740次尝试。 ## 初步图表显示前景乐观 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#the-first-chart-was-promising 使用RTK后，Fable成本下降5%，而DeepSeek成本上升5%。 Claude Code · Fable 5.0 基线$731（84%通过率） RTK $698（83%通过率） OpenCode · DeepSeek V4 Pro 0813 基线$51（71%通过率） RTK $54（69%通过率） 通过尝试 其他尝试 使用RTK时通过率更低：Fable下降1%，DeepSeek下降2%。两个通过率差距都很小。 当我们将所有支出（包括失败尝试）除以通过次数时，Fable使用RTK便宜3%，DeepSeek则贵7%。 另一种方法是平等对待每个任务，因为一个昂贵任务可能抵消多个低成本任务。我们比较了每个任务基线尝试的均值与其RTK尝试的均值，然后对这些变化取平均值。 RTK成本变化（相对于基线） Claude Code Fable 5.0 -5% | +1% OpenCode DeepSeek V4 Pro 0813 +5% | +17% -5% | 0% +5% | +10% +15% | +20% +25% | +30% 总账单变化 | 每任务平均变化 95%置信区间 在此任务级别指标上，Fable贵1%，与零无明显差异。DeepSeek任务成本平均**上涨17%**。 考虑失败情况并不改变趋势。在所有十次尝试均通过的36个DeepSeek任务中，成本仍增加18%。 ## 一个任务决定了整个基准测试的结果 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#one-task-made-the-difference-in-the-whole-benchmark Fable使用RTK节省的成本几乎全部来自一个任务：`winning-avg-corewars`。两种配置均通过所有尝试，但使用RTK时在约一半的轮次内完成。在其他任务中，节省幅度不足1%。 DeepSeek在同一任务上出现相反结果。两种配置均通过所有尝试，但RTK需要更多轮次且成本更高。即使不包括该任务，使用RTK的成本仍然更高。 ## `rtk gain`作为成本指标毫无用处 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#rtk-gain-is-useless-as-a-cost-metric RTK文档将`rtk gain`（https://github.com/rtk-ai/rtk/blob/develop/docs/guide/resources/savings-explained.md#how-to-read-rtk-gain）定义为原始命令输出与过滤后命令输出的字节差值除以4，并非已计费token数量。 在445次DeepSeek RTK尝试中，RTK报告**节省3.492亿token**，减少89%。 大量的报告token节省并未带来更低的任务成本。 rtk gain 平均任务成本变化 0% | large-scale-text-editing 57.3M | -19% crack-7z-hash 38.9M | +28% 其他87个任务 253.0M | +18% 在`train-fasttext`中，模型两次请求`head -1 train.txt`。RTK通过将这些有限读取与整个文件比较，每次报告节省1.205亿token。这两次调用占**比较节省计数器的69%**，尽管请求的命令永远不会返回整个文件。 将`rtk gain`视为节省资金的前提是假设尝试的其余部分保持不变。RTK可以改变代理的后续轮次。`rtk gain`未考虑这些轮次的成本。 这就是社交帖子出错的地方：`rtk gain`计算的是移除的输出量而非节省的资金，它可能使更昂贵的尝试看起来经过了优化。 ## RTK的缺陷可能让你付出代价 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#rtk-bugs-can-bite-you 一个DeepSeek的`git-multibranch`尝试陷入循环。代理运行了带RTK 0.45.0不支持的标志的`find`命令。插件将其重写为`rtk find`，该命令返回"请直接使用`find`"错误。每次重试都被再次重写。RTK在0.46.0版本中修复了此问题（https://github.com/rtk-ai/rtk/commit/6370e79275ef8c1063fc9b682bc36e7e63041b53），这发生于我们运行测试之后。 **339次连续错误** ~12分钟 代理在超时前累积了**339次连续错误**。它仍然通过了任务，但成本约为对应基线尝试的**9倍**，后者同样通过。这是一次异常尝试；趋势即使排除它仍然成立。 不使用RTK时，工具输出约占Fable输入token的11%，DeepSeek的40%。 在RTK尝试中，Claude Code的31%终端调用和OpenCode的51%终端调用使用了RTK。 RTK仅重写shell命令：其Claude Code钩子匹配`Bash`工具，OpenCode插件处理`bash`调用。两个平台都将文件读取和搜索作为单独的`Read`、`Grep`和`Glob`工具暴露，这些会绕过RTK（https://github.com/rtk-ai/rtk/blob/v0.45.0/README.md）。约一半的Claude Code Bash调用已使用`head`、`tail`或`wc`限制自身输出。 在代理编码中，每轮后上下文会被缓存，因此后续对终端输出的读取主要表现为缓存读取。这些读取成本对Fable而言是常规输入token的1/10，对DeepSeek是1/30。 在DeepSeek中，RTK将终端输出字符减少了9%，但提示token增加了9%。未缓存输入下降1%，缓存输入增加9%。模型输出（包括推理）占RTK成本的56%，无RTK时为57%。 当代理采取更多轮次时，任务成本通常随之上升。 Claude Code · Fable 5.0 轮次（对数坐标） 2 | 2 5 | 5 10 | 10 20 | 20 50 | 50 100 | 100 RTK 基线 x = y 成本（美元，对数坐标） 0.1 | 0.1 0.2 | 0.2 0.5 | 0.5 1 | 1 2 | 2 5 | 5 10 | 10 20 | 20 RTK 基线 x = y OpenCode · DeepSeek V4 Pro 0813 轮次（对数坐标） 2 | 2 5 | 5 10 | 10 20 | 20 50 | 50 100 | 100 200 | 200 RTK 基线 x = y 成本（美元，对数坐标） 0.01 | 0.01 0.02 | 0.02 0.05 | 0.05 0.1 | 0.1 0.2 | 0.2 0.5 | 0.5 1 | 1 RTK 基线 x = y DeepSeek的RTK尝试在58个任务中采用了更多轮次，其中44个成本更高。在28个任务中采用更少轮次，其中23个成本更低。 平均而言，DeepSeek使用RTK时每次轮次输入减少7%，但总轮次增加18%。更小的轮次未能累积成更少的总输入。 一次额外的代理轮次可能比压缩节省的成本更高。这是另一种形式的token膨胀（https://www.tbench.ai/blog/tokenflation-when-hi-triggers-33-tool-calls）问题。JetBrains在SkillsBench上观察到相同模式：RTK在低投入任务中增加了轮次，在高投入任务中未降低成本。 ## RTK并未使AI编码更便宜 https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#rtk-does-not-make-ai-coding-cheaper 在Terminal-Bench 2.1上，Fable的节省依赖于一个任务且不适用于其他任务。我们不推荐将RTK作为通用成本节省工具。 个别对话记录显示，当前前沿模型已经能高效利用终端（仅约7%的Fable上下文是终端输出）。模型自身会使用`head -n`或`tail -n`等技术。RTK可能对旧模型帮助更大。如今它属于小众优化，并非普遍节省的来源。 *使用RTK 0.45.0、Claude Code 2.1.220、OpenCode 1.18.25和Harbor 0.20进行测试。轨迹数据可应要求提供（https://quesma.com/cdn-cgi/l/email-protection#adcec2c3d9ccced9eddcd8c8dec0cc83cec2c0）以供后续研究。订阅（https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/#mce-EMAIL）获取未来文章，包括我们计划的Headroom（https://github.com/headroomlabs-ai/headroom）基准测试。感谢Piotr Migdał的审阅和反馈。*