换号这件事官方不修了：删凭证时要连冷却状态文件一起删
CLIProxyAPI 把「换号继承旧冷却」判成用法问题、修复单由作者自己关掉；本期给出删两个文件的正确顺序，并核清 codex2api 那个 400 出在本地白名单，另附 dev 上三笔未发版的修复。
北京 18:54，那张想修「换号继承旧冷却」的单子被作者自己关了。1
他给出的理由只有一句：原地替换凭证不受支持，所以关单。1
上一期（17:08 发的）讲的是「为什么换个号会把旧冷却带过来」。今天这一期讲另一头：这条修的路没有下文了，你的动作得改。
四仓这一小时零新版本：CLIProxyAPI 仍是 v8.0.40，sub2api v0.2.18，codex-proxy v2.1.20，codex2api v3.1.1。
一、这单为什么关
维护者 luispater 在 16:55:50 把口径写死了：凭证的生命周期基于文件，每个凭证文件应当保持稳定的用户身份与状态，而不是把底下的认证信息原地换掉。2
同一段话给了唯一的替代路径：要复用同一个文件名，先删掉凭证文件和它关联的状态文件。2
两秒后，单子被关成 not planned。
作者 eaxeax 接受了这个结论：原地替换凭证不受支持，因此关单；#6844 带来的冷却继承保持原样。1
他的原句是
replacing a credential in place is not supported, so I am closing this PR。这张单本身不小：9 个文件、+1764/−18、21 笔提交、106 条行内评审。1 它挂了 40 个小时，最后一行评论是作者自己写的告别。
结论收成一句话：这条路上不会再有官方补丁。
二、关单之后：换号要删两个文件，顺序别反
要看懂正确做法，先看为什么「删掉 json、再放一个新的」不够。
只删 json，
.cds 会留在原地，名字还是原来那个。真正让人意外的是下一步：重启也不是退路。
启动时
RestoreCooldownStates 会把磁盘上的 .cds 全读一遍，按记录里的 AuthID 去找当前注册的凭证。
所以顺序是三步：删
<name>.json、删同目录同名的 <name>.cds、再放新凭证。中间别留「新文件已经在、
.cds 还没删」的窗口。那一瞬间 watcher 会把新文件当同一次更新，冷却照样继承。有一种机器可以少做一步。
routing.cooldown.save-cooldown-status 默认是 false，示例配置写明：为 false 时冷却只留在内存里。5这种机器上没有
.cds，重启就清干净了。只有把它打开过的机器，才必须手动删。管理端能帮到一半。
但它有一条硬边界：凭证身上带着 401 类失败记录时，这次清理直接不生效——
clearCooldownStateForAuth 第一件事就是这个判断。7「号被封了再换新号」恰好是最需要清干净、也最容易碰上这个哑火的场景。
最后一条容易漏：从面板上传一个同名文件覆盖上去，同样是原地改写。8 它继承的是同一批状态。
三、codex2api：那个 400 出在本地，不在上游
北京 13:28，有人报了另一类故障：codex2api 3.1.1、CC Switch 4.0.18、模型
gpt-6.1-sol，走 /v1/responses，多轮对话到一半回 400，正文是 Invalid input type 'configuration_update' at index 0。9这类条目是 Codex 在 GPT-6 系模型上改思考档位时发的，形状是
{"type":"configuration_update","reasoning":{"effort":"high"}}。9请求没有到上游就被拒了。
表里有
compaction、有 compaction_trigger、有 additional_tools，就是没有 configuration_update。
configuration_update。第 734–739 行是拒绝逻辑，报错带 field 与 code 两个字段。(codex2api v3.1.1 api/validation.go)所以用 WS 的客户端并没有躲过去，只是错误以关闭连接的形式出现。
今天 18:22 有人把补丁提上来了：PR #822，1 个文件、+1/−0。13
提补丁的人在 18:23 自己回帖，把链接贴在了单里。9 状态标着 mergeable unstable，还没合。
但放行不等于上游一定收。
上游仓库里有三张单能对上。
9 月 5 日那张说的是反面：Astra 正是靠这个条目在会话中途改档位时保住缓存前缀。15
今天 14:14 又开了一张：Codex App 在 SSH 会话里报同一句
Invalid input type 'configuration_update' at index 289。那几个回合没有任何回复输出。16也就是说，这句话既可能来自你自己的中转，也可能来自 OpenAI 自己。
分辨方法很直接。codex2api 这条带结构化的
errors[]，里面有 field 和 code（invalid_input_type）；10 上游那条只有一段 message，而且通常整轮无输出。先看是谁写的这行字，再决定要不要动配置。
四、dev 上三笔：被拦不再装成正常结束
上一节是「有人要改」，这一节是「已经改了，但你还没拿到」。
先看改之前是什么样。
finish_reason 就写成 stop。SAFETY、BLOCKLIST、MALFORMED_RESPONSE 都从这个口子出去。(CLIProxyAPI v8.0.40 gemini_openai_response.go)修法把八种原因统一映射成
content_filter：SAFETY、RECITATION、BLOCKLIST、PROHIBITED_CONTENT、SPII、IMAGE_SAFETY、MALFORMED_RESPONSE、MALFORMED_FUNCTION_CALL。21Claude 侧另把 MALFORMED_RESPONSE 归到
refusal。
content_filter 那一支在第 502–503 行；第 536–539 行是八种原因的名单。注意第 504–505 行的 default 仍是 stop——它只管名单之外的原因。(CLIProxyAPI dev 分支同文件)另一处更实用：候选为空、只有
promptFeedback.blockReason 的响应，也就是整条请求被拦。这类响应以前只发一条没有
finish_reason 的块就结束，客户端按截断处理。17现在它显式回 502，消息是
upstream blocked the prompt: <原因>，账照记。17这对运维的意义：以后看到这句话，是上游按安全策略拦了你，不是你的代理断了。
报障人给的代价也很具体：约 48 万 token 的上下文，空响应触发的重试把整段上下文又传了五遍。18
它还没发版。
geminiPromptBlockErrorMessage 在 v8.0.40 里一次都搜不到，要等下一版。同一小时 dev 还有两笔：83cb1b95 给
/v1beta/models 补回输入输出上限（关 #6914），22 e5434f65 修「文本段之后的第一个函数调用」丢签名（关 #6911）。23两笔都在 dev，不在 v8.0.40。
五、上游与额度
三家状态页这一小时都安静。OpenAI 全绿、没有降级组件，最近一条事件是上午的客服响应延迟，13:58 已恢复。24
Anthropic 全组件 operational，页面没有进行中的事件。25
Google Cloud 在册 8 条，最近一次仍是 10-20 那次多产品事件。26
额度侧今天多了一条新信息，两家追踪站的分歧比昨天更大。
Tibo 今天 12:46 发帖：「Day 18/ … But yes… that's a reset!」，一分钟后跟帖一句「Landing tomorrow before 10am PST together with a small ship」。2728
codex-reset 的首页仍写今天 UTC 未重置，最近一次已验证是 18 小时前（10-22 17:10）。
它的累计数是 57 次、存着 10 次，并给出 24 小时 32%、48 小时 53%、置信度 Low。29
opentherank 则写「Landed as announced, around 10:00 Pacific (17:00 UTC)」，累计 65 次、中位 3 天、最长 68 天。30
两家都没把今天这条标成已验证。按公告时间算，太平洋时间 10 月 23 日上午 10 点对应北京 10-24 01:00，这个窗口还没走完。
社区侧：OpenAI 官方社区 Codex 分区窗口内 0 条新帖，最新一条停在 17:39。31
Gemini 官方分区窗口内两条都跟额度与分级有关。
Claude 侧这一小时没有额度类新帖，Claude Code 仓库里唯一沾边的是账单币种显示问题。34
Reddit 的板块列表接口本轮仍返回上游解析错误，三个板块都没取到。这一节的社区侧由上面四路替代。
今天可以先做的三件事
一，把换号当成「删两个文件再放新的」：
<name>.json 与同名 <name>.cds 一起删，顺序别反。开过 save-cooldown-status 的机器尤其别漏。二，遇到 codex2api 的
Invalid input type，先看响应里有没有 errors[]。有就是本地校验，加一行或等 #822；没有 errors[] 且整轮无输出，多半是上游对模型的支持问题。三，Gemini 侧看到
upstream blocked the prompt 时按安全拦截处理，别当网络故障重试。重试只会把同一段被拦的上下文再传一遍。References
- 1CLIProxyAPI PR #6853
github.com
- 2CLIProxyAPI #6908 的维护者答复
github.com
- 3v8.0.40 cooldown_state.go 第 300–331 行
github.com
- 4
- 5v8.0.40 config.example.yaml 第 216–218 行
github.com
- 6v8.0.40 quota.go 第 27–60 行
github.com
- 7
- 8v8.0.40 管理接口表
github.com
- 9codex2api #821
github.com
- 10v3.1.1 api/validation.go 第 674–740 行
github.com
- 11v3.1.1 proxy/handler.go 第 3934–3950 行
github.com
- 12v3.1.1 proxy/responses_ws.go 第 355–365 行
github.com
- 13codex2api PR #822
github.com
- 14openai/codex #44751
github.com
- 15openai/codex #42996
github.com
- 16openai/codex #56367
github.com
- 17dev 提交 3f5d3a16
github.com
- 18CLIProxyAPI #6906
github.com
- 19
- 20
- 21dev 同文件 第 496–547 行
github.com
- 22dev 提交 83cb1b95
github.com
- 23dev 提交 e5434f65
github.com
- 24OpenAI 状态页事件
status.openai.com
- 25Anthropic 状态页
status.anthropic.com
- 26Google Cloud 事件列表
status.cloud.google.com
- 27Tibo 12:46 的帖子
x.com
- 2812:47 的跟帖
x.com
- 29codex-reset
codex-reset.com
- 30opentherank
opentherank.com
- 31OpenAI 开发者社区 Codex 分区
community.openai.com
- 32Gemini API 分区：项目仍被 Restricted
discuss.ai.google.dev
- 33Gemini API 分区：Tier 1 未升到 Tier 2
discuss.ai.google.dev
- 34anthropics/claude-code #104404
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.