大模型上下文窗口的”压缩阀”：headroom能把输入token砍掉九成
AI编程代理每天要往大模型里塞多少数据？代码搜索结果、日志文件、RAG检索片段、对话历史——这些输入动辄数万token，既烧钱又拖慢推理速度。开源项目headroom要做的事情很简单：在数据到达大模型之前先压缩一遍，把token数量砍掉60%到95%，同时保证输出质量不下降。
项目由开发者chopratejas发起，目前在GitHub已获6300颗star，提供Python和TypeScript双语言支持，采用Apache 2.0许可证。它的定位是一个”上下文压缩层”（context compression layer），可以嵌入任何现有工作流。
六种压缩算法按内容类型自动路由
headroom内部有一个ContentRouter模块，会自动检测输入内容的类型，然后分配给不同的压缩器处理。
对于JSON数据，SmartCrusher负责处理数组和嵌套对象；代码类内容则交给CodeCompressor，它能解析Python、JS、Go、Rust、Java、C++的AST（抽象语法树）；普通文本和散文则由Kompress-base处理，这是项目团队训练并发布在HuggingFace上的专用压缩模型。此外还支持图片压缩（40%-90%缩减率）。
实际测试数据很有说服力。在代码搜索场景中，100条搜索结果从17,765个token压缩到1,408个，压缩率达92%；SRE故障调试日志从65,694个token压到5,118个，同样92%的压缩率。而在GSM8K数学推理基准上，压缩前后的准确率完全一致（0.870），TruthfulQA事实性测试甚至从0.530提升到0.560。
四种接入方式，从零代码到深度定制
项目提供了四种接入模式。最简单的是代理模式：一行命令headroom proxy --port 8787就能启动本地代理，无需改任何代码。其次是headroom wrap命令，可以直接包裹Claude Code、Cursor、Codex、Aider、Copilot等主流编程代理。对于需要精细控制的场景，可以用Python的compress(messages)或TypeScript的await compress(messages)作为库函数调用。最后还提供了MCP服务器模式，支持headroom_compress、headroom_retrieve等工具。
值得关注的是CCR（可逆压缩）机制。压缩后的原始数据不会被丢弃，而是存储在本地。当大模型需要完整信息时，可以通过headroom_retrieve按需取回。这解决了一个关键顾虑：压缩会不会丢失重要信息？答案是原始数据始终可追溯。
Token经济学里的真正赢家是开发者的账单
headroom解决的是一个被长期忽视的成本问题。多数人关注大模型的输出质量，却很少计算输入token的开销。当一个编程代理每天跑几十次任务，每次塞进去几万token，一个月下来API费用相当可观。把输入缩减90%，等于把这块成本砍掉九成，而且推理延迟也跟着降低。
不过要客观看到，headroom的压缩效果因场景而异。代码库探索这种复杂场景只能做到47%的压缩率，离宣传的”95%”差距不小。另外，整个压缩管道增加了系统复杂度，对于只使用单一模型且token用量不大的个人开发者来说，引入这一层可能得不偿失。
