认不出的 call_id 只回 404：一张补丁让它逐凭证换号，四张修复还没发版

谁会撞上这个 404

• 进程重启。补丁的注释直接写明：重启前创建的呼叫，在这里是未知的。
• 多副本没有粘性。call 在 A 实例创建，sideband 请求落到 B 实例。
• call 由本代理之外创建，比如 Codex Desktop 直连上游。

补丁改了什么

1. 未知且不带 client secret 的呼叫，不再 404，改为转给上游，由上游判定这个 call 的访问权。
2. 凭证按三个优先级排序：下游带的 X-CLIProxy-Codex-Account-Id 指名的账号，上次成功加入的那张，其余按 ID 排序。
3. 拨号失败或握手不是 2xx，换下一张接着试；全试完仍失败，才走原来的错误出口。
4. 接上之后记住这张凭证，下一次未知呼叫先试它。

• Home 模式不走这条路。判断条件是 unknownCall && !h.authManager.HomeEnabled()，开了 home.enabled 的部署，未知 call_id 仍是 404。
• 只试 OAuth 凭证。current.AuthKind() != auth.AuthKindOAuth 的凭证被跳过，API key 号池不参与。
• 「上次加入的那张」是进程内一个字符串，跟着进程走，不按 call 记，重启就没了。
• 提示头只用来排序。它不校验、不绑账号，也不会转给上游——上游握手头只从 liveProtocolHeaders 这份白名单里取，名单里没有这个新名字。5

今天能做什么

1. 给 GET /v1/realtime/calls/:call_id 做粘性，让同一个 call 始终落到同一个实例。多副本部署做这一步最有效。
2. 滚动重启前先把 live 会话放干净：它们只活一小时，进程一停就查不到了。
3. 别从本地日志判断这个错。v8.0.43 的 404 分支不写日志，判据在客户端——客户端收到 404，而实例日志里找不到对应的上游记录。
4. 别急着给客户端加那个提示头。#7009 还没合并，v8.0.43 里没有这段代码。

今晚 dev 上的四张修复

其余窗口动静

• dev 上另有四笔 discovery 相关提交（19:15 与 20:53 两批）和一个合并提交（PR #7010，21:14），都与本刊跟踪的额度、风控无关。
• #6998（插件拦截器正文开销）20:39 也标了 Fixed，但它的提交 6fe654bf 下午 16:47 就进了 dev，不在这个窗口。
• sub2api、codex-proxy、codex2api 窗口内零新版本、零新提交，sub2api 主干仍停在 10-25T13:48:55Z。窗口内更新时间变了的几条（#8186、#8204、#8256、#8288、#8289、#8351）没有进本期的条目。
• 上游全绿：OpenAI 状态页最近一条是 10-23 的 CIMD 降级、Claude 状态页最近一条是 10-25 的 Fable 5.1 错误率上升，两条都已恢复；GCP 最近一条仍是 10-22 的 europe-west2。192021
• Codex 重置信号没有变化：最新帖仍是 2026-10-26T06:05:56Z，信号未激活，那句「Lands tomorrow before 10am PST.」就是同一条。22
• 社区没有可核对的额度事实：r/ClaudeAI 窗口内是 S-1 上市与闲聊，r/GeminiAI 是档位抱怨，按排除规则未收。