RTK 到底能省多少 Token？从 60～90% 宣传到真实编程任务，公开测评数据整理
RTK，全称 Rust Token Killer，是一个面向 Claude Code、Codex 等编程代理的命令行代理工具。它会拦截 git status、git diff、测试命令、日志读取等操作，在输出进入模型上下文之前进行过滤、压缩和去重。
RTK 早期公开资料中出现最多的数字是 60%～90% Token 节省。但不同资料测量的对象并不相同。有的统计单条命令输出，有的统计 RTK 自己记录的压缩量，也有测试直接比较完成相同编程任务后的总成本。
下面只整理目前能够查到的公开测试数据。
RTK 官方 README：30 分钟 Claude Code 会话估算
RTK 早期 README 将项目描述为可以在常见开发命令中减少 60%～90% 的 Token 消耗，并提供了一组模拟 30 分钟 Claude Code 会话的数据。
官方给出的数据以中等规模 TypeScript / Rust 项目为参考，比较普通命令输出和经过 RTK 压缩后的输出。
| 操作 | 普通输出 | RTK 输出 | 官方节省率 |
|---|---|---|---|
ls / tree | 2,000 | 400 | 80% |
cat / read | 40,000 | 12,000 | 70% |
grep / rg | 16,000 | 3,200 | 80% |
git status | 3,000 | 600 | 80% |
git diff | 10,000 | 2,500 | 75% |
git log | 2,500 | 500 | 80% |
git add/commit/push | 1,600 | 120 | 92% |
cargo test / npm test | 25,000 | 2,500 | 90% |
pytest | 8,000 | 800 | 90% |
go test | 6,000 | 600 | 90% |
| 合计 | 约 118,000 | 约 23,900 | 约 80% |
官方同时注明，这些数字基于中等规模项目估算，实际结果会随着项目大小变化。这里比较的是开发命令产生的输出被压缩前后的数量。
按照这组官方数据，RTK 对测试日志、代码搜索、Git 差异等输出较长的命令，可以将单次命令输出压缩 70%～90%。
RTK 作者早期实测：两周报告节省 10.2M Token
网页地址：www.reddit.com/r/ClaudeAI/…
RTK 作者 Patrick Szymkowiak 在 Reddit 发布项目时，公开了自己工作流中的数据。
他给出的几个例子包括：
| 操作 | 原始输出 | RTK 输出 | 报告降幅 |
|---|---|---|---|
cargo test | 155 行 | 3 行 | 98% |
git status | 119 字符 | 28 字符 | 76% |
| 两周累计 | — | — | 10.2M Token 、89.2% |
作者写出的原始数字是：
“10.2M tokens saved (89.2%)”
中文即：两周累计报告节省 1020 万 Token ，节省率 89.2%。
这篇帖子记录的是作者自己使用 RTK 后，由 RTK 对被处理命令输出进行统计得到的数据。帖子没有设置一个“不安装 RTK、完成相同任务”的对照组，也没有提供 Claude Code 供应商账单的 A/B 成本对比。
GitHub 独立开发者测试：14 条真实命令平均压缩 65.7%
2026 年 6 月，一名独立开发者在 RTK 的 GitHub Discussions 中发布了一组 Rust 项目实测。
测试使用 RTK v0.42.3，项目约有 64 个模块、1.7 万行 Rust 代码，最终统计了 14 条真实命令。
| 命令 | 原始输出 | RTK 输出 | 输出变化 |
|---|---|---|---|
ls src | 563 字节 | 80 字节 | -85.8% |
read filter.rs | 17,935 字节 | 3,932 字节 | -78% |
env | 约 50KB | 约 150 字节 | -99.7% |
git status | 约 100 字节 | 约 50 字节 | -48.1% |
git log -n 5 | 56 字节 | 86 字节 | +53% |
| 14 条命令综合 | — | — | -65.7% |
这组数据里，不同命令之间的差距很大。高输出命令可以压缩 80%～99%，但原本已经很短的 git log 输出从 56 字节增加到 86 字节，最终输出反而增加约 53%。
测试作者将 README 中的 60%～90% 称为偏目标性质的数字，并把自己的综合实测结果概括为 更接近 60%～70% 的命令输出节省。
独立长期实测：8,587 条命令表面削减 90.4%，但数据高度集中
2026 年 6 月，一名开发者整理了自己约 40 天、8,587 条命令的 RTK 历史数据库。
测试环境是单一 Rails Monorepo，数据直接来自 RTK 的 history.db。
整体统计如下：
| 指标 | 数据 |
|---|---|
| 命令数量 | 8,587 |
| 原始输入 | 96.0M |
| 压缩后输出 | 9.3M |
| 报告削减量 | 86.8M |
| 报告削减率 | 90.4% |
| 回退次数 | 2,501 |
| 回退比例 | 29.1% |
但 86.8M 的总削减量并没有平均分布在 8,587 条命令上。
其中 68.7M，占全部削减量的 79.2%，来自仅仅 7 次 Rails 开发日志读取。这些日志每次原始统计量达到约 900 万～1000 万 Token ，压缩率达到 99.8%。
不同 Git 命令的数据也存在较大差距：
| Git 操作 | 次数 | 原始输入 | 压缩后输出 | 削减率 |
|---|---|---|---|---|
git diff | 433 | 5.18M | 0.53M | 89.7% |
git show | 144 | 0.49M | 0.45M | 8.0% |
git log | 527 | 0.16M | 0.13M | 19.0% |
git status | 331 | 1.34M | 1.16M | 13.1% |
git commit | 93 | 0.01M | — | 95.9% |
按周统计时，差异同样很大。有巨大日志参与的工作周达到 90%、95% 和 98% ；一个以现有代码阅读、差异检查和重构为主、没有巨大输出的工作周只有 13% 。
原作者的结论是，RTK 在运行应用、查看大量日志、执行测试等工作中压缩量较高；以代码阅读、规范、评审和文档为主的工作中，压缩效果较弱。
作者还记录了输出压缩造成的信息损失问题，包括旧版本中 git commit 返回错误的成功信息、git diff 摘要与实际差异不一致、git status 信息缺失等。其中部分问题后来已经修复，部分问题在测试文章发布时仍处于 Issue 或修复请求阶段。
Reddit 用户实测：一天只有 0.3%，有人遇到额外工具调用
网页地址：www.reddit.com/r/ClaudeAI/…
2026 年 5 月，一名 Claude Code 用户在 Reddit 发布自己的使用结果。
该用户表示，使用 RTK 一天后，看到的节省率只有 0.3% 。他还记录了 300 多次读取操作，RTK 在这些读取上的统计节省为 0%。
同一讨论中，另一名用户表示，Claude 有时会发现 RTK 截断了所需信息，然后改用其他方式重新获取完整内容。
7 月的跟帖中，还有用户报告类似情况：被截断的信息导致编程代理执行更多工具调用，最终 Token 使用量反而增加。
这些内容属于社区用户使用反馈，没有统一测试环境，也没有统一样本规模。
GitHub Issue 数据复核：一次截断曾被统计成 2.27 万“节省 Token ”
2026 年 4 月，GitHub Issue #1045 报告了一个与 rtk gain 统计有关的问题。
报告者发现，当 rtk read --max-lines 主动截断文件时，被用户要求丢弃的内容也会被计入 RTK 的“ Token 节省”。
其实际历史数据一度显示：
| 指标 | RTK 统计 |
|---|---|
| 总命令数 | 92 |
| 输入 Token | 278.1M |
| 输出 Token | 6.0K |
| 节省 Token | 278.1M |
| 节省率 | 100.0% |
rtk read 贡献 | 269.2M |
报告者表示，这 2.78 亿的“节省”几乎全部由少量大型生物信息文件读取产生，并将这部分数据称为不真实的节省。
Issue 中还给出了一个更小的复现样本。
一个 90,890 字节、1000 行的文件，只读取一行时，RTK 记录：
| 指标 | 数值 |
|---|---|
| 输入 Token 估算 | 22,723 |
| 实际输出估算 | 9 |
| “节省” | 22,714 |
| “节省率” | 99.96% |
Issue 作者认为，这里的 99.96% 没有代表真实压缩，因为绝大多数内容本来就是通过 --max-lines 1 主动要求不读取的。
后续 Issue #1561 又指出，类似的统计方式可能出现在带 --max-lines 的 git diff 和 git show 中。
JetBrains A/B 基准测试：低推理强度成本反增 7.6%，高强度基本持平
网页地址：blog.jetbrains.com/ai/2026/07/…
2026 年 7 月，JetBrains 对 RTK 做了一次成对 A/B 基准测试。
测试使用 Claude Code 2.1.201、Claude Sonnet 5 和 SkillsBench。完整测试覆盖 86 个任务，分别运行低推理强度和高推理强度配置。全部测试合计 425 次计费运行，成本约 320 美元。
对照组使用原生 Claude Code，实验组使用 RTK v0.43.0，并启用官方 rtk init -g 配置。
低推理强度完整测试中，共获得 80 对可比较任务：
| 指标 | RTK 相对对照组 |
|---|---|
| 每任务成本中位数 | +7.6% |
| 成本显著性 | p=0.004 |
| 对话轮次 | +13.8% |
| 轮次显著性 | p=0.03 |
| 缓存读取 | +14.3% |
| 缓存读取显著性 | p=0.008 |
| 新输入 Token | +3.2% |
| 新输入显著性 | p=0.23 |
也就是说，在这组低推理强度任务里，RTK 组没有降低总成本，成本中位数反而增加了 7.6%。
高推理强度下，86 个任务重新运行。结果为：
| 指标 | RTK 相对对照组 |
|---|---|
| 每任务成本中位数 | +0.1% |
| 成本显著性 | p=0.99 |
| 对话轮次 | +0.0% |
| 轮次显著性 | p=0.74 |
JetBrains 将这组结果视为基本持平。
任务质量没有检测到统计上的差异。低推理强度中，RTK 组相对对照组为 5 个更好、4 个更差、71 个持平；高推理强度为 5 个更好、4 个更差、62 个持平，两组符号检验均为 p=1.0。
JetBrains 还分析了 RTK 实际能够处理多少代理上下文。在已有任务记录中，大约只有 33% 的 Bash 调用能够被 RTK 处理，而这些调用携带的内容不到全部工具返回字符的 20% 。JetBrains 据此估算，即使 RTK 把自己能够处理的部分压缩 70%，对完整输入 Token 的理论影响也只有约 3% 。
同一次低推理强度测试中，RTK 自己的 rtk gain 报告节省了 9620 万 Token ，节省率 99.8% ；但同一批任务的实际计费结果增加了 7.6%。
JetBrains 给出的原因包括：RTK 会把完整原始命令输出作为对照，但 Claude Code 本身会截断过大的工具输出；RTK 使用字符数除以 4 估算 Token ；同时大量上下文、缓存重新读取和 Claude Code 内置工具并不经过 RTK。
JetBrains 最终结论是，在他们测试的真实编程代理任务中，没有复现 README 所展示的 60%～90% 整体节省。低推理强度出现 7.6% 成本增加，高推理强度则基本没有变化。
RTK 当前官方文档：60～90% 已明确限定为 Bash 输出压缩
2026 年 7 月 22 日，有用户在 GitHub Issue #3157 中指出，当时 README 使用的宣传语仍是：
“reduces LLM token consumption by 60–90%”
即“减少 60%～90% 的大模型 Token 消耗”。该 Issue 同时引用了 JetBrains 的 +7.6% 成本测试结果。
截至本文整理时，RTK develop 分支的 README 已经将描述改为：
“cuts up to 90% of the bash output your agent reads”
中文含义是：最多减少编程代理读取的 90% Bash 输出。
当前 README 还明确增加了一段说明：RTK 测量的是 Bash 输出减少量，不等于账单减少 90% 。Bash 输出只是输入 Token 的一部分，而输入 Token 又只是完整成本的一部分。
官方的《RTK 节省机制说明》进一步定义了 rtk gain 中几个指标的含义：
| RTK 指标 | 当前官方定义 |
|---|---|
| Input | 原始命令输出字节数 ÷ 4 |
| Output | 压缩后命令输出字节数 ÷ 4 |
| Saved | Input - Output |
| Save% | Bash 输出字节减少比例 |
RTK 当前官方文档明确表示，项目没有集成真实模型分词器，所谓 Token 数量使用 bytes / 4 估算。因此百分比可以用于描述命令输出前后的比例变化，但绝对 Token 数量是近似值，不会与模型供应商的计费数据一致。
官方还明确列出了 RTK 不会减少的内容：模型生成的输出 Token 、用户提示词、系统提示词和对话历史都不由 RTK 处理；Claude Code 自带的 Read、Grep、Glob 等工具也不会自动经过 Bash Hook。
总结
把这些公开数据放在一起，需要先区分两个指标。
RTK 对命令行输出本身的压缩是真实存在的。 官方示例中的测试、日志、搜索等命令常见 70%～90% 的压缩；GitHub 独立测试的 14 条命令综合为 65.7%；另一组持续约 40 天、8,587 条命令的使用记录甚至得到 90.4% 的统计削减率。
但这些数字主要描述的是 RTK 接触到的命令输出被压缩了多少。
它们不能直接等同于“Claude Code 整体少用了多少 Token ”或者“账单降低了多少”。
长期 8,587 条命令的测试里，90.4% 的总成绩高度依赖超大日志：仅 7 次日志读取贡献了全部削减量的 79.2%。没有巨大日志参与的一周，统计削减率曾降到 13%。不同命令之间也从 git diff 的 89.7% 到 git status 的 13.1% 不等。
社区数据同样存在较大跨度，有用户记录到一天只有 0.3% 的节省，也有人报告压缩信息不足后，Claude 会重新调用工具获取完整内容。
目前公开资料中，直接比较“安装 RTK”和“不安装 RTK，完成相同真实编程任务”的测试，以 JetBrains 的成对 A/B 基准测试最完整。在这组测试中，低推理强度的总成本不是下降，而是 增加 7.6% ；高推理强度为 +0.1%，基本持平。任务质量没有检测到显著差异。
因此，如果目标是减少测试日志、Git 差异、搜索结果等命令行输出进入上下文的体积，现有公开数据支持 RTK 在部分场景可以取得较高压缩率，尤其是日志和其他高输出命令。
如果目标是让完整 Claude Code 编程工作流减少 60%～90% 的 Token 消耗或费用，目前公开的真实任务 A/B 数据并不支持这个数字。
RTK 当前官方文档也已经把口径限定得更明确：最多减少 90% 的 Bash 输出，不代表账单减少 90%；rtk gain 的 Token 数字来自字节数除以 4 的估算，而不是模型供应商的真实计费 Token 。
从目前公开测试来看，RTK 更适合作为一个命令输出压缩工具来理解，而不是一个能够稳定让整个编程代理会话节省 60%～90% Token 的工具。
