先烧最早重置的那张号：一条新路由策略刚过评审，发行版里还没有
CLIProxyAPI 那条「先烧最早重置那张号」的路由补丁评审清零，仍卡在 dev 之外；本期给出它的排序规则、两处会咬人的边界、作者 17 小时实测数字，以及上一期流式排空补丁被重写后新挂的那条 P2。
这个窗口里，CLIProxyAPI 没有发新版。动过的只有两张补丁：一条「先烧最早重置那张号」的路由策略，评审已经清零；上一期报过的那条流式排空补丁，被作者整个重写了。
先把这条策略说清。订阅号的周额度各到期各的，谁先到期，谁手上剩下的额度就作废。这条策略的做法是：谁的周窗口先重置，就先烧谁的号，烧穿了再换下一张。1
07:34（北京），自动评审重跑，四条意见全部清零，未解决项为 0。1
补丁仍开着，目标分支是
dev，18 个文件 +2685/−4，五笔提交，维护者还没有表态。v8.0.53 里没有这段代码。一屏判定
| 你的情况 | 现在是什么状态 | 今晚能做什么 |
|---|---|---|
在 v8.0.53 上配了 routing.strategy: soonest-reset | 这个名字不被识别，实际按 round-robin 跑 | 按轮转的脾气算余量，配置先留着 |
用外部脚本每分钟改 weight，把号提前停在某个百分比 | 这条策略想替掉的就是这套脚本 | 脚本可以停，但换代之前继续用 |
| 想今晚就拿到这个排序 | 没有 tag 带它，只能从 PR 头分支自己构建 | 构建后 priority 仍然优先于重置排序 |
| 号池里既有周窗口又有短窗口的 Codex 号 | c3a4f7e 修的就是这个判定 | 用新提交构建，别用 11-03 之前的头 |
这一步补的是「哪边是周」
Codex 号身上有两个用量窗口，primary 与 secondary。哪个是周额度，看响应头里的
Window-Minutes。上一版只比较两边都带长度的情况。只要有一边缺，一律把 secondary 当周。4
feat/soonest-reset-routing，文件 sdk/cliproxy/auth/selector_soonest_reset.go 第 322–355 行。4新写法分四条：两边都带长度时取较长的；只 primary 带，就按 24 小时这条界判；只 secondary 带，则反过来推 primary；两边都不带，仍按 secondary。
这条错了会怎样？真实的周重置还在几天后，却被判成几小时后，这张号就排到队首先被烧。5
评审给出的例子是 primary 报 10080 分钟、secondary 只报一个很短的间隔，旧代码于是拿 short 那一侧当周。
作者补了五个用例，其中两个「只有一边带长度」的用例在上一笔提交上会失败。
排序怎么走，两处会咬人的边界
候选集的收窄方式与
fill-first 一致：先取可用的最高优先级层，再在这一层里按重置时间排。层内四档：已用尽且还没重置的排最后；周重置未知、本轮又没探过的，给一次请求去探；已知重置的按最早优先；探过仍然未知的，排在已知之后。同档保持传入顺序。
探针记录有上限，到顶之后既不淘汰也不再探新号。6
feat/soonest-reset-routing，文件 sdk/cliproxy/auth/selector_soonest_reset.go 第 44–52 行。6InvalidateAuth 是唯一能让名额重新空出来的路径。探针记录只存在内存里，重启后每张号再各探一次。第二处边界在调度器那边。这个选择器被登记成内置选择器，而调度器快路径只模拟轮转与 fill-first。
feat/soonest-reset-routing，文件 sdk/cliproxy/auth/conductor_selection.go 第 1812–1821 行。7也就是说，「上游到底发不发这两个长度头」可以自己抓一次响应看，不必等升级。
4 个号跑 17 小时
作者拿四个 Claude OAuth 号跑了约 17 小时，替换掉原来那套每分钟改 weight 的脚本。1
| 观察项 | 换之前（加权轮转 + 脚本，24 小时） | 换之后（17 小时） |
|---|---|---|
| 最早重置那张号（开局 97%） | 被脚本提前停调约 27 小时 | 跑到重置前 5 分钟才失败切换 |
| 6–7 天后才重置的号 | 拿走 40% 流量 | 约 0%，留着没动 |
| 客户端看到的 429 | 0 | 0，一次上游 429 被透明重试 |
| 重启后 / 滚动后的探测 | — | 每号恰好 1 次 |
这组数字的分量在于第二行。那 40% 的流量烧在六天后才重置的号上，等于把能用的额度用在了不着急的地方。
它的边界也要说清：四个号、一个 provider、17 小时、作者自测，没有第二方复现。
换号之后读不了上一个号的东西
会话跨到另一张号上时，上一张号加密过的内容，新号解不开。
原文给的例子是 Claude Code 的 advisor 结果，返回
400 Advisor tool result content could not be processed，客户端下一轮自己恢复。1作者写明这跟策略无关：故障切换、亲和过期、重启都会撞上，任何策略都一样。
这条策略让它变成每周必现一次——号烧穿的那一刻就是换号。
上一期那张排空补丁被整个重写
新做法三步：先关下游的
Chunks，再排空上游；排空仍限 64 KiB；上游请求换成一个可分离的 context。那个 context 只在
message_stop 之前跟随下游取消。之后分离，排空才跑得完。07:21（北京），评审又提了一条新的 P2。11
理由很具体：
context.AfterFunc 在父 context 已经取消时，是在另一个 goroutine 里调 cancel。于是这个 helper 可能带着
ctx.Err() 为 nil 返回，ExecuteStream 立刻把它交给 http.Client.Do，一次已经放弃的请求照样发出去。作者 07:22（北京）的回复针对的是上一条 P2，讲排空顺序。这条新的还没人应。12
版本位与其余三仓
四个仓库在这个窗口里都没有发版。
上游
OpenAI 状态页全绿，组件全部 operational，没有进行中的事故。17
最近一条还是文件上传报错，11-03 08:46 至 13:39（北京）已恢复。
Anthropic 全绿，窗口内没有新事件。18
Google Cloud 最新仍是 10-28 那条多产品事故，没有新进展。19
Codex 重置信号安静：
signal.active 为 false，今日 UTC 尚未重置。20最近一次已验证的全局重置是 10-28 14:35（北京），距今 7 天，累计 61 次。
首页那句正好是这条策略的前提：没有一个人人共享的周重置时刻，每张号的窗口锚在自己上一次重置后的第一个请求上。
今晚三件
第一件，对一下自己的配置。在 v8.0.53 上写
soonest-reset 等于什么都没做，实际跑的是轮转。先知道这件事，才能算准余量。第二件，抓一次上游响应。看两个
x-codex-*-window-minutes 在不在。这两个头不来，这套排序就没有判据，装了也排不出来。第三件，要现在就用。没有 tag 可升，只能从 PR 头分支构建；构建前把
priority 那一条想清楚——它仍压过重置顺序。不想自己构建，就等它合进 dev 再说下一班车。References
- 1
- 2c3a4f7e 提交
github.com
- 3作者对最后一条评审的回复
github.com
- 4
- 5评审意见：用已知长度判定部分窗口
github.com
- 6selector_soonest_reset.go 第 44 行至第 52 行
github.com
- 7conductor_selection.go 第 1812 行至第 1821 行
github.com
- 8v8.0.53 service_config.go 第 66 行至第 110 行
github.com
- 9v8.0.53 quota_signals.go 第 200 行至第 210 行
github.com
- 10CLIProxyAPI PR 7237
github.com
- 11
- 12作者对排空顺序那条的回复
github.com
- 13CLIProxyAPI v8.0.53 发行页
github.com
- 14sub2api 发行列表
github.com
- 15codex-proxy 发行列表
github.com
- 16codex2api 发行列表
github.com
- 17OpenAI 状态页
status.openai.com
- 18Claude 状态页
status.claude.com
- 19Google Cloud 状态页
status.cloud.google.com
- 20codex-reset 追踪页
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.