billion-context:用100K上下文支撑5倍省Token的长会话压缩插件
给长时间AI编码会话压缩上下文的bili插件,100K窗口也能跑数十亿Token,且摘要可逆并保留缓存前缀。
GitHub ranxianglei/billion-context 更新 2026-10-11 分支 master 星标 782 分叉 74
TypeScript JavaScript Python SMT 上下文压缩 Token成本 bili pi OpenCode Linux/macOS/Windows

🧭 决策指南

适合,如果你

  • 你用pi、OpenCode或dsh进行数天级编码会话,并受100K上下文限制。
    README的Why和核心描述写明可用100K上下文支撑days、month-long sessions及billions of tokens。
  • 你希望原生接入客户端,不改URL、不设置环境变量,也不占用固定8787端口。
    README的Option 1说明原生插件无需launcher、环境变量、固定端口或URL编辑;bili start手动占用8787。
  • 你使用OpenCode并能把compaction.auto设为false,避免原生压缩与billion-context叠加。
    README的OpenCode说明要求设置"compaction": { "auto": false },否则会double-compress。
  • 你需要查看缓存健康度,并能依据95–97%命中率和/acp或/acp-cache排查会话。
    README的Cache health at a glance给出95–97% prefix-cache命中率及/acp、/acp-cache诊断入口。

不适合,如果你

  • 你必须同时保留原生插件和billion-context-pi或opencode-acp两个独立扩展。
    README明确说明Native mode与billion-context-pi、opencode-acp mutually exclusive,安装器会替换配置。
  • 你使用codex但不能先启动bili,也不能自行设置HTTPS_PROXY。
    README的codex说明要求先运行bili start或客户端lane proxy;完整压缩还需要自行export HTTPS_PROXY。
  • 你准备从Git checkout直接安装dsh或OpenCode插件,而不是使用npm发布包。
    README指出dsh和OpenCode的git checkout没有published entry,dsh还会因缺少dist/而无法加载bundle。
  • 你只接受README明确列出的MIT等标准许可证,但项目元数据仅标为Other。
    项目基础信息中的许可协议为Other;提供材料没有给出完整许可证文本。

前置条件

  • 需要npm;README给出的安装命令是npm install -g billion-context --prefix=~/.local。
  • Linux/macOS推荐使用~/.local用户级prefix;Windows默认使用%APPDATA%\npm,均避免sudo。
  • 原生插件支持pi、omp、OpenCode 1.x/2.x、dsh、kimi、hermes和zcode。
  • dsh和OpenCode的原生安装要求npm发布形式;Git checkout没有published entry。
  • codex需要bili代理可达;完整压缩还需要自行设置HTTPS_PROXY。

第一步命令(README 原文)

npm install -g billion-context --prefix=~/.local

要注意

  • 安装原生插件会替换独立扩展配置,原配置快照保存在.bili-bak。
    README的Native mode说明写明installer swaps entries and snapshots the original config。
  • pi原生安装默认启用acp_delegate、acp_delegate_wait和acp_delegate_cancel子代理。
    README的pi说明列出这三个built-in subagents,并另有禁用说明章节。
  • OpenCode配置不关闭auto-compaction会发生double-compress。
    README的OpenCode原生安装说明明确要求设置compaction.auto为false。
  • codex的MCP工具依赖可用代理;无可达实例时tools/list失败并返回-32003。
    README的codex说明列出BILI_MCP_PROXY、live-instance record、8787默认值及-32003错误。
  • 手动bili start使用8787,自动lane从18787区域起步并在冲突时递增。
    README的Ports说明明确区分8787 user zone与18787 self-managed zone。

替代方案

  • 主机内置summarizer:你只需要客户端自带的摘要功能,不需要billion-context的增量、可逆和prefix-cache机制。
    Why
  • billion-context-pi:你已经采用pi的独立in-process extension,并且不准备切换到bili native mode。
    Option 1 — Native plugin
  • opencode-acp:你已经采用OpenCode的独立in-process extension,并且需要保留该配置路径。
    Option 1 — Native plugin

