首页用 Claude Code 跑一个中等规模的 TypeScript 或 Rust 项目，cargo test的完整输出约4800个 token，git status约2000个，ls -la约3200个。Agent实际需要的信息只是其中一小部分——测试过没过、有没有未提交的文件。剩下的全是噪声，但照样占你的配额。
Cursor有credits上限，Aider按token计费，Gemini CLI有每日请求次数。计费方式不同，账单变贵背后的原因是一样的：大量token被cargo test的样板输出、git status的branch提示、ls -la的权限列这些根本不需要AI读的东西塞满了。
下面三款工具分别从不同角度处理这个问题。
一、RTK（Rust Token Killer）
RTK干的事情很简单：拦截shell命令的输出，过滤掉噪声，再把压缩后的版本送给LLM。AI收到的内容完全一样有用，只是少了几千行废话。
rtk-ai/rtkRust 单二进制
100+ 命令支持
RTK在shell命令和AI Agent之间做代理，拦截命令输出后用四种策略压缩：过滤（去除注释、空白、样板信息）、分组（按目录聚合文件、按类型聚合错误）、截断、去重（重复日志折叠为计数）。压缩后的内容透明传给LLM，开发者不需要改任何操作习惯。支持Claude Code、Cursor、Gemini CLI、Codex、Windsurf、Cline、OpenCode等12款工具。
压缩效果
262个测试全部通过的cargo test，原始输出约4823个token，经过RTK只剩11个：
running 262 tests test cargo_cmd::tests::test_filter ... ok test cargo_cmd::tests::test_build ... ok ...（259行省略） test result: ok. 262 passed; 0 failed; 0 ignored Finished in 0.20s
262 passed. 0 failed. Finished in 0.20s
其他命令的实测数据：git status ↓80.8%，pytest 33个测试 ↓96.8%，grep扫描Rust代码库 ↓55.4%。平均压缩率89%来自2900+条真实命令的统计，不是理论值。有用户记录了数周内运行15,720条命令、节省1.38亿token的数据，Apple、Google、Meta等公司的工程师也在star列表里。
安装
# macOS brew install rtk-ai/tap/rtk # Linux / macOS 通用 curl -fsSL https://rtk-ai.app/install.sh | bash # 初始化。以Claude Code为例，其他工具改--gemini / --codex等 rtk init -g # 查看节省了多少 rtk gain
rtk init -g 会在AI工具的配置文件里注入一个PreToolUse hook，之后git status这类命令自动被重写成rtk git status，不用记任何新命令。另有rtk discover可以扫描历史会话，找出哪些命令绕过了RTK还可以进一步压缩。
二、LiteLLM
这个问题很多团队都遇到过：某个任务用GPT-4.1跑太贵，想换个便宜点的模型，但代码里已经到处是OpenAI SDK的调用，换一家就得重写一遍。LiteLLM做的就是在中间加一层，让所有模型看起来都是同一个接口。
BerriAI/litellmPython
40k Stars
统一接口调用OpenAI、Anthropic、Gemini、Bedrock、Azure、Mistral、Ollama等100+提供商。核心功能包括模型路由与故障转移、费用追踪与预算控制、负载均衡、响应缓存、虚拟Key管理。支持Python SDK直接使用，也可以部署为自托管代理服务器供团队共享。
用法
SDK层面，把原来的OpenAI调用换成LiteLLM的completion()，只改model参数就能切换提供商，其余代码不动：
from litellm import completion # 换模型只改这一行 response = completion( model="openai/gpt-4.1", # 或 "anthropic/claude-sonnet-4-..." messages=[{"role": "user", "content": "..."}] ) # 本地Ollama也一样 response = completion(model="ollama/qwen3:7b", messages=[...])
团队场景：Proxy Server
团队用的话更实用的是Proxy Server模式——启动一个自托管网关，给每个开发者或项目分配虚拟Key，设月度预算上限，超额自动限流。“这个月AI花了多少钱、谁用得最多”这类问题从此有数据可查。
# 一行启动 litellm --model gpt-4o # 或Docker docker run -p 4000:4000 ghcr.io/berriai/litellm:main-stable --model gpt-4o # 任何OpenAI兼容客户端指向本地即可 http://localhost:4000
三、oMLX
前两个工具都是在用云端模型的前提下省钱。oMLX走另一条路：M系列Mac在本地跑LLM，接口完全兼容OpenAI，Claude Code、Codex、OpenCode这类工具直接指过来就能用，不需要改任何配置。API费用直接归零。
本地跑LLM不是新鲜事，Ollama和LM Studio都能做。oMLX的差异在两点：速度和上下文持久化。
jundot/omlxApple Silicon 专属
活跃迭代中
基于Apple MLX框架，利用M系列芯片CPU和GPU共享统一内存的特性做零拷贝推理。核心设计是双层KV缓存：活跃上下文放内存，超出限制的部分写入SSD而不是丢弃。下次请求前缀匹配时从SSD恢复，耗时约1.7秒——服务器重启也不影响。
和 LM Studio 的实测差异
Better Stack用同一台MacBook Pro M2跑了个对比：让两个工具分别完成同一个全栈项目生成任务（React前端+Express后端）。oMLX约47 token/秒，LM Studio约16 token/秒，完成时间前者20分钟、后者35分钟。
另一个细节：LM Studio跑模型期间Mac开第二屏幕视频都卡，oMLX跑的时候机器正常用。famstack.dev的测试发现LM Studio界面显示57 token/秒，但由于前缀填充开销，实际有效吞吐只有约3 token/秒。同样的场景oMLX把预填充时间从49秒压到1.7秒。
| 维度 | oMLX | LM Studio | Ollama |
|---|---|---|---|
| 生成速度 | ~47 token/秒 | ~16 token/秒 | ~15-43 token/秒（视芯片） |
| KV缓存持久化 | ✓ 内存+SSD双层 | — 重启丢失 | — 重启丢失 |
| 前缀恢复时间 | ~1.7秒 | ~49秒 | 不支持 |
| 系统资源占用 | 轻量，Mac可正常使用 | 较重，影响其他任务 | 中等 |
| Apple专项优化 | ✓ MLX零拷贝统一内存 | 部分支持 | 2026年3月切换MLX中 |
| 管理方式 | 菜单栏原生App | 独立应用窗口 | CLI |
安装
# Homebrew brew tap jundot/omlx https://github.com/jundot/omlx brew install omlx brew services start omlx # 后台运行，崩溃自动重启 # 或直接下载DMG拖入Applications # 服务启动后暴露OpenAI兼容接口 http://localhost:8000/v1 # 接入Claude Code omlx launch claude
模型直接从Hugging Face下载，Admin Panel可以看实时推理速度和缓存命中率。非Apple Silicon暂不支持。
四、怎么选
| 工具 | 解决什么 | 适合谁 | 上手难度 |
|---|---|---|---|
| RTK | CLI输出噪声消耗token | 用任何AI编程工具、经常跑shell命令的开发者 | 一行命令搞定 |
| LiteLLM | 多模型切换成本高，费用不透明 | 需要对接多家模型的团队或个人开发者 | 需要配置路由规则 |
| oMLX | API按量计费、代码不想出境 | M系列Mac用户，跑量大或有隐私要求的场景 | GUI管理，零配置 |
三个工具可以叠着用：oMLX跑日常轻量推理，需要旗舰模型时通过LiteLLM切到云端，RTK负责压缩全程的CLI输出。组合起来之后AI编程的实际成本会低很多，上下文也能撑得更久。
