深挖 · token 省钱工具横评：caveman vs headroom vs rtk

上一篇深挖 caveman 留下一个尾巴：GitHub 上比它更火的同类还有两个——headroom（~69k star）和 rtk（~78k star），而 token 账单的大头其实在输入侧（agent 流量 93.4% 是 input、仅 4.0% 是 output）。这篇横评回答四个问题：三工具各是什么、适合谁、是否互斥、以及在 ZCode + Claude Code + DSH + Pi 为主力的开发环境里到底该装哪个。

三兄弟各自的座位

把 agent 的 token 流想象成一条管线，三兄弟坐在不同的位置：

caveman（102.6k★，MIT skill + BSL proxy）——坐在出口。skill 是 ~5KB 纯 prompt 指令，让模型用电报式精简语作答，压的是模型输出的散文；proxy 再压输入侧 json/log。但编码 agent 场景的配对实测（JetBrains）：输出仅省 8.5%、整轮账单反而贵 11.6%。它的真实价值是回复可读性，不是省钱。

headroom（68.6k★，Apache-2.0）——坐在中间（agent ↔ API 之间）。本地上下文压缩层，四种形态（Python/TS 库、proxy、wrap、MCP server），pipeline 为 CacheAligner → ContentRouter → CCR 可逆压缩。三个压缩器分工明确：SmartCrusher 压 JSON（统计有损——按字段方差挑重要项，保 error/离群值，数组最多留 15 项）、CodeCompressor 压代码（tree-sitter AST，默认直通 0% 以保正确性）、Kompress-v2（本地 ONNX 小模型）压散文。官方 seeded benchmark：code search -21% / SRE 排障 -57% / 代码库探索 -42% / issue 分诊 -30%，可 --seed 复现，但无第三方独立复现；Reddit 口碑混合（“调了一周才稳定” vs 多实例 Claude Code 压在限额内）。

rtk（78.3k★，Apache-2.0，5 人团队）——坐在入口（agent 内侧）。Rust 单二进制，PreToolUse hook 把 Bash 命令透明改写为 rtk <cmd>（git status → rtk git status），过滤/分组/截断/去重，100+ 命令、<10ms 开销。关键限制：只作用于 Bash 工具调用，agent 内建 Read/Grep/Glob 完全绕过。官方数字 -60~90% 是 bash 输出口径（官方自己也承认"不等于账单省 90%"）；JetBrains 同一测试床实测：理论天花板仅 ~3% 输入 token（78% 的工具结果走内建工具绕过了 hook），低 effort 档每任务中位数反而贵 7.6%——rtk 期间自报"省了 96.2M tokens"而真实账单在涨，JetBrains 的判词是「诚实的工程，错误的反事实」。

适合场景

• caveman：聊天式问答、长解释类回复变短（win case 是单回合 1k+ token 的回复）；编码负载是个位数天花板。
• headroom：工具输出/JSON/日志占大头的输入侧压缩，多 agent 超长会话；对隐私敏感（beacon 默认开且 fail-open，需 HEADROOM_BEACON=off）。
• rtk：bash 重度工作流（CI 排障、测试日志分析）且 agent 用 hook 型集成；社区正面反馈集中在"延长限额"的体感。

还有一本反直觉的账要算：三者砍掉的主要是便宜的 cache_read token。codepointer 的实测会话里，账单被 cache_create（42%）+ output（29%）主导——这些工具"barely move a bill"。

是否互斥：座位模型

三层正交，架构上大部分组合可叠：

• prompt 层（caveman skill）× hook 层（rtk）× 代理层：互不碰面。
• 唯一互斥：caveman proxy 与 headroom 抢同一个 baseURL 座位，事实二选一，两家都没有串接文档。
• 历史包袱：headroom 曾把 rtk 内置（wrap 时自动下载 rtk 二进制并注册 hook），后在 REALIGNMENT 中整体移除（cache 热区风险 + 职责重叠）；headroom 官方反而欢迎挂 Caveman 的 MCP 形态。
• 实测背书：codepointer 把三件全开跑了 500 个真实会话回放——合计只省 3.7%（headroom 2.8% / rtk 0.5% / caveman 0.4%），且确认无双重压缩、缓存前缀仍命中。
• 一个真实的坑：Claude Code 项目级 .claude/settings.json 的 PreToolUse hook 会替换而非合并全局 hook——多 hook 工具共存时 rtk 可能静默消失。

