一个上游 404 锁号 12 小时；sub2api 的心跳把 SSE 帧劈成两半
CLIProxyAPI 把单个上游 404 判成 12 小时冷却，单凭证池随即整池 503；sub2api 的心跳又可能把 SSE 帧劈成两半。本期给出两类症状的判据、逐级处置顺序，以及两条都还没合并的补丁状态。
要处理的两件事都不是上游变了，是两处本地判定写死了。一件把单个上游 404 判成 12 小时冷却，另一件让流式心跳有机会把一帧劈成两半。
两条补丁都开着，一条都没有进发行版。
一个上游 404，把号锁 12 小时
先给判据。客户端连续拿到
503 auth_unavailable: no auth available，错误里带 providers=codex, model=… 与 last upstream error: status 4043。同时上游一次请求都没有。按凭证的请求计数在每十分钟的桶里都是 0，说明请求根本没有发出去。看到这两条，就不必再去查上游了。
根子在冷却分支。v8.0.40 的
conductor_cooldown.go 里，404 一共三处，都是 12 小时：模型支持分支、模型级裸 404 分支、凭证级 applyAuthFailureState4。
sdk/cliproxy/auth/conductor_cooldown.go 第 1078–1086 行：上游没给 Retry-After 时，下次重试被推到 12 小时后。4模型级裸 404 分支的写法最直白：上游没给 Retry-After，就把下次重试时间推到 12 小时后。给了 Retry-After 才按给的秒数算。
凭证级那一处更狠。它没有模型上下文，
case 404 直接写 auth.NextRetryAfter = now.Add(12 * time.Hour)（第 2744 行），锁的是整条凭证，不只是某个模型。为什么 404 会比想象的多？Codex 侧的错误分类把三种错误码映射成 404：
not_found_error、not_found、model_not_found；认不出的落 default，返回 5025。补丁作者说，这条路上不少 404 是上游抖动与模型灰度造成的，而同类瞬时 5xx 只冷却一分钟。冷却之后，所有凭证都不可选时，回执就是那个 5036。单凭证池到这一步就是整池黑，直到有人动手。
今天怎么解
按代价从小到大：
- 单条凭证最轻：
PATCH /v0/management/auth-files/status把这条号关掉再打开。报障人实测这一步立即恢复流量3。v8 的管理组里没有这一条，路由仍在 v07。 - 整池都黑了：重启进程。
save-cooldown-status默认 false，冷却只在内存里，重启即清8。 - 不想动进程：
POST /v8/management/routing/cooldown/reset，body 里带{"auth_index": "..."}；空值回 400，找不到回 4049。 - 别拿
disable-cooling: true换这一条。它关的是全部冷却，429 的额度冷却也一起没了，用尽的号会被反复选中。配置注释写明凭证级的同名设置会覆盖全局值，要单条处理就改那一条8。 - 结构上：池子里至少留两条号。凭证级 12 小时只锁一条，第二条还能接。
补丁改了什么
PR #5514 的标题就是这件事：单个上游 404 改成按分钟冷却，不再 12 小时10。
改法是把一个常量拆成两个。裸 404 走新加的
notFoundCooldown = 10 * time.Minute，显式点名模型的 404 仍走 12 小时，改名 modelSupportCooldown。
sdk/cliproxy/auth/conductor_refresh.go 第 41–50 行：裸 404 与模型支持失败被拆成 10 分钟和 12 小时两个常量。10凭证级那一处没有模型上下文，作者让它一律走 10 分钟；长期判定留给知道模型名的模型级路径。
另外两处改动容易被忽略，却决定这个补丁能不能用。
一处是单调保护。并发在途的失败会乱序回来，一个瞬时 404 不能把先前记下的更晚截止时间改短。
另一处是新加
Result.UpstreamModel 与 RecordWireModelMetadata。payload 规则可能在执行器里改写请求体的 model 字段，别名展开后上游收到的名字与路由名、请求名都可能不同，而结构化 404 报的正是上游那个名字。不记下来，显式 404 会被判成裸 404。补丁在今天 20:35 还落了一笔提交，第 14 笔就是这条别名匹配。现在 27 个文件 +1272/−30，
mergeable_state 是 dirty，也就是还要重基10。原报障单 #5476 早在 2026-09-05 就被关成 not_planned，补丁单则一直开着，31 条行内评审3。
sub2api 的心跳把 SSE 帧劈成两半
症状长这样，是补丁说明里贴的线上帧：
data: {"type":"response.function_call_arguments.delta","sequen:
ce_number":3287,...}心跳写的是一行注释
:。注释行本身合法，解析器本来就该忽略；但这里它不是独立的一行，而是插进了 data: 行的中间。客户端在帧内那个空行处提前提交事件，然后拿到的 JSON 只有半截，报 Extra data。整条回复因此作废。
原因是有两条写通道，中间隔着一个 4 KiB 缓冲。
首个可见输出之前，帧压在 attempt-local 暂存区里；暂存区提交关闭之后，帧改走
bufio.NewWriterSize(w, 4*1024)11。心跳却在那之后仍然直写
w，绕开缓冲。缓冲里只要还有未提交字节，直写就抢在它们前面。
openai_gateway_response_handling.go 第 978–992 行：stageFirstOutput 为真时心跳直写 w，否则退回 writePendingString 走 4 KiB 缓冲。11唯一的守卫
eventInProgress 盯的是上游帧的逻辑边界，看不见下游缓冲里压了多少字节。bufio 写满 4 KB 会自动 flush，切点落在哪个字节与帧边界无关。所以越是长参数的工具调用帧，越容易撞上。
默认值让它变成默认生效。
gateway.stream_keepalive_interval 默认 10 秒12，合法取值是 0 或 5–30 秒。关掉心跳之前先算一笔账
把
stream_keepalive_interval 设成 0 能立刻止血。但心跳当初就是为解决另一个问题加的。同一段代码的注释记了一次生产事故：某部署 12 小时里有 44 个
/v1/responses 请求在 600–900 秒才产出首个可见输出，全被中间层 nginx 的 proxy_read_timeout 600 秒判掉，用户一个字没拿到13。所以要关就一起做：先把中间层读超时抬到盖得住最长思考时间，再关心跳。只关心跳不改超时，等于把偶发坏帧换成稳定长思考被切断。
补丁的两处改动
PR #8320 的第一处是给直写加前提：缓冲为空才允许绕过，否则退回缓冲路径14。
作者补了一句值得记住的：缓冲非空本身就说明流没闲着，这一拍心跳本来也不需要。
第二处更隐蔽。心跳启动时把
c.Writer 换成了带互斥锁的包装器，而透传路径里的 w 是在换之前捕获的裸 writer。继续用
w 写帧，等于绕过包装器的 suspend()，与心跳 goroutine 之间没有任何互斥，两边字节照样能交错到一帧中间。补丁在启动心跳后重新取一次 c.Writer。现在这条单 open，
mergeable_state 是 unstable，3 个文件 +168/−1，含 137 行回归测试14。开单 11 秒后机器人来要 CLA 签名，作者还没回。Gemini 两条新报障
两条都在 Google 官方开发者论坛，都是单个用户、都还没有回复。发帖人不是 Google 员工，这一点先说明。
第一条问的是额度档位15。账号是有效的 Google AI Pro，今天 19:55 发帖，属地在法国，账号不到 5 天，IDE 2.5.5 跑在 macOS 上。
它显示的是 Starter Quota，等待期从 5 小时变成 7 天。发帖人已经试过清缓存、删
~/.antigravity 与 ~/.gemini/antigravity、去 Google 安全页撤销授权后重登、执行 Reset onboarding、无痕窗口、核对订阅状态，全部无效。对运维的意义是判据不同。这类号在池子里表现成「档位不对」，而不是 429；按 429 去调阈值根本对不上。新号先看它显示哪一档、刷新周期是 5 小时还是 7 天，再决定要不要放进池子。
第二条是地区报障16。Windows 上的 Antigravity 2.25.0，Gemini 3.8 Flash High 连一句 hi 都回 400。
报错原文是
User location is not supported for the API use.，状态 FAILED_PRECONDITION。同一条网络上，非 Gemini 模型正常。发帖人核到三件事：账号的 Google 条款页显示日本；代理是 Clash Mi 全局 TUN，出口标注新加坡；
language_server.exe 经这个 TUN 连 daily-cloudcode-pa.googleapis.com:443 与 aicode.googleapis.com:443。它自己给了一句关键限定：账号关联国家不等于请求位置的验证。对中转站来说，Gemini 的判定看的是出口，不是账号资料页上的国家。
要核就核这两个域名的实际出口归属。同网络里非 Gemini 模型能通，也说明整条链路没坏，问题只在 Gemini 这一侧的位置判定。
上游与额度
三家状态页本轮都干净。OpenAI 全系统正常、零降级组件，今天上午那条客服响应延迟（北京 11:41 到 13:58）已经恢复17；Anthropic 全组件正常，页面更新于北京 17:0418；Google Cloud 最近一条仍停在北京 10-23 00:19，窗口内没有新的19。
重置这边，今天还没有全球重置。最近一次已验证落在北京 10-23 01:10，距今 19 小时；累计 57 次、10 次存着20。
另一家把同一次写成「按承诺落地，约太平洋时间上午 10 点」，累计 65 次、中位间隔 3 天21。两家记的是同一次重置，写法不同，不是互相矛盾。
今天那条承诺还没到点。Tibo 在北京 12:47 说「明天太平洋时间上午 10 点前」，换算过来是北京 10-24 01:00。
OpenAI 开发者社区这边窗口内有一条额度相关的新帖：北京 19:23 有人报
Selected model is at capacity22。这和前几期见到的同题报障是同一类，属于上游容量拒绝，不是本地冷却。今天要做的三件事
先把两个判据抄进值班手册：
503 auth_unavailable 加 status 404 是一类，客户端报 Extra data 且帧内有空行是另一类。CLIProxyAPI 遇到第一类，按单条关开、整池重启、最后才动配置的顺序处理。别为了解 404 去开全局
disable-cooling。sub2api 先别急着把心跳关掉。要关就把中间层读超时一起抬起来，否则长思考会换一种方式断。
两条补丁分别在 dirty 和 unstable，都还没进发行版。下一期会跟它们有没有落到 v8.0.41 与 0.2.19。
References
- 1CLIProxyAPI 发行记录
github.com
- 2sub2api 发行记录
github.com
- 3
- 4conductor_cooldown.go v8.0.40
github.com
- 5codex_executor_terminal.go v8.0.40
github.com
- 6auth/errors.go v8.0.40
github.com
- 7server_management.go v8.0.40
github.com
- 8config.example.yaml v8.0.40
github.com
- 9management/quota.go v8.0.40
github.com
- 10
- 11
- 12config.go v0.2.18
github.com
- 13openai_gateway_passthrough.go v0.2.18
github.com
- 14
- 15论坛帖 191839：Urgent Quota Lockout on New Account
discuss.ai.google.dev
- 16论坛帖 191841：Gemini HTTP 400 location error in Antigravity 2.25.0
discuss.ai.google.dev
- 17OpenAI Status
status.openai.com
- 18Anthropic Status
status.anthropic.com
- 19Google Cloud Status
status.cloud.google.com
- 20Codex Reset
codex-reset.com
- 21OpenTherank Codex Reset
opentherank.com
- 22社区帖 1409095：Selected model is at capacity
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.