gpt-5.5 这一格换成了 GPT-6.1-Sol；disable-cooling 又让 model_not_found 不冷却 (2026)

北京昨晚 23:46 到现在，四个仓库都没有新版本。

CLIProxyAPI 停在 v8.0.45，sub2api 停在 v0.2.18，codex-proxy 与 codex2api 窗口内零条目。

要处理的三件事都在已经发出去的版本里。

三件分别是：模型目录里有一格被换成了别的模型、关掉冷却之后 404 不再冷却、从 CC Switch 切回直连的老会话卡在 400。

下文时间都按北京时间写，GitHub 上显示的是 UTC，相差八小时。

目录里 gpt-5.5 这一格，写的是 GPT-6.1-Sol

v8.0.45 是昨晚 23:27 发的。1

v8.0.45 的客户端模型目录里，slug 仍然叫 gpt-5.5 的那一项，display_name 已经写成 GPT-6.1-Sol：上下文 500000、最大上下文 872000、comp_hash 是 3000。2

v8.0.44 的同一项写的是 GPT-5.5、272000 / 272000、2911。3

升到 v8.0.45 时，这一格的名字与数值都被替换成了 gpt-6.1-sol 的那一套，slug 留在原地。

远端那份同名目录也是这组值，与随包的一份一致，改写落在目录本身。4

同一版 models.json 里，codex-free / team / plus / pro 四段已经找不到 gpt-5.5。

v8.0.44 的 codex-free 与 codex-plus 还列着它。5

于是客户端与凭证两侧的名单对不上：客户端那一侧还列着 gpt-5.5，凭证这一侧已经收起了这一项。

这份目录的出口是 GET /v1/models 带上 client_version 参数时走的 Codex 客户端目录，display_name 原样进响应，Devin 通道的模型在后面补一个「 (Devin)」。6 7

v8.0.45 internal/registry/models/codex_client_models.json 第 1804–1841 行：slug 还叫 gpt-5.5，往下依次是 500000、872000、3000 与 GPT-6.1-Sol。

还在请求 gpt-5.5 的客户端，选择器里看到的就是 GPT-6.1-Sol；客户端从这一格读到的上限是 500000 输入、872000 最大上下文。

这件事今天凌晨 0:02 被报了出来。8

报障人在干净的 origin/main worktree 上跑 go test ./...，按包列了六组确定性失败。

其中四处是目录与测试对不上：devin/gpt-5.5 的显示名变成 GPT-6.1-Sol (Devin)、能力表里 gpt-5.5 缺失、deepseek-v4-pro 的上下文档位、comp_hash 从 2911 变 3000。

其中两处可以直接核对：目录条目的数值与 v8.0.44 的对照一致；model_definitions.go 里没有 gpt-5.5 的静态条目。

同一份报告里还有一处与目录无关：internal/api 的 multi-agent 配置测试发现，配置里省略或写 disabled 时，返回的 multi_agent_version 仍是 v2。

另有一处指向 v8.0.45 里的新代码：Vertex 流式 partialArgs 转换在 internal/translator/common/vertex_partial_args.go 第 521 行有一处就地字节写，还没登记进 nocopy_invariant_test.go 的白名单。

报障人另附一条判断：main 的 push CI 只跑 pr-test-build、translator-path-guard、agents-md-guard 三个 job，go test 属于本地检查，这类失败会一路进主干。

v8.0.45 internal/client/codex/models/models_test.go 第 1643–1647 行：测试按 devin/gpt-5.5 → GPT-5.5 (Devin)、gpt-5.5 → GPT-5.5 断言，与上面的目录对不上。

关掉冷却，404 就不再冷却

routing.cooldown.disable-cooling: true 关掉的是「一失败就黑一段时间」这套冷却。在 v8.0.45 里，它顺手把 404 的冷却也一起关掉了。

conductor_cooldown.go 第 1052 行进「模型不支持」分支后，disableCooling 为真就把 NextRetryAfter 置零，为假才给 12 小时。9

模型级 case 404 在第 1105 行同一写法，凭证级 404 在第 2864 行也一样。10 11

清零之后还有一步：第 1256–1260 行在冷却为真、且没有额度期限时，把这颗模型的状态改回 Unavailable = false、Quota.Exceeded = false。12

这次失败因此不留痕迹，下一次选号这张凭证对这个模型立刻又是可选的。

