重登回了 ok，目标号没动；Ultra 档从来不发 5 小时那几行头
一小时窗口里四个仓库都没发版，而发行版里还压着三件真事：按名字重登只有 Codex 生效，Ultra 档的号每次 Fable 周耗尽都会整张凭证被锁，新路由策略名写进去等于轮转——附今晚就能改的开关与一分钟判据。
北京 21:03 到发稿这一小时里，四个仓库都没有新版本：CLIProxyAPI 仍是 v8.0.51、sub2api 仍是 v0.2.19、codex-proxy 稳定版 v2.1.21、codex2api v3.1.2。12
今晚要处理的东西都在发行版里，补丁另算。三件：定向重登对两家 provider 被静默丢弃；Fable 周耗尽后的整号冷却被证实会反复发生，但多了一个能今晚就开的开关；
routing.strategy 里那个新策略名，现在写进去等于 round-robin。上游这小时安静。OpenAI、Anthropic、Google Cloud 三条状态页都没有新事件，Codex 今天 UTC 没有全局重置，最近一次已验证的重置在 10 月 28 日 14:35（北京）。345
一、重登回了 ok，写进去的是另一个文件
带
name 调 POST /v8/management/oauth/auth-url，是面板上「重新登录某个号」的标准动作。这个参数只有在 Codex 那条路上被真正读走。StartOAuthV8 对所有 provider 都解析 name / target_auth_id / auth_id，然后按 provider 分派。6 分派之后，整仓只有两处读 oauthSessionTargetFromContext：Codex 的 RequestCodexToken，以及插件回调那条路。7
internal/api/handlers/management/auth_files_provider_oauth.go 第 243–252 行：RequestCodexToken 在第 246 行取会话目标、第 248 行存进 state。7RequestAntigravityToken 与 requestKimiTokenWithDomain 都没有这一句。它们照常登录、照常写文件，只是目标参数被丢在一边。
time.Now().UnixMilli() 拼出，第 1046 行。9报障人把两种结果都跑出来了：Kimi 连续两次定向登录，目录里从 1 个文件变成 3 个，目标文件字段一字未改；Antigravity 目标写的是
a@x.test，登录完成在 b@x.test，于是多出一个 antigravity-b@x.test.json，接口照样回 {"status":"ok"}。10面板与脚本读到的信号也一致地「成功」：这两家的启动响应里没有
target_auth_id 字段，轮询状态就是一句 {"status":"ok"}。verify=true 同样只被读进那个没人用的目标里。谁会踩到：把「重新登录」当换号手段的站点。批量重登脚本更糟，跑一轮就多出一批没人认领的凭据文件，而旧号还带着坏 token 继续被选中。
一分钟能做完的判据有三条。启动响应的 JSON 里有没有
target_auth_id；完事之后 auth-dir 里的文件数有没有 +1；目标文件的字段或哈希有没有变。三条里前两条任一命中，这次重登就没落到目标上。今晚的处置：Codex 继续用
name；Antigravity 与 Kimi 重登完先数文件，多出来的新凭据要么合并、要么删掉，再把旧文件移出 auth-dir 让它退出候选，别指望它被原地覆盖。这条单开在北京 20:59，到发稿为止 0 评论、没有补丁，也没有人开 PR。10
二、Fable 那条会反复发生：Ultra 档从来不发 5 小时头
今天上午这一栏讲过这条单的机制：Fable 周额度耗尽后，上游只拒 7 天那一档，5 小时那一族响应头缺席，本地判定认不出「只是 Fable 没了」，于是把整张 Claude 凭证按额度耗尽锁住。
21:46 新到的一条评论补上了两块关键事实。11
第一块是范围。这位运维的号是 Max 20 / Ultra 档，这一档已经没有 5 小时窗口，所以 5 小时那几个头在这些号上从来不发——不只是窗口没用到的时候不发。11 换句话说，只要号在 Ultra 档，每一次 Fable 周耗尽都会走这条路。
第二块是实测时间线。11 月 2 日 01:05:55（北京），该号一次
claude-fable-5-1 请求回了 429；此后打到这张凭证上的 claude-opus-5-5、claude-sonnet-5-5、claude-haiku-5-5 全部回 503，原因写着 credential_quota，剩余 55 小时 47 分，所有模型的截止时间都落在 11 月 5 日 05:00（北京）前后。同一时段，该号共享的 7 天窗口还剩约 9%，claude.ai 上用同一个号开 Opus 一切正常。11他给出了一个能今晚就开的开关：
upstream.claude.model-level-cooling: true。这一项在 v8.0.51 的配置样例里就有，默认 false，位置在 upstream 段的 claude 之下。12
internal/runtime/executor/claude_executor_request.go 第 807–826 行：第 816 行的 !modelLevelCooling && 就是那个闸门，只有它为假时才会把 429 标成整张凭证的范围。13代价先说清楚：打开之后，所有 Claude 429 都按模型范围记。真遇到整号额度耗尽时，本地不会再用一张 503 提前挡住兄弟模型，那些请求会各自撞一次上游 429。换来的是 Fable 这类单模型拒绝不再拖累整张号。
它也不回溯。已经被锁住的凭证，开关打开后仍停在原冷却里，要清掉只有两条路：
POST /v8/management/routing/cooldown/reset 带 auth_index，或者面板上那张 auth 文件的 Clear cooldown。14如果只想让 Fable 别碰池子，另一条更窄的路是把
claude-fable-5 与 claude-fable-5-1 写进 oauth.excluded-models，这两个模型就不进候选。三、routing.strategy: soonest-reset 今晚写进去等于 round-robin
这个策略名的吸引力很直白：谁的周窗口最早重置，就先用谁的额度，避免一个快重置的号带着余额过期。cliproxy-rs 已经支持它，读的是同一份
config.yaml。15Go 这边还没认。
normalizedRoutingRuntimeState 的 switch 只匹配 weighted-round-robin 与 fill-first，其余值一个都不改，初始值就是 round-robin；newRoutingSelector 的 default 分支落在 RoundRobinSelector。16
sdk/cliproxy/service_config.go 第 73–110 行：第 77 行只列了两个 case，第 108–109 行的 default 是 RoundRobinSelector。16同一份配置在 cliproxy-rs 上按「最早重置优先」排，在 Go 上按轮转跑。两台机器共用一个
config.yaml 的站点，今晚就会看到两种分配结果。PR #7206 在北京 21:44 开出，19 个文件 +2643/−4，仍在评审。15 在那之前，按重置时间排序只能靠外部脚本改
priority 或 weight，PR 作者自己也说这种做法有竞态。四、自旋那条有了补丁，仍然只是补丁
今天凌晨讲过的那条还在：被禁用的 Codex 号，refresh token 已被判终局失败，access token 还没过期且落在 96 小时的提前刷新窗口里，自动刷新循环就会零延迟空转。表现只有 CPU——一台 darwin/arm64 机器上单张凭证把进程顶到 150–190%，把那个 auth 文件移出
auth-dir（不用重启）立刻掉回约 20%。1821:52 有人开了补丁：PR #7207，3 个文件 +86/−0，改三处。19 一是被禁用凭据的终局失败分支改成把下次刷新推到 access token 过期（或直接不排期），二是提前返回「需要重新登录」时同步更新
NextRefreshAfter，三是循环重排时保证下次时间严格晚于当前。作者给的对照数字是 500 毫秒内 83,940 次 generation bump 与修复后的 1 次。今晚动手清单
- 有重登脚本的站点：对 Antigravity 与 Kimi 的重登看启动响应有没有
target_auth_id，完了数一次auth-dir文件数。 - 跑 Claude 池的站点：决定是开
upstream.claude.model-level-cooling: true，还是把claude-fable-5系列从oauth.excluded-models里排除。 - 已经被锁的 Claude 号：用
POST /v8/management/routing/cooldown/reset或面板 Clear cooldown 清一次，别等 76 小时。 - 想用
soonest-reset的：今晚先别写；或者确认自己跑的是 cliproxy-rs。 - CPU 高但流量不大、日志又不报错的实例：翻一遍有没有「禁用 + refresh token 终局失败」的号。
行情
四个仓库这一小时都没有新版本，
dev 与 main 也没有新合并。CLIProxyAPI v8.0.51 发布于 11 月 2 日 01:08（北京），sub2api v0.2.19 发布于 10 月 28 日 18:16，codex-proxy v2.1.21 发布于 10 月 28 日 04:48，codex2api v3.1.2 发布于 10 月 28 日 04:40。12References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3OpenAI Status
status.openai.com
- 4Anthropic Status
status.anthropic.com
- 5Codex Reset Tracker
codex-reset.com
- 6auth_files_v8.go 第 133–141 行
github.com
- 7auth_files_provider_oauth.go 第 246 行
github.com
- 8antigravity/filename.go 第 10 行
github.com
- 9auth_files_provider_oauth.go 第 1046 行
github.com
- 10issue #7204
github.com
- 11issue #7197 评论
github.com
- 12config.example.yaml 第 458 行
github.com
- 13claude_executor_request.go 第 808–824 行
github.com
- 14management quota.go 第 28 行
github.com
- 15PR #7206
github.com
- 16service_config.go 第 77–110 行
github.com
- 17config.example.yaml 第 161–163 行
github.com
- 18issue #7183
github.com
- 19PR #7207
github.com
- 20CLIProxyAPI dev 分支提交
github.com
- 21Google Cloud Status
status.cloud.google.com
- 22OpenTherank Codex Reset
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.