[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3rnb2bcvkw3h2":3},{"code":4,"message":5,"data":6,"timestamp":27},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":23,"homepage":24,"updated_at":25,"history":26},"ranxianglei\u002Fbillion-context",13,"A context-compression plugin for month-long single sessions (billions of tokens) ,small context windows (a 100K context is enough) and token savings (5x fewer tokens) .上下文压缩插件，月级长会话会话， 兼顾小窗口(100k上下文足矣)省token(省5倍token) . billion-context is all you need","TypeScript",2624,222,919,79,[],"把上下文压缩做进模型 API 流里，让编程 Agent 的长会话不断、少烧 token。","## 解决什么问题\n编程 Agent 的会话越久，历史越长。每次请求都要重放一大段前缀，token 费用持续叠加；一旦超出窗口，会话要么退化成粗暴截断摘要，要么直接中断。billion-context 以代理形式插在 Agent 和模型 API 之间，改写信流，把已经消费过的对话折叠成分层摘要，而不是直接丢掉。\n\n## 有什么不同\n常见做法是宿主自带的摘要器（单向、有损），或者干脆换一个更大的上下文窗口。billion-context 走增量分层压缩，并给模型提供 `decompress` 和 `search_context` 工具，需要精确细节时可以把压缩区间还原回来。另一个关键点是前缀缓存友好——README 称命中率能维持在 95–97%、压缩本身开销 ≤2%。这一点很重要：随意改写前缀会让上游缓存失效，省下的 token 又从缓存上还回去。它声称通过一个代理兼容 Claude Code、Codex、Gemini CLI、OpenCode、aider 等一长串客户端，而不是给每个客户端单独写插件。\n\n## 适合谁\n适合动辄跑几天连续会话的 Agent 用户，以及按 token 计费、想用一条长会话代替多次短会话的团队。如果你被限制在 100K 左右窗口的模型上，也值得看。不适合无法修改 base URL 的封闭 IDE 助手用户；会话本来就很短、离窗口上限很远的人用它只会多一跳代理，没有任何收益。\n\n## 上手成本\n需要 Node\u002Fnpm（`npm install -g billion-context --prefix=~\u002F.local`），然后把 Agent 的 base URL 指向代理，或走 `bili` 启动器\u002F插件方式接入列出的客户端。代价是你在每次模型调用里插入了一个中间人：切换模型、上游缓存 TTL 过期都会变成故障源，README 自己也把这两条列为缓存命中率下降的首要原因。License 显示为 NOASSERTION，内部落地前先确认实际条款。压缩质量依赖模型遵守注入的工具指令，弱模型产出的摘要会明显更差。\n\n## 点评\n项目仅 79 天，2,597 star，一周涨了 937 个、冲上 TypeScript 周榜第 13——这是早期项目赶上真实涨势，而非成熟工具。附带的论文规模不小（长时间纵向研究），对一个这么年轻的项目来说很难得，但属于自发布，行为细节仍以 README 为准。思路是对的，痛点也是真的；风险在于它卡在整条链路最敏感的 API 位置。建议先在副项目里开着 `\u002Facp-cache` 跑一跑，再考虑放进正式工作流。",{"slug":19,"name":20},"developer-tools","开发工具",[22],"dsh-plugin","NOASSERTION",null,"2026-10-24T19:35:21Z",[],1792887552]