v8.0.45 sdk/cliproxy/auth/conductor_cooldown.go 第 1044–1114 行：第 1053 行与第 1106 行都是 if disableCooling，紧接着把 NextRetryAfter 置零，else 分支才写 12 小时。

PR #7019 的作者把这个组合写成了复现。

Zcode 在调一个已经从供应商下架的 glm-5.3-flash，凭证带着 disable-cooling: true；代理把冷却清零后，以大约每秒一次的速度重试同一张永远失败的凭证。13

另一半在 #7041：Zcode 每次重试都换一个 X-Session-ID，会话亲和每次都 miss，回落到最高优先级的那一张凭证，那张正好是刚才失败的。14

这张单加了个 5 分钟的 retry-sticky 记录（SessionAffinityConfig.RetryStickyWindow），失败归因到凭证时清掉绑定。

今晚两张单各推进了一笔。

#7019 在 1:04 落了第四笔提交，补的是 ExecutionSeq 0 的 pre-dispatch 失败，以及让两个冷却分支都打上 forced 标记。15

作者在 1:05 逐条回复了上一轮评审，解释 pre-dispatch 那次为什么会被旧守卫漏掉。16

自动评审在 1:12 又提了三处 P2。

最要命的一处是：一次凭证级 429 的额度影子会把 forced 标记吃掉，切回 disable_cooling 之后那颗 12 小时又被清掉。13

#7041 在 1:05 又落一笔，写入时清掉过期绑定；它的分支把 #7019 的三笔提交一起带着，中间两次 merge。

两张单都还 open，这些改动要等它们合进 dev，再等下一个版本。

今晚能做的有两件：

把已经从供应商下架的模型从那张凭证的可用模型里摘掉。报障里的诱因就是这一条，冷却只是把它放大成风暴。
只把那张凭证的 disable-cooling 单独设成 false。每把 key 的 disable-cooling 会覆盖全局值，其余凭证可以继续关冷却。17 18

旧会话续不上：CC Switch 的封装被当成上游密文

sub2api 的 #8383 今天 1:09 开出来，现象写得很细。

先让 Claude Code 走 CC Switch 的路由模式用 OpenAI 模型，再把 ANTHROPIC_BASE_URL 指回 sub2api 直连。

新会话正常，claude --resume 老会话直接 400。19

The encrypted content ccsw...9In0 could not be verified. Reason: Encrypted content could not be decrypted or parsed.

老会话里 thinking 块的签名，是 CC Switch 自己写的 ccswitch-openai-reasoning-v1: 加一段 base64url 编码的 JSON。

这个前缀是 CC Switch 的常量，它自己的桥接会解封。20

sub2api v0.2.18 在 anthropic_to_responses.go 里跳过空签名与 gAAAA 开头的块，其余签名整串写进 EncryptedContent。21

信封就这样被当成上游密文发了出去。报障人核对过：同一个会话里 523 个这类块都能正常解码成 JSON，报错里被拒的值却以 ccsw 开头。

v0.2.18 backend/internal/pkg/apicompat/anthropic_to_responses.go 第 292–308 行：第 302 行只挡空值与 gAAAA 前缀，第 307 行把剩下的签名原样写进 EncryptedContent。

新会话的历史里不带这些块，所以不受影响；老会话每多一轮就多一批。报障人查的两个会话分别是 523 块与 574 块。

恢复办法他在自己机器上做过，第一步先备份会话文件：

备份后退出会话。
删掉顶层 message.content 里 type=thinking、且签名以 ccswitch-openai-reasoning-v1: 开头的块。
变空的记录用一句短 text 占位，保住 uuid / parentUuid 链。

第一个会话处理后恢复正常，其余内容、工具记录与字段都逐条核过没变。第二个会话按同样办法删了 574 块，报障人说还在等运行确认。

长期看两边都有事要做：CC Switch 切模式时迁一次历史，或者 sub2api 认这个前缀、解封后只转发目标上游接受的字段。

在那之前，从路由模式切回直连的会话，旧的那几轮要按上面的办法清一遍。

短讯

OpenAI 状态页那条「6.1 Sol Degraded Model Performance」昨晚 23:02 开出、今天 0:20 恢复，impact 记为 minor。22

Claude 那条 Sonnet 5.5 事件昨晚 23:50 结束，impact major。

