10/18 晚间速报：v8.0.33 一次发掉 25 笔提交，剪断的流开始报 502、凭证排除名单改成覆盖；上一期那处死锁没修
CLIProxyAPI 发出 v8.0.33：25 笔提交里有四处会改现有部署的行为——剪断的上游流开始报 502、每分钟 429 不再挂几小时、凭证排除名单改成覆盖、三款 Claude 模型关不掉思考；上一期那处会让整站冻住的死锁不在这一版里。
10 月 18 日北京 21:08 到 22:10 这一个小时，CLIProxyAPI 从 v8.0.32 跳到了 v8.0.331。另外三个仓库没动：sub2api 还是 v0.2.17，codex-proxy 还是 v2.1.18，codex2api 还是 v3.1.1234。
上一期的情况要先说清。它的扫描在 21:04 收尾、21:08 发稿，而这一版的发行时间是 21:06:35，正好卡在那两分钟里5。所以上一期写「四仓没有新版本」并没有说错，只是没覆盖到它。这一期把它补上。
这版不小：25 笔提交、90 个文件、+10210/−5106。
分支头上，CLIProxyAPI 的 main 停在 21:05:44，也就是这一版的提交；dev 已经走到 21:46:28，比发行版多出 #6738 那笔合并7。sub2api 的 main 停在 10 月 16 日 12:42，codex2api 停在 10 月 17 日 05:35，codex-proxy 的 dev 停在 18:468910。
先说结论
这一版有四处会改变你现有部署的行为：
- 被剪断的上游流不再被补成正常收尾，三个执行器改成报 502。
- Claude 的每分钟 429 不再被拉成小时级冷却。
- 凭证自己的排除名单从「与全局合并」改成「覆盖全局」，插件模型也终于吃名单。
- 三款 Claude 模型关不掉思考了，请求关思考会被回落到最低档。
另外三件事它一件没修：上一期那处会让整站冻住的锁顺序（
#6744）、未鉴权就能伪造日志行的路径注入（#6731）、Antigravity 额度提示充了值也不恢复（#6745）。这三张单现在都还开着111213。所以今晚升不升，取决于你更怕哪一种：新出现的 502，还是继续冻站。
主线：剪断的流开始报 502，不再替上游说「已说完」
上一期讲过 v8.0.32 的行为：干净 EOF 上只有 OpenAI Responses 格式报错，其余格式合成
data: [DONE]，翻译层再补出 message_delta 与 message_stop14。客户端看到的是 200 正常收尾。这一版在三条路上都改了。Claude 原生流：扫完还没见到
message_stop，且不是取消、也没有扫描错误，就构造一个 502，文案是 upstream stream closed before message_stop15。
CLIProxyAPI v8.0.33 的 internal/runtime/executor/claude_executor_stream.go 第 418–436 行：第 430 行要求「扫描没错、上下文也没取消」才认定这是上游干净断连，第 431 行才把它变成 502；有扫描错误时用的是错误本身，不套这层文案。15Gemini 与 Vertex 转 Claude 输出时，看不到
finishReason 就报 502，文案是 upstream stream closed before finishReason16。OpenAI 兼容转 Claude 时，要求
finish_reason 出现过，否则同样报 50217。Kimi 那条路改得最小：把
scanner.Err() 的检查从补 [DONE] 之后挪到了之前。三条路报错前都会把这一段用量记成失败，不再按成功入账。
影响面在客户端那一侧。以前这类请求拿到 200 和一个正常结束，客户端以为拿到了完整回答；现在会拿到 502，重试逻辑会被触发。
对账也会变。同样的上游抖动，以前是「成功、有 token、收钱」，现在是「失败」，账单和失败率曲线都会跟着动。
今晚能做的三条：
- 升级后 502 变多不是新故障，是以前被吞掉的截断露出来了。先去错误日志里搜这三句文案。
- 如果你的上游本来就常常不发终局事件——一些兼容层、自建反代、故意省略
[DONE]的实现——升级后这些路径会开始持续报错。要么先修上游把收尾发全，要么暂缓升级。 - 依赖「200 +
message_stop」判断成功的客户端，现在会看到 502 并重试。确认它们不会把同一份计费重复计两次。
主线：每分钟 429 不再继承小时级的统一冷却
于是出现那种情况：一次「请求超过每分钟速率」的 429，如果响应里同时带一个几小时后的统一重置时间，冷却就按几小时算。上一期报的
#6720 就是这个。新函数
ParseClaudeRateLimitResetForError 只在三个条件同时成立时才改口径：- body 恰好是那三句 per-minute 文案之一，逐字匹配、不看子串；
- 五个配额状态头一个非空的都没有；
Retry-After只有一个值、能解析，且不超过 7 天 1 小时。
三条都满足，它把统一重置头删掉再解析一次，让短
Retry-After 说话；任何一条不满足，仍旧走老算法。
CLIProxyAPI v8.0.33 的 internal/runtime/executor/helps/claude_ratelimit.go 第 121–164 行：第 125–130 行是那五个声明配额窗口的状态头，第 141 行把三条准入条件并在一处，第 154–159 行才把统一重置头删掉。18两个错误入口都换成了它：常规上游错误分类，以及 fast 直连响应那条6。
影响很直接：被每分钟限速打中的凭证，现在几秒到几分钟就能回池，不再被钉住几小时。
升级后如果你还看到小时级冷却，先别当成没修。看响应头里有没有
Anthropic-Ratelimit-Unified-5h-Status 这类状态头——有，就是真额度窗口，这时它本来就该按小时计。主线：凭证排除名单从「合并」改成「覆盖」
v8.0.32 里，file watcher 在合成凭证时会把凭证自己的
excluded-models 和全局 oauth-excluded-models 合并，写进 excluded_models 属性，注册时读的就是这份合并结果。这一版拆成了两段。合成阶段只放凭证自己的列表，注释写明全局在注册时解析、非空的凭证列表会覆盖它20。
注册阶段先取全局名单，遇到凭证自己的非空列表就整体替换，不做并集。
CLIProxyAPI v8.0.33 的 sdk/cliproxy/service_models.go 第 66–92 行：第 74–76 行三行注释是这次语义变化的原文——凭证自己的清单优先，全局只在凭证没写时生效，所以全局改动对后者不写文件也能生效。20同一版里，插件带进来的静态模型也终于吃这份名单。追加插件模型时先按原始 ID 过滤再拼接21。上一版这条路上名单是绕过去的。
配置文件的注释也跟着写明了这套优先级22。
影响是两个方向的。写过凭证级名单的，全局名单对它不再生效，升级后可能多出你本想屏蔽的模型。没写过凭证级名单的，插件模型会被全局名单筛掉，模型列表会变少——这是修复，不是故障。
今晚查一件事：翻 auth 文件里的
excluded_models 字段。凡是写了这个字段、又依赖全局名单兜底的，把它需要的条目并进这份列表，或者把字段删掉。主线：三款 Claude 模型关不掉思考了
models.json 这一版动了六款 Claude 模型的思考能力表23。claude-opus-5-5、claude-fable-5、claude-fable-5-1 的 zero_allowed 从 true 改成 false。claude-opus-4-7 与 claude-opus-4-8 摘掉了 1024 到 128000 的预算区间。claude-sonnet-5-5 多了一个 disable_type: between_tools。
CLIProxyAPI v8.0.33 的 internal/thinking/validate.go 第 165–205 行：第 170 行判 !support.ZeroAllowed，第 171 行取最低支持档，第 172–174 行注释点名的就是 opus-5-5、fable-5 与 fable-5-1 这三款。24还有一处更安静的变化。请求里带着签名思考块、却没有
thinking 字段的，现在会被补上 thinking.type=adaptive，再挂上 drop_block 的前缀失配策略——除非 tool_choice 是 any 或 tool25。对成本的影响值得算一下。以前这类重放请求不思考，现在会思考，输出 token 会上去。
今晚能做的三条：
- 客户端别再对这三款模型发
reasoning_effort: none或 0 预算，发了也关不掉，只会被改成 low。 - 想省 token 就显式给
low，别指望 none。 - 重放带历史思考块的请求，按「会思考」预估成本。
其余随这一版落地的四笔
Gemini 与 Vertex 的工具 schema 又剔掉两个关键字：
contentMediaType 与 contentEncoding 进了删除名单，位置在 internal/util/gemini_schema.go 第 1515 行26。带这两个关键字的工具定义，上一版打 Gemini 会 400。Antigravity 的 schema 清洗改成随声明数量线性增长6。工具定义几十个的部署，构造请求那段不再越拖越慢。
剩下两笔是给多实例部署的：mDNS 主机冲突处理与 IP 绑定回退，以及 sdk 侧暴露 Antigravity 的 user agent 助手。都不涉及配置项。
次条：codex2api 的 Antigravity 兄弟档位共用同一份冷却
21:58，codex2api 开了一张新 PR：21 个文件、+3180/−84、1 提交、mergeable 是 unstable、未合并29。
病根在档位与线上模型的对应关系。Antigravity 的几个公开档位共享同一个线上 wire 模型，比如
gemini-3.8-flash 的 low、medium、high 三档都落到 gemini-3.8-flash-tiered。冷却以前只写在被命中的那个公开档位上。兄弟档位不跟着冷却，下一次选号可以继续选中同一个受限账号。跨实例的过滤也只读公开键，看不到 wire 与 family 两层的冷却。
顺带一条：原生 Gemini 的
countTokens 非 200 响应没有接进模型冷却处理，于是空转的重试不会被拦。PR 给的做法是给 wire 键与 family 键补写冷却，并加了一层「只延长不缩短」的保护。另外引入了一个默认开启的 Fresh 选号加权（按并发占用、已用配额与近期限流打分），开关是环境变量
ANTIGRAVITY_BALANCED_AFFINITY，设成 0、false、off 可关，需重启生效。现在能用的是识别与临时规避，不是等它合并：
- 同一家的三个档位不是三个独立的账号池。一个号被限速，另外两档照样会打到它。
- 见到某一档反复 429、另一档却「正常」，先怀疑共享冷却没写全，别急着判账号坏了。
- 需要立刻止血，就把那条凭证整条冷却掉：
POST /v8/management/routing/cooldown/reset是解冻用的，反过来要停，就在管理端停用该账号。
还没进发行版 / 还开着
#6738 在 21:46 并进了 dev，不在 v8.0.33 里30。它做的是让 Meta Muse 与带路由后缀的模型名，在四种协议间能认得出思考签名。具体症状与改法这一期没展开。后果是：一个不需要凭证的请求，路径里带
%0A，就能在访问日志里开出第二条物理行，内容由请求方随便写，包括假的时间戳与假的级别。审计和封号判定都要看日志，这一条值得排进日程。上游与额度
OpenAI 全绿、活动事件 033。最近三条已解决的是 10 月 14 日到 16 日的 Compliance API 成本数据延迟、10 月 15 日的广泛功能降级、10 月 14 日两个图像模型的可用性34。
Codex 侧今天 UTC 还没重置。codex-reset.com 记最近一次已验证全局重置在北京 10 月 18 日 04:41，约 17 小时前；累计 55 次全局、10 次 banked、pace ≈ 每 3 天37。
opentherank 的同一项是 63 次、中位间隔 3.1 天、最长 68 天38。两站累计口径差 8 次，取数时选定一处用。
官方社区 Codex 分区窗口内 0 条新话题，最新一条仍是 20:06 那条「用量突然涨到五倍」，上一期讲过39。
r/GeminiAI 窗口内三条都围着 Argon 的额度打转：两条问 5 小时窗口撑不了几次，一条问档位边界——付费 Pro 能用、学生促销与 Jio 促销不能用42。都是单帖自述，没有官方确认，按线索记，不按结论用。
未闭合
#6744 最终修在哪一侧、什么时候有回应；#6731 的 %q 随哪一版发出；#6745 用 UpdatedAt 判过期的改法会不会被接受；#6738 并进 dev 之后随哪一版落地；codex2api #806 合并前会不会把 countTokens 与跨实例过滤补齐；以及升级之后 502 的走向——如果集中出现，说明有上游或兼容层一直不发终局事件，那时要修的是上游，不是中转。References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI v8.0.33 发行页
github.com
- 6v8.0.32...v8.0.33 差异
github.com
- 7CLIProxyAPI dev 提交时间轴
github.com
- 8sub2api main 提交时间轴
github.com
- 9codex2api main 提交时间轴
github.com
- 10codex-proxy dev 提交时间轴
github.com
- 11CLIProxyAPI issue #6744
github.com
- 12CLIProxyAPI issue #6731
github.com
- 13CLIProxyAPI issue #6745
github.com
- 14
- 15
- 16v8.0.33 gemini_executor.go 第 428–441 行
github.com
- 17
- 18v8.0.33 claude_ratelimit.go 第 121–164 行
github.com
- 19v8.0.33 server_management_v8.go 第 32 行
github.com
- 20v8.0.33 service_models.go 第 66–92 行
github.com
- 21v8.0.33 service_executors.go 第 505–508 行
github.com
- 22
- 23v8.0.33 models.json
github.com
- 24v8.0.33 validate.go 第 165–205 行
github.com
- 25
- 26v8.0.33 gemini_schema.go 第 1515 行
github.com
- 27v8.0.33 auth/types.go 第 157–200 行
github.com
- 28
- 29codex2api PR #806
github.com
- 30CLIProxyAPI PR #6738
github.com
- 31v8.0.33 gin_logger.go 第 92 行
github.com
- 32CLIProxyAPI dev gin_logger.go 第 92 行
github.com
- 33status.openai.com summary
status.openai.com
- 34status.openai.com incidents
status.openai.com
- 35Anthropic Status
status.anthropic.com
- 36Google Cloud Status incidents
status.cloud.google.com
- 37codex-reset.com
codex-reset.com
- 38opentherank · Codex Reset
opentherank.com
- 39OpenAI 开发者社区 · Codex 分区 RSS
community.openai.com
- 40r/OpenAI
reddit.com
- 41r/ClaudeAI
reddit.com
- 42r/GeminiAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.