10/18 深夜速报：上游 402 在池模式里什么都不记、在非池模式里直接停用，一次请求能连换十个号；CLIProxyAPI 把强制工具调用加思考拦成本地 400
10 月 18 日北京 19 点到 20 点这一个小时：四仓没有新版本；上游 402 在池模式下什么都不记、在非池模式下直接永久停用，一次请求能连换十个号；CLIProxyAPI 把「强制工具调用＋思考」改成发出去之前本地 400。
10 月 18 日北京 19:06 到 20:02 这不到一小时，四个仓库都没有新版本：CLIProxyAPI 还是 v8.0.32，sub2api 还是 v0.2.17，codex-proxy 还是 v2.1.18，codex2api 还是 v3.1.11234。
四仓分支头也都没动：CLIProxyAPI 的 dev 停在 17:41，sub2api 与 codex2api 的 main 停在 10 月 16 日，codex-proxy 的 dev 停在 18:465678。窗口内没有合并，也没有发行版。
这一小时值得说的是三件事：一处余额耗尽的号在两条路径上都不对，一笔会把请求提前打死在本地的校验，和一条终于写清楚的额度冷却判据。
主线：上游 402 在池模式里什么都不记，在非池模式里直接停用
先给影响面。号池里有一张号余额用完、上游回 402 之后，池模式下它不会被打上任何标记，仍在候选里；一次请求会一路换号，直到用完换号次数。非池模式下它被直接永久停用，充值回来也得人手动放开。
报障人给出的现场是三条：首字延迟从毫秒级涨到十几秒甚至上百秒，单张耗尽号把上游负载放大到十倍，换号绕完一圈之后客户端收到 502/5049。这个单子开在 20:02:03，是这一小时的最后一分钟。
池模式那一半在
HandleUpstreamError 里就能看到。账号处于池模式且没开自定义错误码时，先试管理员显式配的临时不可调度规则。非池模式那一半在同一个函数的
case 402。国产供应商、OpenCode Zen、Command Code 三类走可恢复的临时停调，OpenAI 的 deactivated_workspace 直接判死。
sub2api v0.2.17 的 backend/internal/service/ratelimit_service.go 第 541–563 行：第 545 行把国产供应商、OpenCode Zen、Command Code 分流到可恢复的余额处理，第 551 行单独处理 deactivated_workspace，第 558–563 行是剩下所有 402 的出口——handleAuthError 加 shouldDisable = true。11换号次数是有上限的，默认十次：
gateway.max_account_switches 的默认值写死在 config.go 里，Gemini 那条是三次13。所以池模式那张号被反复选中时，一次请求最多把这条路走十遍。今晚能做的五件事，按性价比排：
- 给余额敏感的账号配上账号级临时不可调度规则，让它命中 402 的文案。这类规则在池模式下也先生效，命中就不会走到上面的跳过分支10。
- 规则的入口在账号编辑弹窗里，字段名是
credentials.temp_unschedulable_rules，保存时按规则数组写回14。 - 池模式里别放会突然断余额的号；放进去就等于放弃本地状态，只能靠规则兜。
- 非池账号充值之后要手动把状态拉回来。周期探测只覆盖激活账号，
error这一档不在里面15。 - 把
gateway.max_account_switches调小，比如 3。换号上限决定一次请求最多赔进去多少上游往返。
自查只要一条：日志里
pool_mode_error_skipped 与 status_code=402 同时出现，就是这一处，不必再查凭证。报障人提的修法是给 402 加内置冷却，默认 30 分钟、可配，并把池模式的拦截放在跳过之前9。目前只有单子，没有配套 PR。
主线：CLIProxyAPI 的一笔提交，把「强制工具调用＋思考」拦在本地
#6704 这一小时落了两笔，都是 19:47 的同一个提交时刻。第一笔修它自己带进来的一个回归，第二笔改的是最终请求体的校验。
fix/http-content-compression 的 internal/runtime/executor/claude_executor_request.go 第 906–940 行：第 913–915 行 IsRequestScoped 返回真，第 919–932 行的校验在最终体上跑，命中就把 400 与一句可执行的出路上报，第 934 行起是原来的 disableThinkingIfToolChoiceForced。16先说第二笔，它更可能咬到在跑的服务。带签名的历史会在 payload 规则之前合成 adaptive thinking，规则随后把
tool_choice 强制成 any 或具体工具。而删思考那一步在规则之前就跑完了。最终体于是同时带着强制工具调用和思考，Anthropic 一定拒17。
新代码不改动你配的字段，也不重跑规则，只在最终体上判一次：
tool_choice 强制工具且 thinking.type 是 enabled 或 adaptive，就本地回 400，请求不再发给上游。错误文案给了两条出路：在 payload 规则里关掉或过滤思考，或者把
tool_choice 改回 auto。这个 400 是请求作用域的，不会因此把整条凭证冷却。放在 v8.0.32 上，同样的请求会照原样发出去，吃一个上游 400，还可能被记成一次上游错误。
自查口径：翻一遍
requests.payload 里有没有把 tool_choice.type 写成 tool 或 any 的规则。有，就在同一条规则里补一步过滤 thinking，或者改成 auto。v8.0.32 不用改配置，这一版还没有这道校验。这条要看清落在哪一版。v8.0.32 已经有 ETag／If-Match 契约：读配置回一个强 ETag，写配置可以带
If-Match，不匹配回 412 并带上当前 ETag，不带就是无条件写19。但 v8.0.32 本身没有响应压缩中间件：
internal/api/middleware 下没有这个文件，全仓的 zstd 只用在请求体解码上。压缩是这张 PR 自己加进来的，所以 ETag 被削弱也只发生在这张 PR 上。它合进来之后，用
If-Match 做配置写入的自动化脚本才不会突然开始 412。#6704 现在 5 提交、头提交就是窗口内那笔、base 是 dev，仍未合并20。发行版上这两处都还没有。主线：codex2api 的额度帧改成了有界队列，并把冷却判据写成契约
#801 这一小时又落了三笔：19:13 有界帧队列、19:26 拒掉畸形 reset 数值、19:44 管理端 live 轮询补字段。现在 23 提交、头提交 85f1a3af，仍未合并21。
feat/ws-usage-frame-ingest 的 auth/usage_frame_observation.go 第 20–62 行：第 34 行起在观测锁内先试直接应用，第 48–54 行是 64 条上限的溢出处理——保留最新尾部并把溢出标记置真，第 56–60 行在溢出时触发一次权威探测。排队中的回调只改运行时状态，不做数据库读写。22第一笔解决的是阻塞：唯一那条 WebSocket 读循环不能被一次持锁的用量写入拖住，所以观测进一个每账号 64 条的有界 FIFO，溢出时保留最新的一段、再补一次权威探测23。
第二笔更实用：额度帧里的 reset 数字先按原始整数表示解析、给偏移设界，分数、指数、溢出值一律拒掉，不再换算成一个荒唐的时长24。
第三笔把帧里的 plan 与 credit 明细投影到管理端 live 轮询，缺的键保留、隐藏余额清空、Antigravity 的字段不动25。
真正值得抄下来的是同一张单里写进 CHANGELOG 的那条契约，它把上一期讲的「被动观测改短冷却」边界补全了23：
- 5h 与 7d 两条用量路径保留更长的那个已有冷却，也保留它的原因，包括权威 Responses 429 与鉴权失败。
- 后来读到的 reset 只延长冷却，不替换原因，也不再计一次失败。
- 真实 Responses 429 可以把本地用量冷却升级成
responses_rate_limited，但不缩短它——所以ignore_usage_limit_status绕不过一次真实拒绝。 - 更强的鉴权失败保持优先。
这些话有对应实现：
usage_cooldown_persist.go 把三类状态收敛到一个发布临界区，延迟到达的帧不会用旧状态覆盖更新的鉴权错误23。对运维的意义：判断某张号是不是「被本地快照提前放回池里」，现在有判据了——看冷却原因有没有被换成窗口类原因。v3.1.1 上这些还没有，只能先按上一期那三条处置。
次条：sub2api 的工具名改写，漏了 tool_reference
#8196 开在 19:50，1 提交、2 文件 +145/−1，base 是 main，仍未合并26。
sub2api v0.2.17 的 backend/internal/service/gateway_tool_rewrite.go 第 205–245 行：第 211–218 行处理 tools[]，第 219–221 行处理 tool_choice，第 222–234 行只对 type == "tool_use" 的块取 name。tool_result 与 tool_search_tool_result 两个分支都不在这里。27没被覆盖的是 Claude Code 那类工具搜索：
tool_result.content[] 里的 tool_reference.tool_name，以及 tool_search_tool_result 里的 tool_references[].tool_name。假名发出去了，回程的引用还写着真名，上游对不上。
PR 的改法是把这两类容器也纳入同一套改写，且只动协议定义的容器，工具输入输出与嵌套载荷保持逐字节不变。它挂的是老单
#1963，那张单还开着28。今晚能做的：用着工具名伪装的部署，先避开 ToolSearch 与延迟加载工具，等这个 PR 进发行版。
次条：#6742 的 Codex OAuth 凭证反复失效（单条未验证）
这一小时新开一张：13 张 Codex OAuth 凭证里有 10 张反复 401，需要人工重新授权；10 月 1 日到 18 日存下的记录里有 22 次鉴权错误，其中两张 17 日已手工重授权，18 日一次全量刷新成功29。
报障人只给了现象，没有给上游原因，也没有第二个人复现。先当单条未验证记着：如果你的号池最近也在反复掉授权，这张单可以当对照样本。
次条：#8194 的 272K 长上下文，本刊不作结论
有一条 15:14 开的单说，按量计费下
gpt-6.1-sol 的输入超过 272K 仍然被打成长上下文，输入与缓存单价翻倍、输出 1.5 倍30。本刊只核到两件事。第一件：v0.2.17 的兜底价目里，
gpt-6.1-sol 的阈值就是 272 000、输入倍率 2、输出倍率 1.531；第二件：官方价目页把这款模型分成 Short context 与 Long context 两档，每百万 token 输入 2／4 美元、缓存读 0.1／0.2、输出 10／15。页上没有写切点在哪32。所以这不是一句「代码写错了」能了结的事：官方价目本身就有长上下文档，谁会在什么账号上吃到它，本刊没有上游账单证据，不给结论。自查口径是拿一条超过 272K 的真实请求对一次上游账单，看上游是否也按长上下文档收。
窗口内其余
#6704 的提交数从 3 变成 5，头提交就是上面那笔校验20。codex2api 的
#804 这一小时没有新提交，仍是 18 提交、72 文件；#805 只是时间戳动了21。sub2api 只有一条 4 月的交流长帖被顶起。codex-proxy 窗口内 0 条更新。#6743 是群里拉人的广告帖，按本刊的排除规则不收。上游与额度
OpenAI 全绿、活动事件 03334。Anthropic 全绿，10 月 18 日无事件35。GCP 的 incidents.json 仍是 7 条，最近一条是 10 月 8 日晚到 9 日的 Cloud Storage36。
Codex 侧今天 UTC 还没重置。codex-reset.com 记最近一次已验证全局重置为 10 月 18 日凌晨 04:41，约 15 小时前。
同页的累计口径是 55 次全局、10 次 banked、pace ≈ 每 3 天，24 小时 21%、48 小时 37%，模型置信度 Low37。
opentherank 的同一项是 63 次、中位间隔 3.1 天、最长 68 天38。两站累计口径差 8 次，取数时选定一处用。
社区侧窗口内没有额度或风控新帖。官方社区 Codex 分区 0 条新话题，最新一条停在 15:3439。
未闭合
#8197 会不会有人回应、会不会带出 PR；#6704 什么时候并进 dev；#801 这 23 提交最终以什么形态合并；#8196 会不会被工具搜索类部署撞上；#6742 的反复 401 是单点还是普遍。References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI dev 提交时间轴
github.com
- 6sub2api main 提交时间轴
github.com
- 7codex2api main 提交时间轴
github.com
- 8codex-proxy dev 提交时间轴
github.com
- 9sub2api issue #8197
github.com
- 10v0.2.17 ratelimit_service.go 第 336–348 行
github.com
- 11v0.2.17 ratelimit_service.go 第 541–563 行
github.com
- 12v0.2.17 ratelimit_service.go 第 973–980 行
github.com
- 13v0.2.17 config.go 第 2435–2436 行
github.com
- 14v0.2.17 EditAccountModal.vue 规则字段
github.com
- 15v0.2.17 ratelimit_service.go 第 415–424 行
github.com
- 16PR #6704 头分支 第 917–932 行
github.com
- 17提交 c569bc07f6
github.com
- 18提交 4fbdb22d26
github.com
- 19v8.0.32 config_v8.go 第 23–37 行
github.com
- 20CLIProxyAPI PR #6704
github.com
- 21codex2api PR #801
github.com
- 22PR #801 头分支 第 30–62 行
github.com
- 23提交 376b9a0c
github.com
- 24提交 1c759fa3
github.com
- 25提交 85f1a3af
github.com
- 26sub2api PR #8196
github.com
- 27
- 28sub2api issue #1963
github.com
- 29CLIProxyAPI issue #6742
github.com
- 30sub2api issue #8194
github.com
- 31v0.2.17 billing_service.go 第 585–590 行
github.com
- 32OpenAI API Pricing
platform.openai.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 Developer Community · Codex
community.openai.com
- 40r/OpenAI
reddit.com
- 41r/ClaudeAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.