官方在恢复通报里写实际影响是 22:42–23:17，涉及 claude.ai、Claude API、Claude Code 与 Claude Cowork。23

Google 官方开发者论坛今天 0:42 有一条申诉：账号连过第三方客户端（OpenCode）经 OAuth 接 Code Assist，被按 ToS 判 403 PERMISSION_DENIED 停用。

发帖人说 10 月 21 日就提交了申诉，到发稿没有回复。24

codex-reset 仍把最近一次全局重置记在 10 月 26 日 14:08，今天没有新帖。25

还开着三张单子：#6715（管理端 Codex 设备码登录，96 笔提交，昨晚 23:49 又并了一次 dev），以及 sub2api 的 #8379 与 #8380（Codex 图片错误码、前端导出），后两张都还是 unstable。26 27 28

References

1
CLIProxyAPI v8.0.45
github.com
2
codex_client_models.json at v8.0.45
github.com
3
同一文件 at v8.0.44
github.com
4
router-for-me/models 的 codex_client_models.json
github.com
5
models.json at v8.0.45
github.com
6
server_routes.go 第 632–642 行
github.com
7
models.go 第 289–310 行
github.com
8
CLIProxyAPI issue 7059
github.com
9
conductor_cooldown.go 第 1052–1060 行
github.com
10
同文件第 1105–1112 行
github.com
11
同文件第 2864–2872 行
github.com
12
同文件第 1256–1260 行
github.com
13
CLIProxyAPI PR 7019
github.com
14
CLIProxyAPI PR 7041
github.com
15
提交 c72f95dc
github.com
16
PR 7019 的回复
github.com
17
config.example.yaml 第 223–226 行
github.com
18
同文件第 543–547 行
github.com
19
sub2api issue 8383
github.com
20
cc-switch 的 reasoning_bridge.rs 第 19 行
github.com
21
anthropic_to_responses.go 第 296–308 行
github.com
22
status.openai.com 事件 01M5YY4A3TQETEQ53DVSK8SW10
status.openai.com
23
status.claude.com 事件 lqhknfdjrcst
status.claude.com
24
discuss.ai.google.dev 196319
discuss.ai.google.dev
25
codex-reset 的 feed
codex-reset.com
26
CLIProxyAPI PR 6715
github.com
27
sub2api PR 8379
github.com
28
sub2api PR 8380
github.com

北京昨晚 23:46 到现在，四个仓库都没有新版本。

CLIProxyAPI 停在 v8.0.45，sub2api 停在 v0.2.18，codex-proxy 与 codex2api 窗口内零条目。

要处理的三件事都在已经发出去的版本里。

三件分别是：模型目录里有一格被换成了别的模型、关掉冷却之后 404 不再冷却、从 CC Switch 切回直连的老会话卡在 400。

下文时间都按北京时间写，GitHub 上显示的是 UTC，相差八小时。

目录里 gpt-5.5 这一格，写的是 GPT-6.1-Sol

v8.0.45 是昨晚 23:27 发的。1

v8.0.45 的客户端模型目录里，slug 仍然叫 gpt-5.5 的那一项，display_name 已经写成 GPT-6.1-Sol：上下文 500000、最大上下文 872000、comp_hash 是 3000。2

v8.0.44 的同一项写的是 GPT-5.5、272000 / 272000、2911。3

升到 v8.0.45 时，这一格的名字与数值都被替换成了 gpt-6.1-sol 的那一套，slug 留在原地。

远端那份同名目录也是这组值，与随包的一份一致，改写落在目录本身。4

同一版 models.json 里，codex-free / team / plus / pro 四段已经找不到 gpt-5.5。

v8.0.44 的 codex-free 与 codex-plus 还列着它。5

于是客户端与凭证两侧的名单对不上：客户端那一侧还列着 gpt-5.5，凭证这一侧已经收起了这一项。

这份目录的出口是 GET /v1/models 带上 client_version 参数时走的 Codex 客户端目录，display_name 原样进响应，Devin 通道的模型在后面补一个「 (Devin)」。6 7

v8.0.45 internal/registry/models/codex_client_models.json 第 1804–1841 行：slug 还叫 gpt-5.5，往下依次是 500000、872000、3000 与 GPT-6.1-Sol。

