Claude Code/Codex/OpenCode 成本神器诞生,Token 节省 80%!
AI 编程助手的 token 消耗,很大一部分是被“命令输出噪音”吃掉的。省钱:80-90% 的 token 节省,按当前模型定价算,回本很快无感:安装配置一次,之后全自动,不影响原有工作流聚焦:只做一件事,不做大而全的功能堆砌适合用的场景重度使用 Claude Code、Cursor 等 AI 编程工具频繁执行测试、构建、git 操作token 消耗是真实痛点(无论是成本还是上下文上限)不太需要
你有没有算过一笔账:用 Claude Code 或 Cursor 一整天,到底消耗了多少 token?
我之前没算过,直到有一天收到账单才发现不对劲。明明只做了几个简单功能,token 消耗却高得离谱。后来排查才发现,真正的“凶手”不是我的代码,而是那些命令输出。
npm install 跑一次,依赖树打印几百行;cargo test 执行完,99% 的通过信息全是绿的;git status 列出一堆 untracked 文件……这些内容全被塞进 LLM 的上下文窗口,而 AI 真正需要的信息可能只有 5% 左右。
RTK(Rust Token Killer) 就是来解决这个问题的。它是个 CLI 代理,在命令输出到达 LLM 之前先做压缩过滤——把“噪音”去掉,只留“信号”。

RTK 是什么?
RTK 是一个用 Rust 编写的命令行代理工具,专门为 AI 编程助手设计。它的工作位置很巧妙:不是替代你的命令,而是“拦截”命令的输出,在送给 LLM 之前做一轮智能压缩。

官方实测数据:30 分钟的 Claude Code 会话,token 从 118,000 压到 23,900,省了 80%。
它的技术特点:
|
特性 |
数据 |
|---|---|
|
启动延迟 |
<10ms |
|
内存占用 |
<5MB |
|
依赖 |
零依赖,单一二进制文件 |
|
语言 |
Rust(这也是它名字的来源) |
因为是用 Rust 写的,启动和执行都非常快,几乎感觉不到它的存在。你照常用 Claude Code,照常执行命令,只是 token 消耗悄悄降下来了。
为什么能省这么多?
RTK 的核心是四种压缩策略,针对不同类型的命令输出做针对性处理。
1. 智能过滤
这是最基础的一层。它会把输出里的“无效信息”识别出来并删掉:
-
注释和空白行:代码里的注释、多余的空行
-
进度条和动画:
npm install时的旋转光标、百分比进度 -
颜色控制字符:终端输出的 ANSI 颜色码(LLM 根本不需要这些)
举个例子,git push 的原始输出可能有 15 行约 200 token,里面包含远程仓库信息、对象计数、压缩进度等。经过 RTK 过滤后,可能只剩一行 ok main,约 10 token。
2. 分组聚合
当输出包含大量同类信息时,RTK 会把它们聚合成更紧凑的形式。
比如 ls 列出 100 个文件,原始输出是 100 行。RTK 会按目录或类型分组,输出变成“src/ 目录下 45 个 .java 文件”、“test/ 目录下 20 个 .java 文件”这样的摘要。
实测数据:ls / tree 类命令,2000 → 400 token,省 80%。
3. 截断保留
对于长输出,RTK 会智能截断,但保留关键部分。
比如测试失败时,它不会把所有通过的测试用例都列出来,而是:
-
保留失败的测试详情
-
保留错误堆栈
-
通过的测试只显示摘要:"95 tests passed"
实测数据:cargo test / npm test 类命令,25000 → 2500 token,省 90%。
4. 去重合并
很多命令会有重复的输出模式,比如构建日志里反复出现的 "Compiling..."、容器日志里的时间戳前缀。RTK 会识别这些重复模式,合并成一行。
支持哪些命令?
RTK 目前支持 30+ 命令,覆盖大部分日常开发场景:
|
类别 |
支持的命令 |
|---|---|
| 文件类 |
ls、read、find、grep、cat、tree |
| Git 类 |
status、log、diff、push、pull |
| 测试类 |
cargo test、npm test、pytest、go test |
| 构建类 |
cargo build、tsc、eslint、ruff |
| 容器类 |
docker ps、docker logs、kubectl pods |
基本上,你用 AI 编程助手时频繁执行的命令,RTK 都能处理。
怎么用?
安装非常简单,两种方式任选。
方式一:Homebrew(推荐)
brew install rtk
方式二:curl 脚本
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
安装完成后验证:
rtk --version
配合 Claude Code/Codex/OpenCode 使用
只需要执行一次初始化:
# Claude Code
rtk init -g
# Codex
rtk init -g --codex
# OpenCode
rtk init -g --opencode
-g 表示全局配置,之后你在任何目录启动 Claude Code/Codex/OpenCode,RTK 都会自动接管命令输出。

