Headroom 宣传能省 60%～95% Token，真实会话能省多少？公开基准、独立 Agent 测试与社区实测整理
Headroom 是一个面向 AI Agent 的上下文压缩工具。它位于 Agent 与大模型之间，在日志、JSON、代码、工具返回结果和历史上下文进入模型前进行压缩，并提供 CCR（压缩---缓存---检索）机制保存原始内容。
项目公开宣传曾以"减少 60%～95% Token"为核心卖点。官方测试中，代码搜索和 SRE 日志场景达到 92%，代码库探索为 47%。问题在于，这些数字测量的是不同类型的上下文，不能直接等同于一次 Claude Code 或 Codex 完整开发任务的账单降幅。
目前已经出现几组公开的非官方测试，包括完整 LangGraph Agent 循环、独立本地调试会话，以及第三方 Claude Code 编程会话对照数据。
第三方 LangGraph Agent 完整流程测试
网页地址：github.com/shreyassks/...
shreyassks/headroom-benchmarks 在 2026 年 6 月公开了一套独立 Headroom 基准。测试使用 LangGraph ReAct Agent、MCP 服务和包含 2,500 行数据的 SQLite 数据集，模型为 MiniMax-M3。主测试包含 50 个案例，共产生 106 次真实 LLM 调用。
核心结果：
| 指标 | 不使用 Headroom | 使用 Headroom | 变化 |
|---|---|---|---|
| 测试案例 | 50 | 50 | --- |
| LLM 调用 | 106 | 106 | --- |
| 输入 Token | 189,365 | 105,769 | -44.15% |
| 按测试价格计算的成本 | $0.1355 | $0.0853 | -37.05% |
| 节省成本 | --- | $0.0502 | --- |
测试作者给出的主结论是：在这个完整 Agent 循环里，Headroom 将输入 Token 压缩了 44%，按 LiteLLM 列表价格计算，成本下降约 37%。搜索类任务贡献的绝对节省最多，多步骤任务则因为上下文不断累积，单次调用的压缩空间更大。
这套测试还复现了 GSM8K、SQuAD v2 和 BFCL，每项取 100 个样本：
| 基准测试 | 基准组 | Headroom | 输入 Token 变化 |
|---|---|---|---|
| GSM8K | 准确率 95.0% | 94.0% | 38,878 → 7,479，-80.8% |
| SQuAD v2 | EM 0.60 / F1 0.785 | EM 0.55 / F1 0.775 | 18,774 → 3,285，-82.5% |
| BFCL | 99.0% | 99.0% | 28,803 → 4,358，-84.9% |
| 三项合计 | --- | --- | 86,455 → 15,122，-82.5% |
质量并非所有测试都完全一致。GSM8K 准确率下降 1 个百分点；SQuAD v2 的 EM 从 0.60 降至 0.55，F1 从 0.785 降至 0.775；BFCL 保持 99%。
测试作者同时列出了限制。MiniMax-M3 的缓存会影响压缩路径，因此部分"输入 Token 节省率"混合了压缩和缓存效果；BFCL 使用字符串匹配判断答案，评分方式偏宽松；TruthfulQA 没有完成评分。该测试也没有真正驱动 Claude Code 在 GitHub 仓库中完成真实编码任务。
因此，这一来源测试的是完整 LangGraph Agent 工作流的输入 Token 和成本，以及标准数据集上的准确率变化，不是 Claude Code 修复真实软件问题的成功率测试。
Headroom 官方基准测试
网页地址：github.com/headroomlab...
Headroom 官方公开的主要工作负载数据如下：
| 官方场景 | 压缩前 | 压缩后 | 官方报告节省 |
|---|---|---|---|
| 代码搜索，100 个结果 | 17,765 | 1,408 | 92% |
| SRE 故障调试 | 65,694 | 5,118 | 92% |
| GitHub Issue 分类 | 54,174 | 14,761 | 73% |
| 代码库探索 | 78,502 | 41,254 | 47% |
官方同时使用每项 100 个样本进行质量测试。GSM8K 从 0.870 到 0.870；TruthfulQA 从 0.530 到 0.560；SQuAD v2 报告 97% 的结果保持率并压缩 19%；BFCL 报告 97% 并压缩 32%。
官方给出的结论是，Headroom 可以根据内容类型压缩工具输出、日志、代码等上下文，并通过 CCR 保存原始数据，需要时再由 Agent 检索。官方宣传口径为减少 60%～95% Token，同时保持答案质量。
独立开发者本地实测：代码、JSON、日志和完整调试会话
网页地址：miyagadget.page/en/blog/202...
Miya-Gadget 在 2026 年 6 月安装 headroom-ai 0.22.3 后进行了独立测试。测试使用 Apple Silicon Mac、Python 3.11 和 Headroom 默认配置，分别准备代码、JSON、日志和自然语言 RAG 文档，并以 Agent 的工具返回结果形式输入。
不同内容类型得到的结果差异较大：
| 数据类型 | 压缩前 | 压缩后 | Token 减少 |
|---|---|---|---|
| 代码 | 877 | 177 | 79.8% |
| JSON | 33,485 | 13,676 | 59.2% |
| 日志 | 25,423 | 17,548 | 31.0% |
| RAG 自然语言文档 | 11,818 | 11,818 | 0% |
代码的压缩率最高，JSON 接近 60%，日志为 31%。自然语言 RAG 文档在默认配置下没有被压缩，因为 Headroom 默认保护这类内容。
作者随后模拟了一次多工具调试会话：超时增加、查看日志、检查 API 状态、检查代码并定位原因。
完整会话从 59,742 Token 降到 31,358 Token，减少 47.5%，约少发送 28,000 Token。
作者还检查了压缩后的关键信息。日志中的 TimeoutError 被保留，JSON 中指定用户的 email 被保留；代码被转换成压缩表示，但原文可以通过 CCR 重新获取。这里的质量验证主要检查关键信息是否还存在，没有让两个 Agent 分别完成同一个软件修复任务并比较最终补丁。
代理模式也没有在作者环境中完成真正的端到端 API 转发验证。作者明确记录，代理没有成功监听端口，因此文章中的压缩率主要来自 Headroom Library 模式。
作者最终总结的数据是：代码减少 79.8%，JSON 减少 59.2%，日志减少 31%，完整模拟调试会话减少 47.5%，自然语言默认不压缩。
社区独立对照：真实 Coding Session 中 Headroom 减少 15% Token
网页地址：www.reddit.com/r/ClaudeAI/...
2026 年 7 月，一名开发者在 Reddit 公布自己的上下文压缩代理，并把 Headroom 作为对照工具，在其所称的"真实 coding sessions"中进行测试。
公开结果为：
| 工具 | 输入 Token 减少 | 成本减少 |
|---|---|---|
| 该作者自己的代理 | 54% | 37% |
| Headroom | 15% | 14% |
在这组会话中，Headroom 的完整会话输入 Token 降幅为 15%，对应成本下降 14%。
这个来源需要保留其背景信息：测试作者同时是另一个上下文压缩项目的开发者。帖子给出了 Headroom 的对照数字和可运行代码，但没有像 headroom-benchmarks 那样在正文中公布测试案例数量、任务成功率或统计显著性，因此不能把这组 15% 与 44.15%、47.5% 直接视为同一测试口径。
它测量的是真实 Coding Session 中的完整输入 Token 和成本变化，而不是单条 JSON、日志或代码块的局部压缩率。
GitHub Issue 数据复核：Claude Code 缓存前缀曾导致开发版几乎不压缩
网页地址：github.com/headroomlab...
2026 年 6 月 27 日，Headroom GitHub Issue #1487 报告了一个 Anthropic 路径上的回归问题。
Issue 记录，在 v0.27.0 之后的 main 分支中，当默认启用 ccr_inject_tool，带冻结缓存前缀的轮次不会再进行压缩。报告者指出，持续运行的 Claude Code 会话基本都会携带冻结前缀，因此该开发版本在普通使用中可能"几乎不压缩"。
同时，Issue 明确写明这个问题没有进入已经发布的 v0.27.0，只存在于当时尚未发布的 0.28.0 开发线上。Issue 后续已经关闭。
这一记录没有提供完整会话的 Token 节省百分比，但说明 Headroom 在 Claude Code 中的实际压缩效果还会受缓存前缀处理逻辑影响，不能只根据单个压缩算法的压缩率推算最终会话 Token。
后续测量口径说明：同一天数据可以得到 15%、38% 或 87%
网页地址：extraheadroom.com/blog/token-...
Headroom 的桌面产品由 Garm Tech 开发，并明确说明其底层由开源 Headroom 提供支持。2026 年 8 月，团队专门发布文章解释 Token 节省百分比的统计口径。
作者使用自己一天的 Claude Code 和 ChatGPT 实际流量进行统计。按照 API 列表价格换算，如果不进行 Headroom 压缩，当天输入成本约为 693 美元 ；Headroom 删除的输入对应 101 美元 ，压缩后的实际等价输入成本约为 592 美元。
同一批数据可以得到三种百分比：
| 统计口径 | 计算 | 结果 |
|---|---|---|
| 相对全部输入成本 | 101÷693 | 15% |
| 相对非缓存读取输入 | 101÷266 | 38% |
| 把模型提供商缓存折扣也算成节省 | ( 3,843+101) ÷ ( 3,843+693) | 87% |
当天约有 427 美元的输入成本来自缓存读取。作者指出，这部分缓存读取不是压缩器自己产生的节省，因此 Headroom 后续界面选择报告第二种口径，即只统计 Headroom 可以作用的"非缓存读取输入"。
这一天共有 3,284 个请求进行了压缩 ，单请求压缩率的中位数为 20% 。较大的压缩主要集中在长上下文请求，其中积累了工具输出、文件读取和搜索结果。
后续文档进一步明确，Headroom 的输入节省率不再把缓存读取计入自身成果；输出 Token 节省则单独标记为估算值，而不是与输入压缩的实测数字混合。
这套桌面产品当前页面也把完整 Agent 编程会话的预期值写成约 40%～50% ，同时仍保留代码搜索 92%、SRE 调试 92%、Issue 分类 73%、代码库探索 47% 等局部场景数据，并注明实际结果取决于工作负载。
总结
现有非官方公开数据支持 Headroom 对输入上下文进行实质压缩，但不同工作负载之间差距很大。
目前最完整的独立 LangGraph Agent 测试包含 50 个案例和 106 次 LLM 调用，输入 Token 从 189,365 降到 105,769，减少 44.15% ；按该测试价格计算，成本下降 37.05% 。这是当前公开数据里较完整的一组 Agent 循环测试。
Miya-Gadget 的独立调试会话从 59,742 Token 降到 31,358，减少 47.5% 。但拆开不同内容后，代码为 79.8%，JSON 为 59.2%，日志只有 31%，自然语言 RAG 文档为 0%。Headroom 的效果与上下文类型直接相关。
另一组社区真实 Coding Session 对照中，Headroom 只减少了 15% 输入 Token和14%成本。该测试信息没有前两组完整，但它提供了一个更低的完整开发会话结果。
因此，目前公开的完整工作流或真实会话数据大致出现了 15%～47.5% 的输入/上下文 Token 降幅 ，已公开的成本测试则出现 14%～37.05% 的下降。由于模型、任务和成本计算方式不同，这些数字不能直接求平均，也不能视为 Headroom 的固定节省率。
60%～95% 的压缩率在代码搜索、重复日志、JSON 等高冗余内容上有公开测试能够达到或接近；现有完整 Agent 工作流和 Coding Session 数据还不足以支持"安装 Headroom 后整个 Claude Code 开发任务稳定减少 60%～95% Token"这一解释。
质量方面的数据也不是绝对零损失。第三方标准测试中，GSM8K 从 95% 降至 94%，SQuAD v2 的 EM 从 0.60 降至 0.55、F1 从 0.785 降至 0.775；BFCL 保持 99%，但测试作者自己指出其评分较宽松。
从已经公开的独立数据看，Headroom 更接近一个对大型工具输出、JSON、日志和不断累积的 Agent 上下文进行压缩的工具。在这类输入占比较高时，完整工作流已有约四成至接近五成 Token 降幅的公开结果；当可压缩内容占比较低，或者完整会话主要成本来自其他上下文与缓存读取时，最终账单降幅可以低得多。