还在请求 gpt-5.5 的客户端，选择器里看到的就是 GPT-6.1-Sol；客户端从这一格读到的上限是 500000 输入、872000 最大上下文。

这件事今天凌晨 0:02 被报了出来。8

报障人在干净的 origin/main worktree 上跑 go test ./...，按包列了六组确定性失败。

其中两处可以直接核对：目录条目的数值与 v8.0.44 的对照一致；model_definitions.go 里没有 gpt-5.5 的静态条目。

同一份报告里还有一处与目录无关：internal/api 的 multi-agent 配置测试发现，配置里省略或写 disabled 时，返回的 multi_agent_version 仍是 v2。

报障人另附一条判断：main 的 push CI 只跑 pr-test-build、translator-path-guard、agents-md-guard 三个 job，go test 属于本地检查，这类失败会一路进主干。

v8.0.45 internal/client/codex/models/models_test.go 第 1643–1647 行：测试按 devin/gpt-5.5 → GPT-5.5 (Devin)、gpt-5.5 → GPT-5.5 断言，与上面的目录对不上。

关掉冷却，404 就不再冷却

routing.cooldown.disable-cooling: true 关掉的是「一失败就黑一段时间」这套冷却。在 v8.0.45 里，它顺手把 404 的冷却也一起关掉了。

conductor_cooldown.go 第 1052 行进「模型不支持」分支后，disableCooling 为真就把 NextRetryAfter 置零，为假才给 12 小时。9

模型级 case 404 在第 1105 行同一写法，凭证级 404 在第 2864 行也一样。10 11

清零之后还有一步：第 1256–1260 行在冷却为真、且没有额度期限时，把这颗模型的状态改回 Unavailable = false、Quota.Exceeded = false。12

这次失败因此不留痕迹，下一次选号这张凭证对这个模型立刻又是可选的。

v8.0.45 sdk/cliproxy/auth/conductor_cooldown.go 第 1044–1114 行：第 1053 行与第 1106 行都是 if disableCooling，紧接着把 NextRetryAfter 置零，else 分支才写 12 小时。

PR #7019 的作者把这个组合写成了复现。

另一半在 #7041：Zcode 每次重试都换一个 X-Session-ID，会话亲和每次都 miss，回落到最高优先级的那一张凭证，那张正好是刚才失败的。14

这张单加了个 5 分钟的 retry-sticky 记录（SessionAffinityConfig.RetryStickyWindow），失败归因到凭证时清掉绑定。

今晚两张单各推进了一笔。

#7019 在 1:04 落了第四笔提交，补的是 ExecutionSeq 0 的 pre-dispatch 失败，以及让两个冷却分支都打上 forced 标记。15

作者在 1:05 逐条回复了上一轮评审，解释 pre-dispatch 那次为什么会被旧守卫漏掉。16

自动评审在 1:12 又提了三处 P2。

最要命的一处是：一次凭证级 429 的额度影子会把 forced 标记吃掉，切回 disable_cooling 之后那颗 12 小时又被清掉。13

#7041 在 1:05 又落一笔，写入时清掉过期绑定；它的分支把 #7019 的三笔提交一起带着，中间两次 merge。

两张单都还 open，这些改动要等它们合进 dev，再等下一个版本。

今晚能做的有两件：

把已经从供应商下架的模型从那张凭证的可用模型里摘掉。报障里的诱因就是这一条，冷却只是把它放大成风暴。
只把那张凭证的 disable-cooling 单独设成 false。每把 key 的 disable-cooling 会覆盖全局值，其余凭证可以继续关冷却。17 18

旧会话续不上：CC Switch 的封装被当成上游密文

sub2api 的 #8383 今天 1:09 开出来，现象写得很细。

先让 Claude Code 走 CC Switch 的路由模式用 OpenAI 模型，再把 ANTHROPIC_BASE_URL 指回 sub2api 直连。

新会话正常，claude --resume 老会话直接 400。19

The encrypted content ccsw...9In0 could not be verified. Reason: Encrypted content could not be decrypted or parsed.

老会话里 thinking 块的签名，是 CC Switch 自己写的 ccswitch-openai-reasoning-v1: 加一段 base64url 编码的 JSON。

这个前缀是 CC Switch 的常量，它自己的桥接会解封。20

sub2api v0.2.18 在 anthropic_to_responses.go 里跳过空签名与 gAAAA 开头的块，其余签名整串写进 EncryptedContent。21

