RTK 宣称省 Token,实测成本反而涨了

RTK reports token savings, but our cost benchmarks disagree

RTK 宣称省 Token,实测成本反而涨了

RTK 号称能削减 90% 的终端输出,让 AI 编程更便宜,但我们的实测结果却大相径庭。在 Terminal-Bench 2.1 基准测试中,我们投入超过 1500 美元,对比了 Fable 5.0 和 DeepSeek V4 Pro 的表现。结果显示,RTK 不仅没有显著降低成本,反而在 DeepSeek 任务中导致成本平均上升 17%。问题在于,RTK 压缩输出可能迫使 AI 代理进行更多轮次的交互,单次节省的 Token 远抵不过额外轮次带来的开销。此外,RTK 报告的 Token 节省数据存在误导,它计算的是被过滤的字节数而非实际计费 Token。对于已经懂得使用 head 或 tail 等命令优化输出的前沿模型,RTK 更多是锦上添花甚至可能适得其反,而非通用的省钱利器。

RTK 报告的 Token 节省量并不等同于实际账单的减少,它统计的是被移除的输出字节,而非你真正省下的钱。
  1. aeneas_ory

    所有这些“技巧”都是骗人的鬼话,我想我们心底都清楚。不管是 caveman、RTK,还是其他那些靠氛围包装的生产力/省 Token 技巧/技能/claude.md。

    我真正有效的方法(虽然基准测试数据有点旧)是用专门的本地代码嵌入模型来索引代码库。这在 CPU 端有点费资源,但在我的测试中,它显著降低了 Token 用量和实际运行时间。当然,这始终取决于统计噪声和主机系统负载,而且运行足够大规模的基准测试本身太贵了,所以请酌情参考。

    你可能会问为什么这招管用?好吧,LLM 基本上是靠暴力穷举单词/短语,然后把这些扔给 find/grep/pgrep 之类的工具(或者像最近这里讨论的那样,写个 Python 脚本来做——https://news.ycombinator.com/item?id=49654229)。语义搜索则是寻找相似性,所以你需要做的暴力穷举就少多了。当然,代价是得先索引所有内容。

    项目地址在这里:https://github.com/ory/lumen

  2. oefrha

    任何稍微看过 rtk gain 输出的人都能一眼看穿,根本不需要什么基准测试。Agent 运行

    rtk command-that-prints-100k-tokens | tail -5

    不用 rtk 时成本是 5 行,大概 100 个 Token,但 rtk 会报告节省了 10 万 Token。当然,它根本不知道后面还有个 tail -5。

    更糟糕的是,由于 rtk 默认会持久化这个节省统计,它破坏了沙箱隔离。在命令前加 rtk 前缀,时不时还会导致随机的自动模式拒绝(这与禁用节省统计持久化无关)。

    老实说,我真不知道任何懂点 CLI 常识的人为什么会把 rtk gain 当真。我猜大概是那些对终端一无所知、只会搞氛围编程的人,看到那个统计数字就觉得自己赚到了吧?

    话虽如此,rtk 在压缩重复的测试运行输出等方面还是有点用的,但你只应该把它用在白名单命令上;像他们建议的那样把所有命令都包起来,纯属蠢行。

  3. ProjectBarks

    看起来这些工具大多都是画大饼。在 Headroom 和 RTK 上做的基准测试表明,两者都未能带来真正的节省。如果真有这么简单的预处理步骤能实现,AI Labs 为什么不自己把优化方案推送到上游呢?

    我猜它们要么根本不管用,要么就是让模型的行为变得混乱不堪。我真的觉得需要某种独立的基准测试。

    以下是展示这类工具存在完全相同问题的其他案例:

    https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-...

    https://brandonbarker.me/writing/headroom-fewer-tokens-bigge...

  4. gillesjacobs

    核心结论:

    每次尝试的平均成本,未使用 RTK → 使用 RTK:

    Claude/Fable: $1.72 → $1.64(约便宜 5%)

    DeepSeek: $0.115 → $0.121(约贵 5%)

    几乎所有的 Claude 节省都来自单一任务。

    排除该任务后,节省幅度不足 1%。

    我读了好几遍才把核心数据提炼出来。

    这篇文章真是把重点藏得太深了。

  5. fg137

    很高兴看到越来越多的人意识到这些不过是骗人的鬼话。如果没有像基准测试这样的客观指标,任何声称都毫无意义。

    我对技能/插件也是这种感觉。虽然某些技能确实能为特定项目/环境提供重要上下文,但我非常怀疑那些(过度)泛化的技能,比如“编写 JS 测试”或“创建规范”。我公司内部就有几十种这样的技能,但我从未见过任何基准测试能证明,它们比简单直接的单句提示在有意义的方式上(即具有统计显著性)表现更好。

同日更多故事

2026-09-11