一个会话跑一个月、还省一半 token：billion-context 的压缩账

长会话最贵的部分不是模型变笨，是你每轮都在为同一段历史重复付钱。billion-context 是今天 GitHub 日榜上的一个上下文压缩插件，思路很直接：它坐在 agent 和模型 API 中间，历史变长时由模型自己决定把旧消息折叠成摘要，需要时再展开或搜索找回来，摘要写在小段里，缓存前缀不断。

它支持的客户端很广：Claude Code、Codex、Gemini CLI、Qwen Code、opencode、Kimi Code 等 17 个以上，一句 npm install -g billion-context 装好，bili claude 这样启动就行。代理会往对话里注入四个工具：compress 折叠、decompress 展开、search_context 搜摘要、acp_status 看用量。

数字要分两档看。标题里那个“省 5 倍 token”是作者自己的说法。真正能拿出来的，是 README 里引的第三方 1,500 项交叉评测：ContextBench 第一名，成本比全量上下文低 58.3%；LongMemEval-S 上比最好的 RAG 高 16.6%，成本低 71.1%；1.48M token 的 MemoryAgentBench 全程存活，稳态压缩 30 倍，而全量上下文 199 个用例全挂。同一份材料里还有一篇论文：一组 4.5 个月、17.4 万次调用的纵向实验，累计输入 187.6 亿 token，零窗口越界，最长的单会话跑了 1.2 万次调用。

但有两处提醒必须写在前面。第一，部分客户端走的是证书中间人模式：代理要解密你的模型流量才能压缩，等于把代码和提示词交给一个本地代理——个人项目没问题，公司网关或涉密代码先问清楚合规再装。第二，原生插件和独立扩展只能二选一，同时开会重复压缩，README 自己写了这个坑。

结论在什么情况下不成立：如果你的会话本来就短，装它纯属多一个环节；如果你的会话动不动就跑满上下文、每个月 token 账单肉眼可见，这才是它该待的地方。省钱的办法不是换更便宜的模型，是别为同一段历史付两次钱。