材料未说明

  • README节选没有说明支持的Node.js具体版本。
  • README节选没有给出不同模型提供商、模型名称及其压缩质量差异。
  • README节选没有提供压缩前后真实Token成本、延迟和吞吐基准。
  • README节选没有说明运行代理所需的CPU、内存和磁盘规模。
  • 项目许可元数据为Other,但提供材料没有给出完整许可证条款及其限制。
  • README节选没有说明Windows上的完整安装、代理和客户端覆盖范围。
  • 材料没有说明782颗星、weekly Trending上榜与具体功能、发布版本之间的因果关系。

💡 深度解析

6
不适合 我使用 100K 上下文模型进行数天调试,并依赖子代理继承父会话;项目宣称 5 倍 Token 节省和 95–97% 缓存命中率,我能否把这些数字当作预算依据?
适合读者: 在 100K 上下文模型上运行长时间调试和子代理协作、关注前缀缓存命中率与 Token 成本的 AI 代理重度用户

不适合把 5 倍节省或 95–97% 命中率当作预算保证;它们可作为项目目标或健康指标,但实际结果依赖模型、缓存和会话内容。

  • README 的产品描述写有“5× fewer tokens”,缓存章节则把 95–97% 定义为健康会话的前缀缓存命中率,并说明压缩本身成本不超过 2%。
  • README 同时列出上游缓存 TTL 过期、模型切换和 bili bug 等命中率下降原因,因此数字不是独立于环境的固定 SLA。
  • 项目支持派生子会话继承父会话的压缩上下文,适合子代理协作,但继承后的信息完整度仍受摘要影响。
  • 长期会话依赖增量、分层和可逆压缩;项目也明确不能突破模型或提供商的单次请求上下文上限。

可以把这些数字用于理解设计目标,却不能直接换算成你的账单或调试质量。尤其是完整日志、精确工具输出和不可概括状态可能在压缩后不可始终可见。

  • README「# billion-context」:5× fewer tokens
  • README「Cache health at a glance」:healthy session keeps a 95–97% prefix-cache hit rate;compression itself costs ≤2%
  • README「Cache health at a glance」:usual causes include upstream cache TTL expiry、model switch、a bili bug
  • README「Derived (child) sessions inherit the parent's compressed context」
  • 项目洞察「usage_limitations」:不能突破模型或提供商的单次请求上下文上限
材料未说明:README 未提供不同模型、不同提供商或不同任务类型下的真实 Token 节省分布。;未给出子代理继承压缩上下文后的准确率、额外延迟或缓存命中率数据。;未说明 `/acp` 与 `/acp-cache` 输出的具体字段和可自动化采集格式。
适合 我同时使用 pi、omp 和 OpenCode 1.x/2.x 做大型重构,希望把数月级会话控制在 100K 上下文内;billion-context 是否适合直接接入?
适合读者: 使用 pi、omp 和 OpenCode 1.x/2.x 进行大型重构、希望让数月级单会话保持在 100K 上下文内的 AI 编程工程师

适合,因为这正是项目针对的长期编码会话场景,但 OpenCode 需要特别处理原生压缩冲突。

  • README 将目标明确写为“small context windows (100K is enough)”和“month-long single sessions (billions of tokens)”。
  • 项目采用增量、可逆、分层压缩,摘要按小范围写入,并可按需解压;这比达到窗口上限后一次性总结更适合大型重构。
  • pi、omp、OpenCode 1.x/2.x 都有原生插件安装路径,OpenCode 安装器还会关闭其 native auto-compaction。
  • README 明确警告 OpenCode 同时启用原生自动压缩会造成 double-compress,因此不能把两套压缩同时打开。

它仍不能让单次请求突破模型提供商的上下文上限;被压缩内容是否保留了重构所需的精确约束,也取决于摘要质量。

  • README「# billion-context」:small context windows (100K is enough) · 5× fewer tokens · month-long single sessions
  • README「Why」:compression here is incremental, reversible, and prefix-cache friendly
  • README「Option 1 — Native plugin」:supported today for pi、omp、opencode (1.x and 2.x)
  • README「Option 1 — Native plugin」:OpenCode 的 native auto-compaction 会被关闭;同时启用会 double-compress
npm install -g billion-context --prefix=~/.local
材料未说明:README 未给出 pi、omp 与 OpenCode 1.x/2.x 在同一大型重构任务上的实际正确率、延迟和Token节省对比。;未说明压缩摘要对完整构建日志、精确代码片段和隐含业务约束的保留比例。
适合 我在 Linux/macOS 上用 npm 全局安装 billion-context,并同时运行多个 pi、OpenCode 和 dsh lane;如何判断它的安装和端口管理是否符合我的约束?
适合读者: 在 Linux 或 macOS 上运行 Node.js/npm、使用多个客户端 lane,并希望避免全局安装权限和端口冲突的个人 AI 编程开发者

