billion-context 0.1.133 → 0.1.134-pr.1083.981

package/README.md

@@ -810,30 +810,6 @@ The file auto-rotates at 10 MB (renamed to `bili.log.old`). Cache-hit stats
 per request are logged as `[acp-usage] round N input=X cached=Y (cache hit Z%)`
 so you can measure prefix-cache health directly from the log.
 
-### Chaining bili instances (bili → bili)
-
-When one bili's upstream is another bili (`client → A → B → LLM`), only the
-instance closest to the client should run the compression pipeline — a second
-pass would double-compress and corrupt session state. Any of three signals on
-the inbound request makes the downstream instance pass it through **verbatim**
-(no tool/tag injection, no acp-loop, no session state):
-
-- `x-bili-hop` — stamped with the processing instance's id on every processed
-  emission (#300). Clients never send this header, so its presence always means
-  "came from a bili".
-- `x-bili-sig` — sha256 digest of the exact emitted body bytes (#1078). Proves
-  no middlebox rewrote the request in transit; on mismatch the downstream
-  instance passes through anyway, because it must not process content it did
-  not produce.
-- ACP artifacts in the body (render tags / context-management tool names) —
-  fallback for relays that strip bili's headers.
-
-Every detection logs a prominent `[chain]` line (to `bili.log` and stderr)
-naming the signal that fired. Older versions that stamp only `x-bili-hop` keep
-working unchanged. If a third-party relay in your chain rewrites or strips
-request bodies/headers, a `[chain]` warning on the downstream instance is the
-safety mechanism working, not an error.
-
 ### Self-update
 
 The proxy checks npm for a newer version on startup and every 3 minutes. When a

package/README.zh-CN.md

@@ -402,16 +402,6 @@ bili --host 0.0.0.0           # 所有网卡(或直接用局域网 IP)
 
 文件超过 10 MB 自动轮转(重命名为 `bili.log.old`)。每个请求的缓存命中统计会以 `[acp-usage] round N input=X cached=Y (cache hit Z%)` 打印,可直接从日志衡量前缀缓存健康度。
 
-### 串联多个 bili(bili → bili)
-
-当一个 bili 的 upstream 指向另一个 bili(`客户端 → A → B → LLM`)时,只有离客户端最近的那个实例应该执行压缩管线——二次处理会重复压缩并破坏会话状态。入站请求上任意一个信号命中,下游实例都会**原样透传**该请求(不注入工具/标签、不跑 acp-loop、不建会话状态):
-
-- `x-bili-hop` —— 处理方实例在每次处理后的转发上盖自己的实例 id(#300)。客户端永远不会发这个头,所以它的出现一定意味着"来自某个 bili"。
-- `x-bili-sig` —— 转发体字节的 sha256 摘要(#1078)。用来证明请求在途中没有被中间设备改写;摘要不符时下游同样直接透传,因为它不能处理自己没有产出的内容。
-- 请求体中的 ACP 产物(render 标签 / 上下文管理工具名)—— 针对会剥掉 bili 请求头的中转站的兜底检测。
-
-每次命中都会在 `bili.log`(及 stderr)打一条醒目的 `[chain]` 日志,标明触发信号。只盖 `x-bili-hop` 的旧版本行为不变。如果你的链路里有第三方中转站会改写或剥离请求体/头,下游实例出现的 `[chain]` 警告是安全机制在工作,不是错误。
-
 ### 自动更新
 
 代理启动时和每 3 分钟检查 npm 是否有新版本。发现新版本就全局安装(`npm install -g`)并打印通知 —— **重启 `bili` 才能生效**。