重启 Claude Code/Codex/OpenCode,就生效了。之后你执行的命令会自动被 RTK 压缩过滤,完全无感。
Cursor、Windsurf 等 AI 编程 IDE 也是适用的,甚至 OpenClaw 都能用。
# Cursor
rtk init -g --agent cursor
# Windsurf
rtk init --agent windsurf
# OpenClaw
openclaw plugins install ./openclaw
如果要卸载的话,也是一行命令即可:
rtk init -g --uninstall
省了多少?
各类命令的压缩效果
|
命令类型 |
原始 Token |
压缩后 |
节省比例 |
|---|---|---|---|
|
ls / tree |
2000 |
400 |
80% |
|
cat / read |
40000 |
12000 |
70% |
|
git status |
3000 |
600 |
80% |
|
cargo test / npm test |
25000 |
2500 |
90% |
查看节省统计
RTK 提供了一个命令查看 token 节省情况:
rtk gain

加上 --graph 参数还能看 30 天趋势图:
rtk gain --graph
加上 --daily/--weekly/--monthly 还能按天/周/月查看。

有用户反馈在 Claude Code 上节省了 10M token(89%)。按当前 Claude 的定价算,这是一笔不小的费用。

与其他方案对比
RTK 不是唯一能省 token 的方案,但它解决的问题很聚焦。来看看几个常见方案的对比:
|
方案 |
原理 |
效果 |
适用场景 |
|---|---|---|---|
| RTK |
压缩命令输出 |
最高 90% |
频繁执行终端命令的场景 |
| tokf |
类似的 CLI 过滤器 |
~90% |
与 RTK 类似,功能稍少 |
| .claudeignore |
排除特定文件/目录 |
视项目而定 |
减少不必要文件进入上下文 |
| Compact Mode |
Claude Code 内置压缩 |
30-50% |
探索阶段,快速浏览代码 |
| PTC |
私有工具调用,中间结果不进入上下文 |
视使用频率 |
复杂任务链,减少中间态 |
怎么选?
-
如果你主要用 AI 执行终端命令(测试、构建、git 操作),RTK 或 tokf 是首选
-
如果你想减少代码文件进入上下文,用 .claudeignore
-
如果你在探索阶段想快速浏览,开 Compact Mode
-
这些方案可以叠加使用
有什么局限性?
任何工具都有边界,RTK 也不例外。
1. 信息丢失风险
压缩的本质是“删减”,某些场景下可能会删掉你真正需要的信息。
比如调试一个偶发的测试失败,你可能需要看到完整的测试输出,而不是被压缩后的摘要。
2. 非标准命令支持有限
RTK 内置了对常见命令的解析规则,但对于一些非标准格式、自定义脚本的输出,压缩效果可能不如预期。
总结
RTK 解决的问题很小众但很真实:AI 编程助手的 token 消耗,很大一部分是被“命令输出噪音”吃掉的。

它的价值在于:
-
省钱:80-90% 的 token 节省,按当前模型定价算,回本很快
-
无感:安装配置一次,之后全自动,不影响原有工作流
-
聚焦:只做一件事,不做大而全的功能堆砌
适合用的场景:
-
重度使用 Claude Code、Cursor 等 AI 编程工具
-
频繁执行测试、构建、git 操作
-
token 消耗是真实痛点(无论是成本还是上下文上限)
不太需要的场景:
-
偶尔用 AI 写点代码,token 消耗本来就低
-
主要用 AI 做代码解释、文档生成,很少执行命令
-
已经通过其他方式把 token 消耗控制在合理范围
如果你属于前者,RTK 值得一试。30 秒安装,效果立竿见影。
项目地址:https://github.com/rtk-ai/rtk
最后
从0到1!大模型(LLM)最全学习路线图,建议收藏!
想入门大模型(LLM)却不知道从哪开始? 我根据最新的技术栈和我自己的经历&理解,帮大家整理了一份LLM学习路线图,涵盖从理论基础到落地应用的全流程!拒绝焦虑,按图索骥~~
因篇幅有限,仅展示部分资料,需要点击下方链接即可前往获取