信封就这样被当成上游密文发了出去。报障人核对过：同一个会话里 523 个这类块都能正常解码成 JSON，报错里被拒的值却以 ccsw 开头。

v0.2.18 backend/internal/pkg/apicompat/anthropic_to_responses.go 第 292–308 行：第 302 行只挡空值与 gAAAA 前缀，第 307 行把剩下的签名原样写进 EncryptedContent。

新会话的历史里不带这些块，所以不受影响；老会话每多一轮就多一批。报障人查的两个会话分别是 523 块与 574 块。

恢复办法他在自己机器上做过，第一步先备份会话文件：

备份后退出会话。
删掉顶层 message.content 里 type=thinking、且签名以 ccswitch-openai-reasoning-v1: 开头的块。
变空的记录用一句短 text 占位，保住 uuid / parentUuid 链。

第一个会话处理后恢复正常，其余内容、工具记录与字段都逐条核过没变。第二个会话按同样办法删了 574 块，报障人说还在等运行确认。

长期看两边都有事要做：CC Switch 切模式时迁一次历史，或者 sub2api 认这个前缀、解封后只转发目标上游接受的字段。

在那之前，从路由模式切回直连的会话，旧的那几轮要按上面的办法清一遍。

短讯

OpenAI 状态页那条「6.1 Sol Degraded Model Performance」昨晚 23:02 开出、今天 0:20 恢复，impact 记为 minor。22

Claude 那条 Sonnet 5.5 事件昨晚 23:50 结束，impact major。

官方在恢复通报里写实际影响是 22:42–23:17，涉及 claude.ai、Claude API、Claude Code 与 Claude Cowork。23

Google 官方开发者论坛今天 0:42 有一条申诉：账号连过第三方客户端（OpenCode）经 OAuth 接 Code Assist，被按 ToS 判 403 PERMISSION_DENIED 停用。

发帖人说 10 月 21 日就提交了申诉，到发稿没有回复。24

codex-reset 仍把最近一次全局重置记在 10 月 26 日 14:08，今天没有新帖。25

References

1
CLIProxyAPI v8.0.45
github.com
2
codex_client_models.json at v8.0.45
github.com
3
同一文件 at v8.0.44
github.com
4
router-for-me/models 的 codex_client_models.json
github.com
5
models.json at v8.0.45
github.com
6
server_routes.go 第 632–642 行
github.com
7
models.go 第 289–310 行
github.com
8
CLIProxyAPI issue 7059
github.com
9
conductor_cooldown.go 第 1052–1060 行
github.com
10
同文件第 1105–1112 行
github.com
11
同文件第 2864–2872 行
github.com
12
同文件第 1256–1260 行
github.com
13
CLIProxyAPI PR 7019
github.com
14
CLIProxyAPI PR 7041
github.com
15
提交 c72f95dc
github.com
16
PR 7019 的回复
github.com
17
config.example.yaml 第 223–226 行
github.com
18
同文件第 543–547 行
github.com
19
sub2api issue 8383
github.com
20
cc-switch 的 reasoning_bridge.rs 第 19 行
github.com
21
anthropic_to_responses.go 第 296–308 行
github.com
22
status.openai.com 事件 01M5YY4A3TQETEQ53DVSK8SW10
status.openai.com
23
status.claude.com 事件 lqhknfdjrcst
status.claude.com
24
discuss.ai.google.dev 196319
discuss.ai.google.dev
25
codex-reset 的 feed
codex-reset.com
26
CLIProxyAPI PR 6715
github.com
27
sub2api PR 8379
github.com
28
sub2api PR 8380
github.com

gpt-5.5 这一格换成了 GPT-6.1-Sol；disable-cooling 又让 model_not_found 不冷却

目录里 gpt-5.5 这一格，写的是 GPT-6.1-Sol

关掉冷却，404 就不再冷却

旧会话续不上：CC Switch 的封装被当成上游密文

短讯

References

Related content

gpt-5.5 这一格换成了 GPT-6.1-Sol；disable-cooling 又让 model_not_found 不冷却

目录里 gpt-5.5 这一格，写的是 GPT-6.1-Sol

关掉冷却，404 就不再冷却

旧会话续不上：CC Switch 的封装被当成上游密文

短讯

References

Related content