实测 billion-context：一个宣称能省 5 倍 token 的 AI 编码代理，在 Windows 上跑得怎么样

用 Claude Code、Codex CLI 这类 AI 编码 agent 的人对账单都不陌生：每轮对话都要把代码库上下文、历史消息、工具调用结果整体打包发给模型，token 消耗随会话长度线性上涨，长会话里大头往往是重复发送的旧上下文。

billion-context 的思路是在 agent 和模型 API 之间插一层本地代理：它监听一个端口，接收 /v1/chat/completions 这类标准请求，对上下文做压缩后再转发给上游模型，宣称能把 token 用量压到原来的五分之一。项目地址是 ranxianglei/billion-context，MIT 许可，纯 TypeScript 实现，当前版本 v0.1.197。

判断这类中间层项目靠不靠谱，第一步很朴素：能不能在干净环境里装起来、编译过、把服务跑住。我这次实测就停在这一步，并且会把边界说清楚。

测试环境与安装

• Windows 10 (19045)，Node.js v24.13.1，npm 11.8.0
• git clone 仓库，拿到 1501 个文件
• npm install：装了 604 个包，耗时 33 秒，退出码 0

依赖数量对一个小工具来说不算少，但一次通过，没有报任何平台相关的编译错误，TypeScript 项目在 Windows 上常见的原生依赖翻车（node-gyp 之类）没有出现。

编译与启动

npm run build 正常退出，产出单文件 dist/index.js，体积 5.45MB，看起来是打包工具把依赖全部内联进去了。这种分发形态对终端用户友好：装好后不需要再关心 src 目录。

几个基础命令的实测结果：

node dist/index.js --version
# 0.1.197 (467e09ef)

node dist/index.js --help
# 列出 bili pi / bili codex / bili claude 等启动器，退出码 0

help 输出里能看到它对几种主流 agent 客户端做了适配入口，每个启动器负责把客户端的模型端点指到本地代理。

启动服务：

node dist/index.js start --port 8791

代理正常监听。启动过程中它自动在配置目录生成了一个 {"providers":{}} 的配置文件，providers 为空，符合首次运行的预期。

接口探活

用 curl 打了几个端点：

第三行值得多说一句。在未配置任何上游模型的情况下，代理没有把请求放行、也没有崩溃，而是返回了明确的拒绝。对要常驻在开发机、监听端口的中间层服务来说，默认拒绝的姿态是对的，比默认放行或者含糊报 500 要让人放心。

状态端点暴露版本和 commit，排查问题时不用猜自己跑的到底是哪个构建，这也是基础设施类服务的好习惯。用完之后终止进程，端口确认释放（再连返回 HTTP 000，curl 退出码 7）。

另外注意到它用 Node 内置的 node:sqlite 做存储，不额外拉起数据库进程，部署形态确实轻。

这次没有验证的部分

必须如实说：本次实测只走到「安装、编译、起服务、接口探活」这一层。

核心的压缩效果没有测。原因很简单：要验证「省 5 倍 token」，需要配置真实的上游 LLM API key，并接入一个真实干活的 agent 会话，对比压缩前后的用量。我这台机器上没有可用的模型凭证，代理也因此始终停留在拒绝转发的状态。这个数字目前仍然是项目的自我宣称，不是我的实测结论。

同理，压缩会不会影响 agent 完成任务的质量（比如丢掉关键的代码上下文导致答非所问），这是这类方案真正的风险点，也需要拿着凭证跑真实任务才能回答。

什么人适合先试

如果你对以下场景有需求，这个项目的工程质量值得你拿自己的 API key 试一轮：

• 长会话编码 agent 用得多，token 账单敏感
• 愿意在本地加一层代理，接受多一个常驻进程
• 有自己的模型凭证，能跑压缩前后的对比

从这次实测看，项目在细节上是认真的：构建一次通过、失败姿态保守、状态信息可观测、依赖干净。装不上的顾虑可以打消，省不省 token、压缩后 agent 还聪不聪明，留给你自己的环境去验证。拿到 key 之后大概率就是改一个 base URL 的事，成本不高，值得跑个对照。

本文基于 2026-10-17 在本机 Windows 环境的实测记录撰写。项目地址：https://github.com/ranxianglei/billion-context，许可证 MIT，版本 v0.1.197。