适合,因为 README 对用户级 npm 安装和多 lane 端口隔离都有明确机制,但你仍需确认 shell 的 PATH 和实际实例状态。

  • Linux/macOS 推荐使用 --prefix=~/.local,避免 sudo 和旧的 root-owned prefix 导致 EACCES;bili 会安装到 ~/.local/bin。
  • 手动 bili start 使用 8787,而 native hooks 和 launcher lanes 从 18787 的自管理区域开始,端口冲突会自动递增。
  • 升级重启时,如果旧进程仍在同一 lane 端口排空,代理最多等待 5 秒并优先复用原端口;真正被占用时才漂移并记录日志。
  • 这种设计适合多个客户端并行运行,但旧进程、手动启动的 8787 服务或异常退出仍可能让客户端连到错误实例。

它解决的是常见的安装和端口生命周期问题,不等于消除了代理进程、日志和升级状态的运维成本。

  • README「Install」:`npm install -g billion-context --prefix=~/.local`;avoid `sudo`
  • README「Quickstart」:`bili start` owns `8787`,lane 从 `18787` 开始
  • README「Quickstart」:collisions hop +1;升级重启最多等待 5s 后复用同一端口
  • 项目洞察「common_pitfalls」:旧进程和手动 8787 服务可能造成连接到错误实例
npm install -g billion-context --prefix=~/.local
材料未说明:README 未给出多个 lane 同时运行时的资源消耗、最大并发数或端口范围上限。;未说明 Windows 以外系统在代理异常退出后的自动清理行为。
视情况 我只使用 OpenCode 2.x,并且必须避免双重压缩和配置被覆盖;应该用 billion-context 的原生插件,还是继续使用 OpenCode 自带压缩?
适合读者: 维护 OpenCode 2.x 配置、不能接受原生自动压缩与外部压缩层同时运行的 AI 编程工程师

视情况:如果你的目标是长期会话、缓存前缀稳定和可逆恢复,可以选择 billion-context;如果 OpenCode 自带压缩已足够且会话不会逼近窗口,继续原生方案更简单。

  • 原生安装命令会把插件写入 OpenCode 的真实配置,并禁用 compaction.auto,说明两套机制不能并行承担压缩。
  • README 要求安装前手动备份配置;卸载时会把配置快照保存到 .bili-bak。
  • 项目声称增量压缩最多支持数月级单会话,并强调 95–97% 的前缀缓存命中率,但这些结果会受模型切换和上游缓存 TTL 影响。
  • 若使用 git checkout 而不是 npm 包,README 说明 OpenCode 没有已发布条目,可能无法按原生 Npm.add 路径加载。

因此,决定因素不是 OpenCode 版本本身,而是你是否需要长期、可恢复的上下文生命周期,以及是否能接受配置层变化。

  • README「Option 1 — Native plugin」:set `"compaction": { "auto": false }`
  • README「Option 1 — Native plugin」:keep a manual backup of the file first
  • README「Cache health at a glance」:healthy session keeps a 95–97% prefix-cache hit rate
  • README「Option 1 — Native plugin」:git checkout has no published entry
bili plugin install opencode
材料未说明:README 未比较 OpenCode 原生压缩与 billion-context 在相同模型、相同会话上的质量和费用。;未说明 OpenCode 2.x 的所有小版本是否都通过了同等稳定性验证。
不适合 我需要在企业敏感代码环境中接入 Claude 和 Codex,但网络策略不允许随意增加本地代理,且上线前必须审查许可证、日志和数据流;billion-context 是否适合部署?
适合读者: 在企业或敏感代码环境中使用 Claude、Codex 等 AI 编程客户端、受网络隔离和许可证审查约束的技术负责人

不适合直接部署,除非企业安全和合规审查明确允许本地代理改写模型请求,并接受项目许可证与会话存储风险。

  • 项目工作在客户端与模型提供商之间的本地代理层,需要观察、改写或路由请求;这与网络隔离、终端管控或敏感代码策略可能冲突。
  • Codex 的接入通常还涉及代理启动、HTTPS_PROXY 或 bili codex,会增加企业网络配置和排障面。
  • README 的许可证标记为 Other,并说明除 MIT 外存在额外归因要求;闭源集成、再分发和商业部署不能只按 MIT 处理。
  • 代理会产生进程、端口、日志、配置和会话文件;项目洞察明确指出企业环境需要审查请求流向、日志存储和数据合规。

