刚开源两个月就冲上热度榜前列billion-context 的一周 628 星是怎么来的【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context2026 年 8 月上旬一个叫billion-context的仓库悄悄出现在 GitHub 上slogan 只有一句话billion-context is all you need。它的定位反直觉不是把上下文窗口做得更大而是宣称100K 小上下文足矣——靠上下文压缩插件把已消耗的对话折叠成可逆的分层摘要省 5 倍 token同时支撑数月级别、数十亿 token 的超长单会话。到 10 月中旬这个仓库在周榜上拿下 628 星冲入热度榜前列。一个个人项目两个月内从 0.1.x 的早期版本号一路发布到0.1.197见 package.json在 AI 编程工具这个赛道并不算罕见的发布节奏。但 628 星这个量级放在两个月历史的基数上意味着增长是陡的。这篇文章想回答一个问题热度不是凭空来的它踩中了哪些真实痛点、靠什么工程证据站住了脚。以下分析全部基于仓库源码、随仓库开源的论文paper/目录以及同期社区情报不依赖任何推测。一周 628 星从发布密度看增速的内部证据Star 快照只能看一个点无法还原每日曲线但仓库内部留下了比 star 数更诚实的增速证据——发布与迭代的密度。第一层证据是版本号跨度。CHANGELOG 从0.1.342026-08-11一路记到当前的0.1.197两个多月约 160 个发布版本其中 2026-08-22 至 08-24 三天内就有五个大版本。这个节奏对应的是持续数月的生产使用反哺开发作者在仓库里维护的 devlog见 devlog/README.md显示从 2026-08-13 到 2026-09-27 共有 36 个完整迭代条目每条都包含REQ.md问题陈述与验收标准和WORKLOG.md提交、关键文件、测试结果。例如 devlog/2026-09-23_dsh-llm-pi-ai-fetch-bypass/ 一条条目里owner 的评审直接否决了SDK 私有 fetch 绕过的根因假设要求开发者用逐版本证据链推翻自己的结论——这种迭代质量是社区口碑传播的底层素材。第二层证据是测试体量。仓库内共有 800 个.test.ts测试文件其中 17 个是驱动真实客户端的 E2E 套件tests/e2e/例如e2e-codex.test.ts会拉起真实的codexCLI 穿过 bili 代理跑完整生命周期warmup → 负载增长 → ACP 压缩 → 纯度校验 → 原生 compact 拦截。npm test全量跑 800 个文件CI 用scripts/run-ci-tests.mjs以并发 4 的确定性方式执行并自带自检新增会派生进程的顶层测试文件若未登记进并发假设清单任务直接失败。第三层证据是外部生态的跟进。10 月 14 日 CSDN 上已经出现完整的中文开发者指南《如何为 billion-context 贡献代码500 测试体系、原生插件协议与统一存储架构》系统梳理了它的四层测试体系、原生插件协议与统一存储架构——一个开源仅两个月、尚无大型机构背书的个人仓库出现这种级别的第三方技术拆解本身就是热度信号的组成部分。README 里的社区板块也留下了直观注脚一个 QQ 群已满开了第二个。把这些拼起来628 星不是营销事件的结果而是一个生产数据先行、发布密度极高、工程纪律外显的项目在合适的窗口期被社区发现后的自然爬升。为什么是压缩路线而非原生长窗切入点的踩点逻辑要理解这个切入点先看它反对什么。仓库随代码以 MIT 许可开源了一篇论文paper/model-driven-incremental-hierarchical-compression-training-free-multi-generational-context-management-for-long-lived-coding-agents.md其中把现有解法归为三类且每类都有明确的结构性缺陷滑动窗口截断直接丢弃最老的 turn位置退化还会侵蚀幸存者出窗内容永久不可恢复渐近保留率 R∞0阈值触发的一次性自动压缩主流商业编码 CLI 的出厂设置如 Claude Code 的/compact临近窗口上限时把整段历史压成一个不透明 blob 并丢弃原文——不可逆、单粒度、且触发时机对任务状态完全盲目。论文给它算了一笔账每轮把约 80% 窗口的历史重新摘要早期内容的保留率按 ρ≈0.4–0.6 逐轮几何衰减四轮之后只剩 3–13%外部记忆向量/图存储写时不可逆——事实留下了但解释某个修复为什么有效的 traceback、300 轮前用户说过的约束这类程序性上下文在离开窗口的瞬间就丢了。而原生长窗路线1M、4M token 窗口模型的代价是双重的按 token 计费意味着账单随历史线性膨胀注意力在长上下文尾部退化把更多上下文塞进去并不等价于更好。billion-context 的差异化主张是200K 有界窗口就够了条件是把它组织成一种叫 fold 的布局。核心机制在仓库内一目了然——压缩由两部分承担宿主代理src/npm 包billion-contextCLI 为bili夹在 agent 与模型 API 之间改写 Anthropic/OpenAI 流压缩内核kernel/npm 名acp-kernel约 1 万行 TypeScript是零宿主依赖的纯库每轮走固定的 9 段流水线assign-refs → sync-blocks → merge-blocks → prune → filter → hide-compress-calls → nudge-inject → emergency-truncate → render-refs见 kernel/src/pipeline.ts。这张图是整个项目的骨架。模型窗口被分成两半左侧是 digest blocks——按 tier-1/2/3 分层的摘要块像 LSM 树一样逐代蒸馏tier-1 摘要本身可以作为原料再被压缩成 tier-2每一块都可按需decompress还原生产语料中 tier-1 占驻留空间的 92% 却只代表 13.5M/21.6M 的原始历史右侧是 recent zone保留约 50K token 的逐字原文新的 turn 追加在这里首条/末条消息受保护。代理向对话注入四个上下文管理工具——compress、decompress、search_context、acp_status——由模型自己决定何时压缩哪一段compress在服务端执行。关键设计在 kernel/DESIGN.md 的第一页就写明了这和 zip 有本质区别——模型写摘要库负责其余一切编排核心库本身从不调用模型所以它才能是纯函数、可独立测试。这套布局的经济学是论文的核心贡献全部来自 4.5 个月、三宿主的真实生产数据174,327 次模型调用、187.6 亿累计输入 token增量压缩让成本只跟工作量走不跟历史长度走。每轮只压上次压缩以来新增的已消费增量增长门控 50K有效下限 22.5K每条内容一生只被折叠一次保留率稳定在约 1/8不随轮数复利衰减。生产观测中每次压缩的输出中位数仅 185 token97.5% 的摘要不超过 2K token重载会话的历史量约 900K token最终驻留摘要仅约 13K——约 70 倍的常驻宏折叠。前缀缓存永不失效。历史是 append-only 的压缩只去活后缀范围KV 缓存前缀因此始终有效。实测活跃节奏下调用间隔 2 分钟占 89% 流量缓存读取份额达94.2%在按缓存 token 约 10% 计费的定价下这直接砍掉了大部分输入成本。对比之下rewrite 式压缩每次事件都要打爆整个前缀。上下文留在模型注意力的可靠区间。前沿模型在 sub-200K token 区间注意力最可靠fold 让总上下文持续振荡在这个带内而不是推向退化的长尾。这张来自生产日志的轨迹图是最有说服力的一张12,049 次调用的 OpenCode 会话和 8,584 次调用的 Pi 会话每次调用的上下文都在有界带内振荡从未击穿 1M 窗口而 204,800-token 窗口的模型在整个观察期零违规。论文还给出容量上界同一布局按生产比例校准的仿真显示1M 窗口理论上可支撑约 28.6B token、106 天的单会话工作——而不加 fold 的同一会话大约 104 次调用不到一天就会撞上窗口约 550 倍的差距。受控实验qwen3.8-27b四组对照则把质量账算实了压缩组账单 token 降 31–54%召回探针与不压缩基线持平重复取回re-fetch调用降 63%。值得点出的踩点细节这套判断力是免训练的。论文把压缩判断写成一份可执行的提示词规范doctrine见 kernel/DESIGN-prompts.md两种失败模式过压缩/欠压缩、单一判据当前任务步骤还需要这段内容吗、KEEP/DROP 规则、以及六个交互机制——比如 nudge 故意不告诉模型上下文占用率模型会把20%锚定为健康状态而拒绝压缩以及赋予模型拒绝压缩的权利。对照 AgentFold、Context-ReAct 等需要针对每个框架微调 30B 模型的研究路线把策略放进可检查、可版本化、可宿主覆盖的文本里显然是更轻、也更适合个人开源者维持的路线——这或许是它能在两个月内被大量小窗口用户GLM、Kimi 等 100K–200K 窗口订阅用户接住的关键。从榜单表现看它踩中的社区情绪最后看榜单之外的生态面2026 年年中到秋中文技术社区的上下文关键词集群已经整体换轨。同期掘金上的热门开源项目——headroom给 AI Agent 装上上下文压缩层Token 最高省 95%1,296 阅读、Context Mode21K Stars、98% 上下文节流、OpenViking给 Agent 装上可自进化的上下文数据库——以及 CSDN 上 SQLiteFTS5 构建轻量上下文方案的教程指向同一个情绪社区的关注点正从窗口能不能更长转向token 花得值不值。长窗模型MiniMax-01 的 4M、各家 1M 窗口把天花板抬得很高但按 token 计费的账单和长尾注意力退化是每一个重度使用编码 agent 的人的切身痛点。billion-context 的 slogan——100K 上下文足矣——恰好是这个情绪的反向表达不需要更大的窗口需要的是正确的布局。它踩中的第二层情绪是可验证性焦虑。这个赛道上省 X% token的宣称很多但能拿出生产规模纵向数据的几乎没有。billion-context 把论文与代码放在同一个仓库里paper/目录注明是 MIT 许可的活文档任何人都可以编辑论文里每个数字都带 [V]日志验证/ [A]仿真/ [P]计划中的证据标记附完整的 claims register 登记哪些是测量、哪些是外推。仓库甚至把 94.2% 缓存命中这种核心指标做成了用户可自查的界面这是它 Web UIhttp://localhost:8787的会话用量页顶部是缓存命中率 96% 与压缩后命中率归因分解新内容 / 压缩回补 / TTL 回补下面折线图把每次压缩折叠点、上游 TTL 过期重读逐条标出。README 开头就教用户用它自查健康会话保持在 95–97% 前缀缓存命中压缩本身代价 ≤2%持续更低用/acp或/acp-cache查归因。一个把怎么验证我说的话写进 README 首屏的项目对社区情绪的承接是直接而有效的。第三层是长会话这个马拉松现象本身。论文的语料分析4,843 个会话画出了一个反直觉的分布62% 的压缩活动发生在 1.3% 的千消息以上会话里——短会话 benchmark 在结构上观测不到压缩真正发力的区间。这意味着该项目天然筛出了一批重度用户他们不是试用而是把一个月的工作装进一个会话里跑。这类用户产生的问题反馈仓库 issue 编号已推进到三千以上又反过来支撑了 36 条 devlog 的迭代密度形成一个闭环。把三层拼起来628 星的答案是它出现在上下文经济学取代上下文长度成为社区主叙事的时间点它拿出了一个可被第三方复述、可被 Web UI 自查的生产级证据链4.5 个月、187.6 亿 token、零窗口违规、94.2% 缓存命中、31–54% 账单削减它的接入成本恰好压到个人用户能立刻验证的门槛——npm install -g billion-context --prefix~/.local一行命令三种接入方式原生插件 /bili client启动器 / baseURL 加/bili/前缀覆盖 Claude Code、Codex、OpenCode、pi、Kimi、Gemini CLI、Copilot CLI 等二十余个客户端。热度是窗口期的奖赏但让 628 星之后的用户留下来的是 fold 布局里那个朴素的主张上下文管理的价值不在任何单一机制而在让模型在正确的时机只折叠它已经消费完的增量。【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
