AI编程Token节省利器：RTK让Claude Code/Codex/Cursor成本直降80%

在日常开发中，当你使用 Claude Code 重构 yudao-cloud 的某个核心模块并执行mvn deploy命令时：

整整 200 多行的输出被原封不动塞进 Claude Code 的上下文窗口，但真正有用的可能就两行：BUILD SUCCESS、以及末尾的 WARNING。

这样的场景每天重复发生，主要集中在以下 4 类情况：

将这些未经处理的原始输出全部发送给 AI——每月的 token 消耗就是这样累积起来的。

RTK（Rust Token Killer）是一款运行在本地机器上的CLI 代理工具：拦截 Claude Code / Codex / Cursor 执行的命令输出，通过 4 层压缩策略将其精简后再返回给 AI。官方 README 标注的节省比例达到 60-90%——某次 30 分钟的 Claude Code 会话，11.8 万 tokens 被压缩至 2.39 万。

项目地址：https://github.com/rtk-ai/rtk

最令人惊叹的是其 Star 增长速度——半年前文章中记录的数据还是 16.3k，截至本文发布已攀升至 45.3k——3 倍的增速，说明社区在用实际行动投票。

其设计理念用一句话概括：*"Single Rust binary, 100+ supported commands, <10ms overhead"* —— 单一 Rust 二进制文件、支持 100+ 命令、单次调用开销 <10ms。选择 Rust 实现就是为了追求速度，每次拦截都不能拖慢你的开发流程。

以下 4 个策略名称沿用官方 README 的英文原文——属于客观陈述，未做二次创作。

"Removes extraneous content like comments and whitespace."— 官方 README

专门清除注释、空行、模板化的样板代码。Maven 输出中的[INFO] Downloaded from central:...这类行毫无信息量，全部删除；测试输出中的大段OKOKOK收敛为一行。

"Consolidates similar items (files by directory, errors by type)."— 官方 README

按维度聚合相似项。当mvn test报错时，如果 10 个文件中出现同一个 NullPointerException——RTK 会按异常类型聚合成一条，Claude Code 看到的是「在 10 个 service 中出现相同的 NPE」，而不是 10 段重复的堆栈跟踪。

"Preserves relevant context while eliminating redundancy."— 官方 README

保留与当前任务相关的内容，删除冗余部分。tree -L 3列出了 5000 个文件，但 AI 本次只关注yudao-module-system子目录——RTK 智能保留这部分 + 裁剪无关分支。

"Collapses repeated log entries with occurrence counts."— 官方 README

重复的日志合并为一条 + 显示出现次数。Pod 启动时的Connection to Nacos established、Registering as health endpoint、Listening on 8080这类每个 Pod 都会输出的样板日志——合并为一条带计数的信息，token 直接节省 90%。

我使用 https://github.com/YunaiV/yudao-cloud 进行了 4 个高频场景测试，前后对比呈现数量级差异：

如果存在失败的 case：RTK 不会粗暴删除——它保留所有失败项的完整堆栈跟踪，但将成功的 412 个收敛为一条。

月度对比：日常每天使用 Claude Code 4 小时——月度 token 账单从 降至 40 左右。打开 yudao-cloud 这种多模块大型项目，节省效果更为显著。

RTK 的核心定位：不是让你更换模型或工具，而是在你现有工作流前面增加一层压缩——AI 客户端不变、模型不变、工作方式不变，只是输出在送达 AI 前先经过精简处理。

按推荐度排序：

安装后自动在 Bash 中挂载 hook——无需修改任何 Claude Code / Cursor 配置，命令执行时会自动经过 RTK 这一层。完全透明无感。

验证安装是否成功：运行rtk doctor会列出当前已接管的命令、压缩比例统计、性能开销等信息。

按 README 的完整清单：

11 款主流 CLI Agent 基本全覆盖——无论你的团队选择哪一款，RTK 都能作为压缩层介入。

Token 节省这个领域这两年方案众多——但 RTK 走的路线最为聪明：它不要求你改变使用习惯。

适合使用的几种情况：

不太建议入坑的几种情况：

归根结底：Token 焦虑的本质是信息密度问题——你发送的每个请求中夹杂了 90% 的噪音、AI 不需要、你也不需要看，白白消耗的费用。RTK 这种"在工作流前加压缩层"的思路，未来一年很可能成为 Agent 的标配组件——这条路走对了。

项目仓库：https://github.com/rtk-ai/rtk