因此,技术上虽可能接入 Claude 和 Codex,合规前置条件却比压缩收益更关键。README 没有提供企业审计、数据隔离或零日志模式的保证。

  • 项目洞察「usage_limitations」:项目需要在本地代理层观察、改写或路由模型请求
  • 项目洞察「usage_limitations」:企业安全策略、网络隔离或敏感代码环境可能不允许这种架构
  • 项目数据:license 为 `Other`
  • README「Attribution requirement」:除 MIT 外存在额外归因要求
  • 项目洞察「usage_limitations」:代理会引入进程、端口、日志和配置文件等运维面
材料未说明:README 未提供零日志模式、企业审计接口、会话文件加密或数据驻留控制。;完整许可证文本和额外归因义务的具体范围未在给定正文中展开。;未说明代理是否支持企业认证、TLS 检查代理或网络隔离环境中的离线运行。
视情况 我需要同时接入 Codex、Hermes 和 Claude:Codex 不能只靠插件自动注入代理,Hermes 使用 Python 插件,而 Claude 有 marketplace 流程;billion-context 能否统一部署?
适合读者: 使用 Codex、Hermes 和 Claude 等不同接入能力的 AI 代理基础设施工程师,需要统一管理代理路由和上下文压缩

视情况:三者都在项目覆盖范围内,但统一的是上下文管理目标,不是完全相同的安装和路由流程。

  • Claude 可通过 marketplace 安装后执行 /billion-context:bili-setup;Hermes 的安装器会复制 Python 插件到 ~/.hermes/plugins/billion-context/。
  • README 的启动器列表包含 bili codex、bili hermes 和 bili claude,因此三者都有项目定义的接入路径。
  • Codex 不能只依靠插件安装获得完整代理路由;项目洞察指出通常还需要启动 bili、设置 HTTPS_PROXY,或使用 bili codex。
  • 不同客户端的配置、认证、会话格式和子代理行为可能不同,README 没有承诺功能完全等价。

所以可以统一运维入口和压缩层,但不能假设一套插件配置覆盖三种客户端;Codex 的代理可达性是部署成败的关键。

  • README「Option 1 — Native plugin」:Claude marketplace 与 `/billion-context:bili-setup`
  • README「Option 1 — Native plugin」:Hermes 使用 Python plugin 并复制到 `~/.hermes/plugins/billion-context/`
  • README「Option 2 — Launcher」:包含 `bili codex`、`bili hermes`、`bili claude`
  • 项目洞察「common_pitfalls」:Codex 通常需要 `HTTPS_PROXY`、启动 bili 或使用 `bili codex`
npm install -g billion-context --prefix=~/.local
材料未说明:README 未说明 Codex、Hermes、Claude 三者在同一代理和同一提供商上的兼容性矩阵。;未说明 Hermes Python 插件所需的 Python 版本及客户端版本范围。

✨ 核心亮点

  • 100K上下文即可支撑数月级、几十亿Token会话
  • 增量可逆压缩,目标节省5倍Token且保持缓存前缀
  • 支持pi、OpenCode、dsh、kimi、hermes等原生插件
  • 健康会话的prefix-cache命中率为95–97%

🔧 工程化

  • bili提供原生插件、Launcher和/bili/ URL三种接入方式
  • bili plugin install可为pi、omp、OpenCode等写入客户端配置
  • 分层摘要支持按需解压,区别于不可逆的主机内置摘要器

⚠️ 风险

  • 原生模式与billion-context-pi、opencode-acp互斥
  • codex仍需先启动bili;无法连接时tools/list返回-32003
  • OpenCode需关闭auto-compaction,否则会发生双重压缩
  • dsh的Git checkout没有发布入口,缺少dist/会导致bundle不加载

👥 适合谁?

  • 使用pi、OpenCode或dsh进行长时间编码会话的开发者
  • 受100K窗口和Token费用限制、需要数十亿Token会话的团队
  • 希望用bili原生插件避免固定端口和URL改动的用户