headroomlabs-ai/headroom

1. 基本情况

2. 主要用来干什么

把一切要进入 AI 的内容先压缩一遍再送进去——工具输出、日志、检索到的资料片段、文件内容，连对话历史都压。

它给的例子很直观：一段 10,144 个 token 的日志压成 1,260 个，而 AI 照样找出了里面那条 FATAL 错误。少花八分之七的钱，得到同一个答案。

有一点必须先说，因为它决定你敢不敢用：压缩过程在你自己的机器上完成，任何提示词和文件内容都不会被发到外面去。 这类"中间层"工具最容易让人担心的就是内容外流，它在 README 里明确排除了这一点。

它有四种用法，你按自己的情况挑：

除了压缩，还有三个功能值得单独提：

• 压缩是可逆的。原文在本地留有缓存，需要时能取回来。这一条很关键——压缩类工具最大的风险就是"万一 AI 恰好需要被压掉的那部分怎么办"，它给了退路。
• 输出也能省。它不只压你发过去的，还会削减模型写回来的内容——大多数同类只管前半截。
• 跨工具共享记忆。Claude、Codex、Gemini、Grok 共用一个存储，自动去重。
• headroom learn：从失败的会话里挖出教训，自动写进 CLAUDE.local.md（默认已加入 git 忽略）之类的规则文件。

关于它宣称的省多少，请注意读法：官方说的是编程场景省 20%、JSON 场景省 60–95%。这比同类喊的数字保守得多，但口径可能也更实在——见下一节。

3. 为什么会火

它戳中了什么痛点

用 AI 编程助手的人都在同时挨两刀：上下文窗口被垃圾塞满，以及为这些垃圾付钱。一条 npm test 吐出几百行、一个 JSON 接口返回几千行、检索出来的资料片段里 90% 用不上——这些全额进入上下文，全额计费。

Headroom 的定位比同类都宽：不只压命令输出，你发给模型的一切它都压——工具输出、日志、文件、检索片段、连对话历史都算。

为什么值得单独看它

三个设计上的选择，我认为都很关键：

1. 压缩在本机完成，内容不外发。 这类"夹在中间"的工具最让人不安的就是内容会不会被送去第三方，它明确排除了。
2. 可逆。 原文在本地留缓存，需要时能取回。这是对"压缩会不会丢关键信息"这个根本质疑的直接回答——同类里很少有人处理这一点。
3. 连模型写回来的内容也削。 大多数同类只管你发过去的那半截，但输出 token 通常比输入贵好几倍。

还有一个功能我没在别处见过：headroom learn 会从失败的会话里挖出教训，自动写进 CLAUDE.local.md 这类规则文件——相当于让你的 AI 从自己的错误里积累经验。

大家在夸什么 / 骂什么

我这次没有检索到关于它的成规模评测，好评差评都没有。 它 2026 年 1 月才建立，虽然星数不低，但深度使用者的公开反馈基本是空白。

别把"找不到差评"读成"没有问题"。 对这个项目我建议你保持一份额外的谨慎，因为它介入的位置很深——它同时改写你发出去的和收回来的内容。

但有一件事我要替它说句公道话

它官方宣称的数字是编程场景省 20%、JSON 场景省 60–95%。同类里有喊"省 60–90%"的。同样是压缩，差距这么大，只可能是测量口径不同。

而 Headroom 这个 20% 明显是更保守、更像真实场景的说法。在这个领域，敢把数字说小的，往往比喊得响的更可信。（这一点你实测时可以直接验证，见下一节。）

4. 同类还有谁，怎么选

headroom 和 rtk 是最直接的一对，值得单独比：

那两个数字的差距（20% vs 60–90%）几乎肯定是口径不同，而不是能力差三倍——rtk 说的是"命令输出被削掉多少"，headroom 说的是"编程场景整体省多少"。分母不一样。 这一点没有任何一篇评测澄清过，也是我建议你实测的第一件事。

什么时候该选它

• 你想一次性把所有输入都管起来，而且怕压缩丢信息 → 选 headroom。可逆这一条是它相对 rtk 最实质的优势：万一 AI 需要被压掉的那部分，还能取回来。
• 你的问题只是"跑个测试就把上下文塞满" → rtk 更专、更轻、装完不用管。如果 80% 的浪费来自命令输出，它就够了。
• 你在处理大量 JSON 接口返回 → headroom 明显更对症，那是它宣称收益最高的场景（60–95%）。
• 你要的其实是"记住上次聊了什么" → 那是 claude-mem 的活，压缩解决不了。
• 你还不知道钱花在哪 → 先用 claude-code-templates 看一周，没测量就优化最容易白忙。
• 两个可以叠加（rtk 管命令、headroom 管其他），但叠加后省多少没人测过。

一句话：rtk 是手术刀，headroom 是滤网。 前者更快更专，后者更全且给了后悔药。

你亲测时重点看这几点

1. 20% 还是 90%，自己测一次（最值得验）。同一段真实任务，裸跑、装 rtk、装 headroom 各跑一遍，记 token 数。 这一次实验能同时回答"两家谁更实在"和"到底省多少钱"两个问题——全网没有这个数据。
2. 可逆功能真的管用吗。故意制造一个"AI 需要看被压掉的内容"的场景，看它能不能自动取回原文。这是它相对 rtk 的核心卖点，必须验证是不是真的。
3. 压缩会不会让 AI 答错。这是所有压缩工具的根本风险。跑一个需要完整日志才能判断的任务，看结论会不会变。
4. headroom learn 写出来的东西有没有用。它会把"教训"自动写进你的规则文件——这个功能听起来很美，但写出来的到底是有用的经验还是噪音？ 用一周后打开那个文件看看，这个观察别人没做过。
5. 它这么新，稳不稳。2026 年 1 月才建立，介入位置又很深（同时改写发出和收回的内容）。跑一周看看有没有奇怪的失败——公开反馈几乎是空白，你的实测就是第一手资料。

5. 我的实测

还没有亲自试过这个工具。

客观数据来自 GitHub 接口，生成于 2026-09-07。判断部分仅供参考，动手前请以你自己的实测为准。