CLIProxyAPI v8.0.41 一版关掉七张单：RESP 崩溃补丁进发行版，两条返回语义同时变了
CLIProxyAPI v8.0.41 用一版把七张报障单一次关掉，包括两期前那条未鉴权的 RESP 崩溃补丁；配置一行不用改，但 Gemini 的终止原因与整份被拦这两类返回的语义变了，告警规则要跟着调。
凌晨 02:25，CLIProxyAPI 发了 v8.0.41。1
十条 changelog 里九笔是实际改动，其中七笔各自关掉一张报障单。这七张单的关闭时刻挤在北京时间 02:24:48 到 02:25:01 这十三秒内。2
里面有三条本刊前几期点过名：上一期的用量合并（#6925）、更早的工具参数被清空（#6898）、以及连着两期在报的 RESP 无上限。没有一条还在 dev 上等下个版本。
配置一行不用改。
config.example.yaml 在 v8.0.40 与 v8.0.41 之间逐字节相同，这版也没有新增配置键。3要改的是告警规则。有两类返回的语义变了，升级后的头一天，它们会以「新故障」的样子出现在面板上。
十三秒关七张单
最后一笔代码提交 8289ec4c 落在 02:18:56，发行页写的发布时间是 02:25:13。4
两版之间动了 47 个文件，其中 26 个是测试文件。5
和上两期不一样的地方在这里：这次
main 也到了同一支提交。main 与 dev 的头都是 18:18:56Z，从主干构建和从发行包构建拿到的是同一份。6前两期补丁只在 dev，从主干拉代码拿到的是旧版本。上一期给的四步防护，升级后可以逐步撤掉；前置代理那条建议留着。
本刊报过的三条
用量合并：不再一律按 Claude 的口径重算
上一期给的算例是 140 变 150。当时的问题在「无条件重建」：含缓存的输入被当成未缓存再叠一次缓存，已不含思考的输出再减一次思考。7
现在先问一句「送进来的这份快照自己是什么口径」，再挑对应的构造器。
internal/runtime/executor/helps/plugin_executor_usage.go 第 186–226 行：第 188–194 行先从 update 里问两个口径问题，问不出来再问 existing；第 197 行的分支用新口径重建，第 217 行的分支按「缓存是子集」处理，两种都对不上才落到旧的独立口径。三条路的取舍很直白。输出不含思考，就把思考单列；输入含缓存，就把缓存当子集；两个都对不上，才回到旧算法。
判定不是猜的。
detailInputIncludesCache 要求快照的 breakdown 质量是 complete，且总量、未缓存量、缓存量三项都对得上，才认这个口径。8自查只要一步：升级前后各打一条 interactions 流式请求，比
usage 里的总数。旧版多出来的那一份就是缓存。工具参数：只有显式关掉的空对象才算无参
#6898 的症状是参数被整份吃成
{}。工具声明的 schema 写 {"type": "object"}、省掉 additionalProperties，也就是隐式开放，旧代码仍把它判成无参工具，回程把参数归一化成空对象。9修法是一行判定，外加四行新注释。
internal/util/translator.go 第 947–970 行：第 951–953 行的注释写明「省略 additionalProperties 的对象不算无参」；第 964 行多要求一个 info.forbidsDynamic，也就是 schema 必须显式写 additionalProperties: false，否则直接返回假。另一半在流式侧：Gemini 与 Antigravity 的空
input_json_delta 押到工具结束再发，续块不会把重复的空对象拼上去。RESP：两期前的加固原样进了发行版
同一个提交 SHA，888f2382，本刊在两期前逐行读过它。10
四个上限加三处 panic 恢复一起进了发行版：数组最多 1024 项、单个 bulk 64 KiB、一个数组累计 64 KiB、一行 64 KiB。
internal/api/redis_queue_protocol.go 第 426–452 行：第 439 行把数组计数卡在 1024，越界即判协议错误；第 443 行给整个数组一份 64 KiB 预算，第 445 行把它传进每一项的读取。它没有改鉴权顺序。连接进来仍然先读一整帧命令，读到了才回
NOAUTH。11所以对外暴露的实例，未鉴权的第一帧现在仍然能进来，只是这一帧有了上限，解析路径上也有人兜住 panic。真要挡住外面，还是那两条：前置代理只放行 HTTP，或者把
server.host 从空改成内网地址。顺带一句：开了 Home 模式的实例，这条路径本来就关着，读到配置就直接回
ERR redis usage output disabled in home mode。这次新关的五张
| 条目 | 以前的样子 | 影响谁 |
|---|---|---|
| #6897 | 内联 $ref 时，同级关键字把目标的约束冲淡了 | 工具 schema 里 $ref 与同关键字并存 |
| #6911 | 文本夹在两次工具调用之间，第一个 functionCall 缺 thought_signature，上游回 400 | Claude 转 Gemini 且带工具调用 |
| #6906 | 八种 Gemini 终止原因被压成正常结束 | 所有 Gemini / Vertex / Antigravity 下游 |
| #6895 | codex 的 phase: commentary 段被当正文写出去 | codex 转 claude 的响应 |
| #6914 | Home 模式的 /v1beta/models 不带 inputTokenLimit | 靠目录做模型发现的客户端 |
后两条要多说两句，因为其中一条会改你面板上的读数。
终止原因这张表这次重写了判定：
SAFETY、RECITATION、BLOCKLIST、PROHIBITED_CONTENT、SPII、IMAGE_SAFETY、MALFORMED_RESPONSE、MALFORMED_FUNCTION_CALL 八种原因，以前落到 stop，现在落 content_filter。12
internal/translator/gemini/openai/chat-completions/gemini_openai_response.go 第 496–543 行：第 496–512 行是分派函数，第 502–503 行把命中项写成 content_filter；第 538 行是那八种原因，第 539 行返回真。两条会被当成故障的返回
第一，Gemini 的安全拦截不再伪装成正常结束。以前
finish_reason 是 stop，客户端以为答完了；现在是 content_filter。第二，prompt 整份被拦的响应，现在直接 502。判据是没有 candidates、只有
promptFeedback.blockReason，回给客户端的是 upstream blocked the prompt: <原因>。15这一道一共挂了六个调用点：Gemini 执行器的非流式与流式各一处，Vertex 执行器四处。16
动手改告警前先确认一件事：你的面板按
finish_reason 分类，还是按 HTTP 状态码分类。前者这周就会跳变，后者只在第二类上跳。升不升，三步
- 先备份
config.yaml。这版不改配置结构，备份只为回滚时有对照。 - 升到 v8.0.41 并重启。只需动 CLIProxyAPI，另外三个仓库这窗口没发版。
- 升完打一条 interactions 流式请求看
usage总数，再打一条会被 Gemini 拦的请求看返回码。前者对账，后者确认新的告警分类。
要不要今晚就升：如果实例的 8317 对公网开着，这版值得今晚升——那是唯一一条「等一天就多一天暴露」的。其余两条是账本与参数正确性，晚一天只是多一天的错数。
还没进来的三张
PR #6893（代理拒绝 CONNECT 时挂住）仍然开着，2 文件 +88/−3，mergeable clean，18:22:03Z 又有更新。17
PR #6715（把 Codex 设备码登录暴露到 v8 管理接口）也开着，19 文件 +1366/−38，18:38:43Z 更新。18
PR #6926 可以不用等了。它是社区在 18:21:57Z 提的草稿，改的正是用量合并那件事；维护者自己那笔 18:18:56Z 已经修完并随这一版发出。19
四仓这一小时
| 仓库 | 当前版本 | 发布（北京） | 本窗口 |
|---|---|---|---|
| CLIProxyAPI | v8.0.41 1 | 10-24 02:25 | 发版；关七张单 |
| sub2api | v0.2.18 20 | 10-23 15:44 | 零新版本、零新条目 |
| codex-proxy | v2.1.20 21 | 10-23 03:56 | 零新版本、零新条目 |
| codex2api | v3.1.1 22 | 10-17 05:46 | 零新版本、零新条目 |
sub2api 窗口内唯一动过的是四月那张交流长帖被顶起，不算动态。
其余窗口动态
Codex 重置这件事，两家追踪站今天给了两套说法，本刊照抄不合并。
codex-reset 首页：今天 UTC 还没重置，最近一次已验证的全局重置是 10-22 17:10 UTC，约 25 小时前；累计 57 次、10 次 banked、节奏约每两天一次。23
opentherank 首页写的是
Landed as announced, around 10:00 Pacific Time (17:00 UTC). Tibo has not posted a separate confirmation.，最近一次记录 10-22 17:00 UTC，累计 65 次、中位间隔 3 天。24差别在计数口径（57 对 65），不在最近那一次——两边都指向 10-22 傍晚。
codex-reset 首页自己还有一处矛盾：同一屏既写「not so far today」，又写「58 minutes ago」。后者是它的 radar 读数，对应 feed 里 2026-10-23T17:40:51Z 那条
operator-observed 记录，summary 与 04:47:34Z 那条推文逐字相同，属同一条帖的重录。25按北京算，下一条承诺落在 10-25 01:00（夏令时读法），字面 PST 是 02:00。26
三家上游状态页窗口内没有新事件。OpenAI 全绿，最近一条是 10-23 的客服响应延迟，03:41 到 05:58，已恢复。27 Anthropic 全绿，页面更新于 17:42。28 Google Cloud 最近一条仍是 10-22 16:19 的 europe-west 故障。29
还没闭合的
七张单关得快，但关闭动作只说明代码进了主干。发行页那十条 changelog 与七张单能不能一一对上，还得逐张核。
#6897 是这版改动最大的一处，新增 539 行、两个新测试文件。本刊只核了它的判定入口，没有逐条核它保留约束的算例。30
Codex 重置的两种口径谁先落地，等 10-25 凌晨那个时点过去再看。
References
- 1v8.0.41 发行页
github.com
- 2七张单的关闭记录
api.github.com
- 3v8.0.41 的 config.example.yaml
github.com
- 48289ec4c 的提交说明
github.com
- 5v8.0.40 到 v8.0.41 的文件清单
github.com
- 6main 的提交时间轴
github.com
- 7#6925
github.com
- 8plugin_executor_usage.go 第 260–300 行
github.com
- 9#6898
github.com
- 10888f2382 的提交说明
github.com
- 11redis_queue_protocol.go 第 78–100 行
github.com
- 12gemini_openai_response.go 第 536–543 行
github.com
- 13server_routes.go 第 1071–1092 行
github.com
- 14model_registry.go 第 1806–1811 行
github.com
- 15gemini_executor.go 第 500–521 行
github.com
- 16gemini_vertex_executor.go 第 548–560 行的调用
github.com
- 17PR #6893
github.com
- 18PR #6715
github.com
- 19PR #6926
github.com
- 20Sub2API 0.2.18
github.com
- 21v2.1.20
github.com
- 22v3.1.1
github.com
- 23codex-reset 首页
codex-reset.com
- 24opentherank
opentherank.com
- 25codex-reset 的事件列表
codex-reset.com
- 26Tibo 那条推文
x.com
- 27OpenAI 状态
status.openai.com
- 28Anthropic 状态
status.anthropic.com
- 29Google Cloud 状态
status.cloud.google.com
- 3029150a22
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.