disable-cooling 打开时，一个下架的模型让同一张凭证每秒被重试

关掉冷却之后，永久错误也不再被记账

三分钟自查

• 配置：grep -rn "disable-cooling" config.yaml。命中全局那一行，或者某张凭证下的 disable-cooling: true，就有嫌疑。
• 冷却表：GET /v8/management/credentials 每条凭证带一个 cooldowns 数组，元素形如 {scope, model_key, reason, retry_at, remaining_seconds}。78
• 撞上这条洞的模型，在 cooldowns 里查不到条目：它被判成可用，就没有冷却可报。真的按 12 小时生效时，这里会有一条 scope: model、reason: model_not_supported、remaining_seconds 接近 43200 的记录。
• 日志：同一个模型名反复 404，而冷却表干净，基本就能对上。

今晚能做的

1. 把会撞下架模型的那张凭证改回 disable-cooling: false。解析函数先读单凭证覆盖、再读全局，所以其他凭证继续不受冷却影响。6 代价是这张凭证重新有冷却，当初想躲掉的黑屏期会回来。
2. 把下架模型从这张账号的可用模型里摘掉。选号阶段就排掉它，请求不会再打到不存在的模型上。代价是还在调用它的客户端直接拿到 404。
3. 等 #7019 进版。它把这条分支的 12 小时改成无条件执行，测试里的期望值也一起改成约 12 小时；目前仍是 open。1

补丁没堵住的两处

• 模型级的通用 404，第 1078–1086 行，关掉冷却时同样清零。9
• 凭证级的 404，第 2768–2776 行，12 小时同样只写在 else 里。这一支在失败记到整张凭证时才走，清理动作放在一个 defer 里，效果一样。10

同一小时里的另外三件事

interactions 的图片请求，v8.0.44 仍被一句 stream 打回

Meta 的订阅额度只活在一次流里

codex-proxy 的桌面端内更新只进了 dev

sub2api #7962 重基到 0.2.18

版本面

• CLIProxyAPI v8.0.44 于北京 10 月 26 日 23:49 发出，tag、main、dev 是同一个提交 1f917e77；窗口内零新提交。2
• sub2api 仍是 v0.2.18（北京 10 月 23 日 15:44），主干停在 10 月 25 日 21:48。22
• codex-proxy v2.1.20（北京 10 月 23 日 03:56）、codex2api v3.1.1（北京 10 月 17 日 05:42），两仓窗口内零新版本。2324
• 上游全绿：OpenAI 没有活动事件，最近一条是 10 月 24 日早上的 CIMD 降级；Claude 全系统正常，最近一条是 10 月 25 日的 Fable 5.1；GCP 八条记录里最新仍是 10 月 22 日的 europe-west2。252627
• 重置信号没动：最新帖仍是 10 月 26 日 14:05 那条「Not enough resets」，signal 未激活，10 月 23 日、25 日、26 日三条事件都还挂着 pending。28

今晚要做的三件事

1. 查 disable-cooling。开着它的站，先确认有没有哪个模型已经下架。
2. 用 GET /v8/management/credentials 看 cooldowns。模型撞了 404 却查不到冷却条目，就是这条洞。
3. 要把图片走 interactions 的请求先改道 :generateContent，或者干脆走流式。