ranxianglei/billion-context

解决什么问题

编程 Agent 的会话越久，历史越长。每次请求都要重放一大段前缀，token 费用持续叠加；一旦超出窗口，会话要么退化成粗暴截断摘要，要么直接中断。billion-context 以代理形式插在 Agent 和模型 API 之间，改写信流，把已经消费过的对话折叠成分层摘要，而不是直接丢掉。

有什么不同

常见做法是宿主自带的摘要器（单向、有损），或者干脆换一个更大的上下文窗口。billion-context 走增量分层压缩，并给模型提供 decompress 和 search_context 工具，需要精确细节时可以把压缩区间还原回来。另一个关键点是前缀缓存友好——README 称命中率能维持在 95–97%、压缩本身开销 ≤2%。这一点很重要：随意改写前缀会让上游缓存失效，省下的 token 又从缓存上还回去。它声称通过一个代理兼容 Claude Code、Codex、Gemini CLI、OpenCode、aider 等一长串客户端，而不是给每个客户端单独写插件。

适合谁

适合动辄跑几天连续会话的 Agent 用户，以及按 token 计费、想用一条长会话代替多次短会话的团队。如果你被限制在 100K 左右窗口的模型上，也值得看。不适合无法修改 base URL 的封闭 IDE 助手用户；会话本来就很短、离窗口上限很远的人用它只会多一跳代理，没有任何收益。

上手成本

需要 Node/npm（npm install -g billion-context --prefix=~/.local），然后把 Agent 的 base URL 指向代理，或走 bili 启动器/插件方式接入列出的客户端。代价是你在每次模型调用里插入了一个中间人：切换模型、上游缓存 TTL 过期都会变成故障源，README 自己也把这两条列为缓存命中率下降的首要原因。License 显示为 NOASSERTION，内部落地前先确认实际条款。压缩质量依赖模型遵守注入的工具指令，弱模型产出的摘要会明显更差。

点评

项目仅 79 天，2,597 star，一周涨了 937 个、冲上 TypeScript 周榜第 13——这是早期项目赶上真实涨势，而非成熟工具。附带的论文规模不小（长时间纵向研究），对一个这么年轻的项目来说很难得，但属于自发布，行为细节仍以 README 为准。思路是对的，痛点也是真的；风险在于它卡在整条链路最敏感的 API 位置。建议先在副项目里开着 /acp-cache 跑一跑，再考虑放进正式工作流。