OptScale Kompressor 词元压缩把 AI 编程账单砍 22.7%

为什么账单会飙升？

写过 Codex CLI 或 GPT-5.5 的同学都知道，编程智能体把构建日志、编译器报错、测试堆栈一次性塞进上下文，动辄几十万词元。官方报道里提到，Terminal‑Bench 2.1 跑出来的数据显示，超 200000 词元的请求占比从 1.9% 降到 0.13% 才勉强能吃下折扣。没压缩前，账单按 token 计费，动不动就几百刀。

Kompressor 怎么把词元“压”下去

OptScale Kompressor 是 Hystax 放出的单 Rust 二进制，体积只有几 MB，零外部网络调用，1 KB 输出约 0.2 ms。它不改智能体任何一行代码，只在请求进模型前把上下文做一次确定性压缩，再把压缩后的标记喂给模型。压缩逻辑分四步：

按 format‑aware 识别代码块、日志行、堆栈帧等结构
把重复度高的机器输出（构建日志、编译报错）替换成带标签的占位符，保留 recoverable 标记以便后续还原
对剩余文本做逐字节的 deterministic 编码，保证同一输入每轮输出完全一致，满足 prompt caching 的逐轮一致性要求
若压缩后仍超限，触发 fail‑safe 直接截断最不重要的尾部，防止请求报错

四大原则让压缩不翻车

官方把这四条写成设计原则：

确定性：同一上下文、同一版本 Kompressor，输出逐字节一致，缓存命中率直接上去
可恢复：删除的段落换成 <kompressor‑tag>，后端随时能把原文拼回来，调试、审计零损失
格式感知：对 Markdown、JSON、堆栈帧分别走不同切分策略，不把代码缩进当垃圾删了
故障安全：极端情况下自动降级为硬截断，绝不抛异常让智能体挂掉

实测数字：账单砍 22.7% 的细节

在 Terminal-Bench 2.1 上，以 Headroom 默认 8.2% 压缩率为基准（激进档 11.6%），Kompressor 再省 15.8%，综合下来输入词元减少 25%，模型账单下降 22.7%。任务成功率从 82.2% 微降到 81.1%，基本在噪音范围。把 ML 训练评测任务单独跑，省 26%；从源码构建场景省 28%。这些数字都是 PR 里 CEO Nick Smirnov 亲自披露的，没做任何美化。

能不能直接上手？

克隆 GitHub 仓库，cargo build --release 拿到单二进制，丢进 PATH 里，给智能体加个前置 hook 就完事。MIT 许可证随便商用、改代码、打包进 Docker，完全没门槛。想白嫖更多额度的，直接把 Kompressor 接进现有 prompt caching 流水线，缓存命中率蹭蹭涨，账单再砍一刀。

本文来源：摸鱼杂货店。查看原文：OptScale Kompressor 词元压缩把 AI 编程账单砍 22.7%。