我们的棋盘（ZCode + Claude Code + DSH + Pi）

适配矩阵按就绪度排：Pi > Claude Code > ZCode > DSH。

• Pi（badlogic/pi-mono）：三者就绪度最高——caveman 原生 wrap（bundled extension）、rtk plugin（TS extension）、headroom 可经 pi.registerProvider() 换 baseUrl 零障碍接入。
• Claude Code：三层全可用。skill 直装；rtk 是 PreToolUse hook 透明改写；headroom 是完整 wrap（还带 –memory/–code-graph 旗标）。
• ZCode：skill 层可用（SKILL.md 同构，本机 caveman 已实跑）；headroom 有专门 provider（headroom/providers/zcode/，读 v2/config.json 自动检测上游是 Anthropic 还是 OpenAI-compatible、支持自定义 baseURL）——但 ZCode 是 Electron 桌面应用无 CLI，走"起 proxy + 手动贴进 Settings > Model Settings"的半自动模式。rtk 零支持（仓库 571 个文件路径扫描零提及）。
• DSH（= DeepSeek Harness，dsh --help 第一行实锤）：三者均无官方接入。rtk 依赖宿主 hook 机制而 DSH 无公开 hook API；headroom 代理理论上可手动指 baseURL（“any OpenAI-compatible client”）但无 wrap；好在 DSH 生态自带 dsh-compressor（Headroom 的精简移植，官方称压工具输出 -20% 上下文）——不用外接。

还有一层信任成本：headroom 能看到你的 API key，rtk 可以执行任意命令，而 headroom wrap 曾经自动下载 rtk 二进制（供应链耦合——“a poisoned rtk release could arrive through headroom”）。

推荐结论

值不值得的排序和就绪度刚好相反：

1. 默认一个都不装。三件全开的真实回报是 ~3-4%，代价是三份信任面 + 一份运维复杂度。
2. 只装一个的话选 headroom：协议覆盖最全（Anthropic Messages + OpenAI Chat/Responses + Gemini/Vertex/Bedrock）、唯一正面处理 KV-cache（只压增量、旧前缀字节级转发保缓存命中）、Apache-2.0 无功能阉割。路径：在 Claude Code 上 headroom wrap claude 完整试跑两周，/stats 看自己真实流量的节省率，站得住再手动接到 ZCode。
3. rtk 跳过：主力环境里 ZCode、DSH 都不支持，唯一宿主 Claude Code 上有负收益实测。
4. caveman 只留 skill 层（可读性收益），proxy 座位让给 headroom。
5. DSH 用生态内的 dsh-compressor，不外接。
6. 最后说句实话：最大的省钱杠杆不在这三个工具里——官方 prompt caching（Anthropic cached input 打 1 折）、/compact、把 CLAUDE.md 控制在 200 行内，这些免费手段的确定性远高于任何第三方压缩层。

参考阅读

• codepointer: Cutting LLM token costs — 唯一的三工具同装分层实测（500 会话，合计 3.7%）
• JetBrains Part 1 (caveman) / Part 2 (rtk) — 同一测试床的配对 A/B 实测
• headroom repo — 四形态架构与官方 benchmark
• headroom limitations — 有损边界自述（值得读的诚实文档）
• rtk supported-agents 文档 — 16 个 agent 的接入机制全景
• headroom cache-optimization — KV-cache 经济学：为什么砍 cache_read 省不了多少
• pi custom-provider 文档 — Pi 的 baseUrl/协议配置
• 上一篇：深挖 · caveman — 本横评的前置