auth 文件原地重写一次，新凭证就继承了旧号的冷却与最后错误
CLIProxyAPI 的文件快照携带逻辑会把旧凭证的冷却、最后错误与不可用状态搬给同一路径下新换的凭证，v8.0.40 就在现网；本期给出触发条件、三步处置与补丁状态，另附一处无锁读与 sub2api 推理强度映射的补丁。
北京时间 12:46，CLIProxyAPI 上来一张单，标题本身就是结论：被重写过的 auth 文件会继承旧凭证的运行时状态。1
昨天凌晨那期写的是同一处代码的反面——文件快照会把刚写下的冷却整段抹掉。补上之后，它开始把旧冷却搬给新凭证。
这段代码在 v8.0.40 与 dev 上逐字节相同，现网就在发生。
作者 eaxeax 自己划了边界：这份单不主张生产命中频率，测试只在 macOS 上跑过，Linux、Docker 与全量测试都没跑。他把 PR 里那 18 个测试原样拷到 dev 上，14 个失败。1
同窗口还有两件事：PR #6907 是一处没在锁里读的 metadata，sub2api 上一期那张推理强度映射有了补丁。
窗口是北京时间 11:40 到 12:55。四个仓库没有新版本。
一、状态是怎么搬过去的
搬状态的那笔提交是
d5816d5e，10 月 22 日上午落进 dev，13 个文件、+1195/−11，标题写着「preserve runtime cooldowns on file snapshots」。2处理一次文件快照重写时，它先跑一道校验：
FileSnapshotMatchesDisk，确认这份快照正是磁盘上的那一份。3这道校验看的是文件有没有被动过。文件里的凭证换成了谁，它不看。
确认完就开始赋值。第 384 到 388 行把模型状态、上次刷新时刻、下次刷新时刻、刷新失败次数换成旧的；第 392 到 408 行把状态、状态说明、
Unavailable、NextRetryAfter、LastError、Quota 与 cooldownRecordedSeq 换成旧的。
sdk/cliproxy/auth/conductor_lifecycle.go 第 375–408 行：第 376 行的 credChanged 是这条路上唯一的身份判据，第 384–388 行搬模型级状态，第 392–408 行搬凭证级状态；只有第 410 行那句 credChanged || mode == updateModeRefresh 成立，才会往下清 401 类失败并恢复状态。你要对上的只有一件事：文件名没变。
ID 由相对 auth 目录的路径生成，与文件内容无关。4 同一个
codex-01.json 里不管换成谁的 token、谁的账号、哪个项目，在管理器眼里都是同一张凭证。二、身份判定只看令牌
CredentialsChanged 的整份清单是：access token、外层 access token、refresh token、id_token、api_key、SIWC 的 access / refresh / id_token / client_id 四个字段，最后加一个 use_siwc 开关。5这份清单覆盖的是令牌类字段。provider、Codex 的
account_id、Vertex 的项目与服务账号，都落在清单之外。于是「同一份 OAuth token、换了个 codex 账号」被判成没变，
CredentialVersion 停在 1。6
sdk/cliproxy/auth/conductor_refresh.go 第 453–495 行：第 458 行比两个 access token，第 461 行比 refresh token，第 472 行比 id_token，第 489 行比 api_key，第 492–495 行比 SIWC 那四个字段。整份清单里没有 provider，也没有 Codex 的 account_id。按重写方式分，作者列了五种后果：
- 换成另一个 provider：冷却与额度留着。
- 同 provider、换了 access / refresh token：那次非 401 的刷新失败留着。
- Codex 换了
account_id、token 没变：失败留着，而且CredentialsChanged看不见这次变化。 - Vertex 换了服务账号或项目：失败留着；两份都不一样、都不合法的服务账号，还会被判成相等。
- 插件凭证的身份只在
StorageJSON里：存储轮换后失败留着；只差在 2^53 以上的 64 位数字，会因为 float64 归一化被判成相等。
三、迟到的那次 401 落到新号头上
判陈旧的函数里，第 869 行比的是令牌：
authMatchesTokenPartition 在当前凭证的两个分区里找一遍。7令牌没变，这一条就成立，版本比较根本轮不到。8
sdk/cliproxy/auth/conductor_cooldown.go 第 860–878 行：第 865 行先比注册代，第 869 行只要结果里的 access token 与当前任一令牌分区相同就直接 return false（不判为陈旧），版本比较排在它后面。于是在途的那次请求会这样收尾：请求是在旧账号上派出去的，文件在同 token 下换了
account_id，请求回来说 401。这一条被当成有效结果记下来，把新账号标成不可用。Codex 的两个令牌分区（外层令牌与 SIWC 令牌）都成立。换成 provider 的话，旧 provider 的一次迟到 429 会落到新 provider 上。
四、今天能做的三件事
换凭证就换文件名。 删掉旧的
codex-01.json，写到 codex-02.json。ID 随路径变、冷却文件也随文件名变，这条继承路径就绕开了。已经中招的，按
auth_index 调一次重置。 管理端有 POST /v8/management/routing/cooldown/reset，body 是 {"auth_index": "..."}，它会把这条凭证的模型态与冷却一起清掉。9有一类清不掉：如果继承过来的那条
LastError 是 401 终态，clearCooldownStateForAuth 第一件事就是返回 false。10 这时重置接口会成功返回，状态却还在，只能删文件重写。开着冷却落盘的，顺手清掉那一份。
routing.cooldown.save-cooldown-status 打开时，冷却按凭证写成一个 .cds，文件名取自 auth 文件名。1112 旧的 .cds 留在目录里，重启会把旧号的冷却重新读回来。真正的修法在 PR #6853：仍开着，7 个文件、+946/−8、mergeable clean，改法是给携带加一道身份前置条件，并给「同 token 换号」记一个运行时版本，让上面那条令牌快路不再一票通过。13
五、次条：一处没在锁里读的 metadata
internal/runtime/executor/claude_executor_auth.go 第 32–51 行：第 37、40、43 行直接按 key 读 metadata，第 49–51 行改用带锁的 ReadMetadataString，同一个函数里两种取法。Go 运行时碰上 map 并发读写会直接 abort：进程退出，客户端拿不到任何响应。
影响面要说准。常规代理这条路上，每条请求拿的都是副本，不共享这张 map。16 作者也是这么自限的：只有直接调执行器的嵌入式用法才够得着。跑标准代理的可以等，嵌进自己服务里的要留意。
六、sub2api：上一期那张单有补丁了
上一期写过的 #8308，聚合分组把推理强度映射静默丢掉，现在有 PR #8309：作者 wucm667，12:14 提，6 个文件、+201/−16，open、mergeable clean。17
平台闸从「只放行 openai / anthropic」改成「anthropic 或国产多协议平台」。补丁的测试把 DeepSeek、Kimi、智谱、MiniMax 逐个按
IsCNProvider 判过，OpenCode Go 这类非国产目标维持原行为。原生 Anthropic 直通现在会在模型改写之前应用映射、上限与拒绝；命中拒绝时直接回 Anthropic 格式的 403，不向上游发请求。用量里分别记映射前与转发后的强度，面板上能看出
low ↳ max。补丁里还有一件与推理强度无关的改动：前端 DOMPurify 升到
^3.4.17，并在 pnpm-lock 里加了低于该版本的强制覆盖。作者的说法是「完整检查时发现现有版本触发新的高危告警」。这些都在本地验过，作者没做在线供应商验证。补丁未合，今天仍要按上一期的结论办：客户端自己带 effort。
七、版本、上游与额度
四仓零新版本。CLIProxyAPI 仍是 v8.0.40（北京 08:10 发布），main 停在 08:09，dev 头 11:36 的
41a4b9f4；sub2api 仍是 v0.2.17，主干停在 10-22 10:33。1819两条旧单有了结局。10-22 凌晨那期写过的 #6854（uTLS 诊断日志）11:42 被关掉、没有合入；v8.0.40 的传输层仍然只在代理拨号失败时写一行 Errorf，握手失败没有日志，整包搜
dial_ms / tls_ms 零命中。22 同一批被关的还有 #6840、#6841、#6842，也都没合。上游 11:41 新开一条事件：「Delays in customer support responses」，12:43 更新为 identified，影响级别写 none，组件列表是空的。23
它影响的是支持系统；API 面全绿，没有降级组件。24 按支持面事件处理即可，上游 API 这侧不受影响。
Claude 与 Google Cloud 窗口内都是干净的。
额度侧两站口径不同，别混用。codex-reset 首页写今日 UTC 尚未重置，最近一次已验证的全局重置是 12 小时前（北京 10-23 01:10），累计 57 次、10 张 banked、节奏约每 2 天。25
opentherank 记 65 次、中位间隔 3 天、最长 68 天，同一次重置它记成 10-22 17:00 UTC，与 codex-reset 的 17:10 差 10 分钟。26
新的一条预告：12:47 的帖写「Landing tomorrow before 10am PST together with a small ship」，换算过来是北京时间 10 月 24 日凌晨 1 点前后。27 前一条 12:46 的 Day 18 帖结尾也写了「that's a reset」。
两站都还没把它记成已验证重置，codex-reset 的信号位是 active、状态仍待确认。
八、今天的处置表
| 处境 | 今天做什么 | 依据 |
|---|---|---|
| 要换 token、换号或换项目 | 换文件名重写，别在原文件上覆盖 | auth_provider.go |
| 面板上一条凭证带着旧号的冷却 | 按 auth_index 调重置；401 终态的清不掉，删文件重写 | quota.go |
开着 save-cooldown-status | 删掉对应的 .cds 再重启，别让旧冷却被读回来 | cooldown_state.go |
同 token 换过 Codex account_id | 旧分区的一次 401 会记到新分区；盯 unavailable 出现的那一刻 | conductor_cooldown.go |
| 把执行器嵌进自己的服务 | #6907 那处无锁读可能让进程直接退出，先别升 | claude_executor_auth.go |
| composite 分组绑国产平台，推理强度不生效 | 等 #8309，或者客户端自己带 effort | PR #8309 |
References
- 1CLIProxyAPI #6908
github.com
- 2提交 d5816d5e
github.com
- 3conductor_lifecycle.go 第 292–306 行
github.com
- 4
- 5conductor_refresh.go 第 454–503 行
github.com
- 6conductor_lifecycle.go 第 372–381 行
github.com
- 7conductor_refresh.go 第 422–428 行
github.com
- 8conductor_cooldown.go 第 861–874 行
github.com
- 9
- 10conductor_cooldown.go 第 468–474 行
github.com
- 11config.example.yaml 第 211–222 行
github.com
- 12cooldown_state.go 第 283–296 行
github.com
- 13CLIProxyAPI PR #6853
github.com
- 14CLIProxyAPI PR #6907
github.com
- 15
- 16conductor_execution.go 第 1551、1582 行
github.com
- 17sub2api PR #8309
github.com
- 18CLIProxyAPI 发行页
github.com
- 19sub2api 发行页
github.com
- 20codex-proxy 发行页
github.com
- 21codex2api 发行页
github.com
- 22utls_client.go 第 101–124 行
github.com
- 23OpenAI 状态页事件
status.openai.com
- 24OpenAI 状态页接口
status.openai.com
- 25codex-reset
codex-reset.com
- 26opentherank 的 Codex 重置页
opentherank.com
- 27@thsottiaux 的帖子
x.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.