来源：HN (112pts)
URL: https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/
精读日期：2026-09-12
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • RTK（Rust Token Killer）宣称可削减 Claude Code 最多 60% token、压缩最多 90% 的 bash 输出，但“减少终端输出”≠“降低 AI 编码成本”。
  • 作者花费超 $1,500、数天时间，在 Terminal-Bench 2.1 上跑了 1,740 次尝试（85 个 Fable 任务 + 89 个 DeepSeek 任务，各 5 次基线 + 5 次 RTK）。
  • 结果：RTK 使 Fable 成本下降 5%、DeepSeek 成本上升 5%；通过率分别下降 1% 和 2%。
  • 按“每次通过成本”计：Fable 便宜 3%，DeepSeek 贵 7%；按任务等权计：Fable 贵 1%（与 0 无显著差异），DeepSeek 贵 18%。
  • Fable 的节省几乎全部来自单个任务（RTK 下轮数减半），其余任务节省不足 1%；DeepSeek 在同一任务上反而更贵。
  • 445 次 DeepSeek RTK 尝试中，RTK 报告节省 1.205 亿 token（两次各 1.205 亿），但报告值是按“原始字节减过滤字节 ÷ 4”估算，并非真实计费 token。
  • 无 RTK 时，工具输出仅占 Fable 输入 token 的约 11%、DeepSeek 的 40%；RTK 尝试中 Claude Code 31%、OpenCode 51% 的终端调用走了 RTK。
  • DeepSeek 的 RTK 尝试：终端输出字符减 9%，但 prompt token 反升 9%；未缓存输入降 1%、缓存输入升 9%；模型输出（含推理）占成本 56%（RTK）vs 57%（无 RTK）。
  • 轮数效应：DeepSeek 有 58 个任务 RTK 轮数更多，其中 44 个更贵；28 个任务轮数更少，其中 23 个更便宜。平均每轮输入少 7%，但总轮数多 18%。

二、方法/架构拆解

  • 被测工具：RTK 0.45.0，通过 Claude Code hook 匹配 Bash 调用、在 OpenCode 中重写 Git/测试/包管理/文件命令，返回更精简的同类输出。
  • 基准：Terminal-Bench 2.1（重终端交互），刻意不用 3.0/4.0，因 2.1 任务通过率高，“成本只在通过的任务上才有意义”。
  • 模型路由：Claude Code + Fable 5.0；OpenCode + DeepSeek V4 Pro 0813（经 OpenRouter）。
  • 实验设计：每任务同模型路由、同平台、同任务超时下各跑 5 次基线 + 5 次 RTK；剔除 4 个 Fable 安全拒答任务。
  • 成本度量三口径：总花费/通过数、任务等权平均、含失败尝试的总花费。
  • 环境版本：RTK 0.45.0、Claude Code 2.1.220、OpenCode 1.18.25、Harbor 0.20；轨迹已公开。

三、值得注意的局限/争议

  • 作者承认：
  • 结论基于 Terminal-Bench 2.1，未覆盖更难的 3.0/4.0。
  • RTK 报告的“token 节省”是字节估算，非计费 token，且假设后续轮次不变，未计入额外轮次成本。
  • 存在单个异常任务（插件把不支持的 0.45.0 命令反复重写导致循环），但去掉该任务趋势不变。
  • AI 判断：
  • 样本仅两个模型、一个基准，泛化性有限；“Fable 便宜 3%”与“任务级贵 1%”口径矛盾，说明结论对度量方式高度敏感。
  • 缓存机制（Fable 缓存读为常规输入 1/10、DeepSeek 1/30）使“压缩输出”的边际收益被大幅稀释，这是 RTK 逻辑的结构性弱点。
  • 作者结论“不推荐 RTK 作为通用省钱工具”较强，但仅基于当前前沿模型；对旧模型可能仍有效，作者自己也承认这点。

四、与 RRLab 研究的关联

  • Harness 工程：RTK 属“输出侧压缩”类 harness 优化，本文证明其收益被轮数、缓存、模型行为抵消——提示 harness 优化必须做端到端成本归因，而非只看中间指标。
  • 多模型协同：同一优化在 Fable 上省钱、在 DeepSeek 上更贵，说明 harness 组件需按模型路由差异化配置，不能一套通吃。
  • 模型评测：提供了可复用的成本评测方法论（多口径、含失败尝试、任务等权、轮数归因），可直接借鉴到 RRLab 的评测框架；也示范了“报告节省 vs 实际节省”的偏差检测。
  • Agent 落地：核心教训是“一次额外 agent 轮次可能贵过压缩省下的量”，落地时应以“每通过任务成本”和轮数分布为 KPI，而非 token 压缩率。
  • AI 原生产品：RTK 79k stars 与实测收益的落差，是“指标营销”风险的典型案例，产品定价/宣传应基于计费口径而非字节估算。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/