能服务的 6 个号全进冷却后，那 6 次 404 只留在用量流里
这一小时四个仓库零发版：能服务某个模型的号全在冷却之后，请求被派到服务不了它的号上，6 次 404 只留在用量流、文本日志里一条都没有，而本地给裸 404 定的价是 12 小时——另附两条今晚能改的配置和 sub2api 两处记账与端点问题。
这段时间（北京 10-29 20:18 到 23:15）四个仓库都没发新版本：CLIProxyAPI 停在 v8.0.47、sub2api 停在 v0.2.19、codex-proxy v2.1.21、codex2api v3.1.21234。
CLIProxyAPI 的 dev 分支也没动，仍停在上期记下的 d30edd7f5。所以今晚没有要升的版本。codex-proxy 与 codex2api 这一小时也没有新条目，两个仓库不用动。
今晚该查的是另一件事：能服务某个模型的号全被冷却按住之后，请求去了哪儿，日志里为什么看不见。
六次 404 只留在用量流里
晚上 23:00（北京）CLIProxyAPI 开出一张单，讲的是 Antigravity 多号池6。
账号形状很清楚：一个实例 15 个 Antigravity 号，其中 6 个能服务
claude-opus-5-5-high，6 个不能，另外 3 个两边都不在。能服务的 6 个全部进了额度冷却之后，同一条客户端请求在 5 秒内打出 6 次 404，每次换一个不能服务的号。
上游对每一次都回同一句：
Requested entity was not found.，状态是 NOT_FOUND。同一份用量库里这样的 404 累计 96 次，16 次落在同一个号上。
而
main.log 里一条 NOT_FOUND 都没有，只有一句冷却告警：auth unavailable: 6 of 6 candidate(s) for model "claude-opus-5-5-high" ... are in cooldown这句告警自己就把一半事实说了。那个 6 of 6 是通过模型能力过滤之后的候选数，不是池子里的账号总数7。
也就是说，本地认为能服务
claude-opus-5-5-high 的号有 6 个。这 6 是候选集，不是整个号池。而 404 是 21:07:08 到 21:07:13 之间打出去的，那几秒里这些号还在被派出去执行。两条记录放在一起，顺序只有一个：先被选出去撞了 404，之后才全进了冷却。
sdk/cliproxy/auth/conductor_selection.go 第 2522–2550 行：能力过滤在计数之前，所以「6 of 6」数的是能服务的号7先排除「重试把请求甩到别的号」
有两处代码可以先把这条直觉解释排掉。
选号失败时，执行循环直接返回错误，不再换号执行8。
而 404 压根不在重试轮次认的状态码里：那张名单是 403、408、429、500、502、503、5049。
404 不触发下一轮，所以那 6 次不是重试打出去的。它们是被当成候选正常选出来、再执行出去的。
剩下要查的只有一处：本地对这几个号的模型能力判断，跟上游不一致。
判定链有两段。registry 的客户端模型表里没有登记的号一律判为不支持10。
调度分片也按同一份集合建，只把「支持这个模型」的号放进去11。
所以只要那几个号的表里写着
claude-opus-5-5-high，它们就会一直留在候选里，直到上游用 404 告诉你不是。一次误判要付 12 小时
本地给裸 404 定的价是写死的。
上游没点名哪个模型不支持、也没给
Retry-After 时，那个号在这个模型上被按住 12 小时12。
sdk/cliproxy/auth/conductor_cooldown.go 第 1096–1118 行：401/402/403 是 30 分钟，404 是 12 小时，除非上游给了 Retry-After12Requested entity was not found. 这句话不在本地认的「模型不支持」名单里。那份名单是十来种写法，比如 model not supported、not available for your plan13。所以它走的就是那条 12 小时，不会走模型不支持的短路径。
这里有一处对不上，得先查。如果每次 404 都真被按 12 小时，同一个号一天里不该被再选中 16 次。
两种可能：那台实例把冷却关了，或者跑的是已带上
#5514 的构建。开单前先看该号模型状态里的 next_retry_after 有没有被写。routing.cooldown.disable-cooling 打开时这段不生效，代价是另一个方向：所有失败都不再隔离。想把 12 小时缩到分钟级，有一张单从 9 月 4 日开到现在：裸 404 改成 10 分钟，只有明确点名模型的 404 保留 12 小时14。
它今天 21:34（北京）又动过一次，仍未合并，27 个文件 +1320/−29。
今晚的四步
第一步，确认有没有中招。去用量事件里筛
result=404 且模型相同的记录，别去 main.log 找，那张单已经证明那里没有。第二步，修能力表。OAuth 账号的排除名单写在
oauth.excluded-models.antigravity15，或写进该凭证文件的 excluded_models；凭证自己那份非空时优先，不与全局合并。这是根治，其余都是止血。改完要验一句：再看告警里那个分母，它变小才算真的进了候选过滤。
第四步，别调
max-retry-interval。它管的是「为冷却最多等多久」，默认 30 秒17，改它不会动 404 记 12 小时这件事。影响面要说清楚：一个实例挂多个 Antigravity 号、且某个模型只有部分号能服务时才会撞上。
带档位后缀的 Claude 模型最容易撞，因为同名模型在不同号上的可用性差得最明显。
两张未合并的 PR，改的是冷却后的两头
同一小时里 CLIProxyAPI 还开了两张 PR，方向正好互补。都还没合。
关着的时候行为不变。打开后按最近一次周配额重置挑号，并把两种失败拆开。
额度真用完：429 加
claude_quota_exhausted，带真实的 reset_at。观测不到可用性：503 加
claude_quota_unavailable，带 next_check_at。两者都带重试提示，而且在不开启上游响应头透传时也保留。作者自述没有做真实模型请求与部署验证。
这条回落同时作用于 Claude OAuth 的 uTLS 传输，以及按
effectiveProxyURL 取代理的执行器。优先级没变：请求级 > 认证文件 > 配置文件
proxy-url > 环境变量。所以在 Docker、K8s 或公司网络里只写环境变量、把
proxy-url 留空的部署，Claude OAuth 与执行器现在走的是直连。合并前唯一的办法，是把代理写进
proxy-url。sub2api：两条都在运维手上
第一条是记账。
#8419（北京 21:45 开，open）讲的是：请求已经发到上游、还没回的时候，把 API Key 删掉20。结果是这次请求的用量记不上：
usage_log 里费用 0、余额不减。评论给了可复制的报错。报错长这样：
gateway.record_usage_failed ... model=claude-fable-5-1 error=code=404 reason="API_KEY_NOT_FOUND"，落在 gateway_handler.go:966。这个错误就是「密钥不存在」，定义在
api_key_service.go 第 27 行21。有一处容易看漏：结算里对「密钥已不存在」本来是有显式容错的——Key 自己的额度与限速计数跳过，其余结算项照做22。
backend/internal/repository/usage_billing_repo.go 第 186–206 行，v0.2.19：容错只覆盖 Key 自身的两笔计数22整笔记账失败，说明中断发生在容错之外。不管在哪一处，处置是同一个方向。
今天的做法：要停一个 Key 先禁用，别直接删；确实要删，等它手上没有在飞的请求。
已经发生的，去
usage_logs 找费用 0、但 token 计数不为 0 的行，那些是本该扣没扣的。第二条是 Cloudflare。
#8420（北京 22:08 开，6 个文件 +216/−3，mergeable unstable，base main）让 Cloudflare 的 REST messages 端点别再带 beta=true23。
backend/internal/service/gateway_upstream_request.go 第 996–1012 行：beta 画在字符串里，没有开关；Anthropic 直连与 count_tokens 两条路同样硬编码24Cloudflare 的
/ai/v1/messages 不认这个查询参数，直接回 400 unrecognized_keys ["query"]。今天没有开关。把 Cloudflare AI Gateway 的 REST 端点接到 Anthropic API Key 账号上就会撞 400，要接就等合并与发版。
上游与重置
三家状态页都干净。OpenAI 全绿、没有降级组件，最近一条事件是 10-27 的 6.1 Sol 降级26。
codex-reset 首页仍写今天 UTC 没重置：最近一次已验证的全局重置在 33 小时前，累计 61 次、10 张 banked，24 小时给 46%、48 小时 71%29。
官方社区 Codex 分区 22:34（北京）有一条新帖，报近两周持续的容量报错，并称选 GPT-6 Astra 或 6.1 Sol 时实际由 5.6 Terra 处理30。
这是用户侧观察，帖子只有 16 次浏览、无官方回复。要核自己有没有中，比响应体里的
model 字段最直接。它和
#7105 可以并读：上游现在用「这个号没有这个模型」和「这个模型满容量」两种说法把请求推回来，本地则各自记成 404 与 429。sub2api 另开一条功能请求
#8421（北京 23:01）：给 OpenAI OAuth 母账号加「重置卡到期前自动使用」，默认关、默认提前 1 小时31。只登记，不当修单。References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI dev 提交记录
github.com
- 6issue 7105
github.com
- 7conductor_selection.go 第 2522–2550 行
github.com
- 8conductor_execution.go 第 544–549 行
github.com
- 9isCredentialRetryRoundStatus
github.com
- 10ClientSupportsModel
github.com
- 11ensureModelLocked
github.com
- 12conductor_cooldown.go 第 1096–1118 行
github.com
- 13isModelSupportErrorMessage
github.com
- 14PR 5514
github.com
- 15oauth.excluded-models 示例
github.com
- 16ResetQuota
github.com
- 17config.example.yaml 第 200–222 行
github.com
- 18PR 7104
github.com
- 19PR 7103
github.com
- 20issue 8419
github.com
- 21ErrAPIKeyNotFound
github.com
- 22usage_billing_repo.go 第 186–206 行
github.com
- 23PR 8420
github.com
- 24gateway_upstream_request.go 第 996–1012 行
github.com
- 25issue 8274
github.com
- 26OpenAI Status
status.openai.com
- 27Claude Status
status.claude.com
- 28Google Cloud Status
status.cloud.google.com
- 29Codex Reset
codex-reset.com
- 30社区帖 1410767
community.openai.com
- 31issue 8421
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.