10/20 入夜速报：重启清空会话日期钉，跨天会话的思考块全丢；那条 503 落到 plus 档
重启会把伪装模式下的会话日期钉清零，跨天会话此前的思考块与整段 prompt cache 一起丢；同一小时里那条 503 报障第一次出现 plus 档，另附 Antigravity 缓存键与 codex2api 套餐过滤两处能当场执行的改动。
北京 18:28 到 19:28 这一个小时，四个中转仓库没有新版本。
CLIProxyAPI 的 dev 在 18:54 合进一张 Antigravity 的补丁，main 没动。sub2api、codex-proxy、codex2api 的主干都停在原处。
这一小时最值得看的是两件事：一件说重启会把会话日期钉清零，另一件把上一期的档位结论又推翻了一次。
下面的记号只说明改动走到哪一步。标「已进 dev」的还在分支上，剩下的连分支都没进。
重启一次，跨天会话的思考块全丢
19:07 开的单 #6799 是这一小时最该看的一条1。
它说的是件小事：伪装模式下被钉住的会话日期，只活在进程内存里。
v8.0.35 的代码证实了这一点。日期钉放在一个包级 map 里，键是会话 ID 的 SHA-256，值只有日期与过期时刻2。
查询函数在找不到或已过期时返回空串3。
所以重启之后，同一会话的下一次请求拿不到旧日期，注入的是当天日期。
如果这个会话是前一天开始的，
messages[0] 的文本就变了。Anthropic 会按前缀绑定校验，把此前所有 thinking 块判为不匹配而丢弃。prompt cache 也从
messages[0] 起全部失效。
v8.0.35
internal/runtime/executor/helps/claude_diagnostics.go 第 120–168 行。第 129–136 行是那个包级结构体与 map 的初始化，第 140–147 行的键只对 session ID 做哈希，第 151–166 行的查询在 miss 或过期时返回空串。整段没有任何写盘调用——这就是重启会清零的原因。报障人给了自己的数字：一个跨天会话在重启后丢掉 237 个思考块，那一次请求读到 0 个缓存 token，写入了 671,481 个1。
三件事叠起来才危险。
重启发生在每次升级、每次机器重启、每次崩溃之后。保留期由
session-date-pin-days 控制，默认 7 天4。而它只决定「进程还在时留多久」。还有一层：大多数客户端看不到这件事。
只有请求明确带上
thinking.block_binding.prefix_mismatch_behavior: drop_block 与那个 beta 头，上游才把丢弃原因报出来。其余客户端只会觉得这一轮慢、账单变贵。
能确认的处置只有三条。
- 今天要升级或重启的，挑没有跨天长会话正在跑的时候。
- 跨天的长会话先收尾，重启后重开一个，别续着上一个。
- 别把
session-date-pin-days: 7当成「重启也能保留七天」。这个键管的是进程内的保留窗口，不是落盘。
Antigravity 的模型目录换了缓存键，已进 dev
18:46 提交、18:54 合并进 dev 的 #6798 改的是 Antigravity 的模型目录缓存5。
旧的缓存键由账号、注册代次、项目、端点、代理五段拼成，没有客户端 UA。
后果很具体：UA 变了，已缓存的目录不会失效。目录的存活期就是模型目录的刷新周期，3 小时6。
新的键多了 UA 一段。注释写明：换 token 不会让一份成功目录失效，换客户端指纹会7。
dev 分支
sdk/cliproxy/antigravity_models.go 第 104–139 行。第 106–107 行是新注释，写明目录按账号、项目、线路与客户端指纹隔离，单换 token 不使成功目录失效；第 122 行的格式化串结尾多了一个 %q，接的就是 UA。同一张补丁还做三件事：探测与缓存用同一份 UA 快照；过期的发布结果被丢弃；周期扫描时会取消已经过时的在途探测。
Hub 的 UA 也换了写法。旧的是
antigravity/hub/2.23.0 darwin/arm64。新的在前面挂了
aidev_client，平台段换成 os_type=darwin; arch=arm64。changelist 跟着按发行版配：2.24.0 配 1000335682，仍识别 2.23.0 配 998057262，未知版本不带 cl5。
登录时取项目号与 AI credits 查询走的
loadCodeAssist，也从默认端点改到 daily，并去掉了 Accept: */*。凭证里显式写了 base_url 的实例不受影响，覆盖仍然优先。
v8.0.35 不含这笔，它是 10-20 03:02 发布的8。
所以今天能做的只有两件：等下一个 tag；已经手工把 Antigravity 的 base_url 指到 daily 的实例，升级后这个覆盖照样生效。
codex2api：套餐白名单填 pro，整条 Key 直接 503
19:15 开的 #810 是一条能当场验证的配置坑9。
同样的 Key，不设
plan_allow 时 /v1/messages 与 /v1/chat/completions 都是 200。勾上
pro 之后，/v1/models 返回空列表，任何请求都回 503 no_available_account。清空立刻恢复。根因在套餐名的域不一致：上游给的是
{"id":"pro","name":"Google AI Pro"}，代码先取展示名10。
codex2api v3.1.1
auth/antigravity_client.go 第 940–966 行。第 948 行是 firstNonEmpty(result.PaidTier.Name, result.PaidTier.ID)——名字优先于 ID；第 962–963 行在受限时再追加 " (Restricted)"，让这个字符串更难对上。发行版上这条路径还在。处置很简单：把
plan_allow 清空，或者在填之前先看一眼 /v1/models 是不是还列得出模型。顺带一句：这条和余额、额度都无关，账号本身是健康的，只是调度阶段被过滤光了。
那条 503 报到第四次：plus 档也进了名单
同一张 #8239 今天第四次进本刊，但这一次有真增量12。
17:56 那条写的是「大都是 20X 的账号出问题，plus 没问题」13。
19:19 这条把它推翻了：我订购的四个 plus 账号都有这个问题14。
他给的报错串是「正在重新连接 /5」。
后面接的是
stream disconnected before completion: Our servers are currently overloaded。窗口内还多了一条量化：白天大概 10–13% 的请求都是这个错15。
到本条为止，单子仍是 open、0 标签、18 条回复、维护者零回应。
本地能确认的只有两件事。
第一，sub2api 对 OpenAI 账号只有一个「订阅 / 非订阅」的判定，没有 pro、plus 这些档位分支16。档位差异不是本地写出来的，本地也改不了。
第二，错误形态变了：断在流中间。首块已经发给客户端、又收到容量让渡事件时，本地只记一条日志，不换号17。
sub2api v0.2.17
backend/internal/service/openai_gateway_response_handling.go 第 512–530 行。第 519–521 行三个条件同时成立才进这一支：事件是 error 或 response.failed、客户端已经收到输出、错误体被判成容量让渡；成立后只调一次 logOpenAICapacityFailoverSuppressed（第 522 行），不做换号。所以处置也变了。
客户端看到「正在重新连接」就直接重试，这一轮本地救不回来。
不要按档位批量停号。这条错仍然不写账号状态，停号只会把小池子改得更小。
上一期那条「整档中招时把
gateway.max_account_switches 调小，用更快的失败换更短的等待」，在这种断流形态里同样适用。上游：伦敦区的根因是电源事件
谷歌云那条事故，19:12 的更新第一次给出根因：
europe-west2-b 这个 zone 内发生了电源事件导致的宕机，电源事件已缓解，未来 30 分钟内部分基础设施服务先恢复18。症状描述也跟着收窄了：从「整个 region 有多项服务异常」变成「
europe-west2-b 里的服务不可用，region 内其它服务可能出现错误升高」。受影响产品 38 个，清单里仍然没有 Vertex AI，也没有 Gemini API。事故开始时间不变，仍是 14:08；结束时间仍为空。
下一次更新承诺在北京 20:00。
对中转站，要动的还是那两处：Vertex 凭证里 location 钉在
europe-west2 的，和自建服务跑在伦敦区的。这一小时的其余状态
| 仓库 | 当前发行版 | 主干最新提交 | 窗口内 |
|---|---|---|---|
| CLIProxyAPI | v8.0.35，10-20 03:02 发布8 | main 12:23、dev 18:54 | 一张补丁合进 dev |
| sub2api | v0.2.17，10-16 12:41 发布19 | main 10-19 20:45 | 三条条目变动 |
| codex-proxy | v2.1.19，10-20 05:10 发布20 | dev 10-20 04:57 | 无 |
| codex2api | v3.1.1，10-17 05:46 发布21 | main 10-17 05:35 | 一条新单 |
sub2api 窗口内三条：#8239 是主线，另两条跟额度风控无关——#7996 是 DimAgent 平台接入，仍是 open；#764 是交流长帖被顶起。
CLIProxyAPI 窗口内两条：#6798 已合，#6715 被顶起（仍 open，12 个文件 +894/−33，Codex 设备登录进管理接口）。
另有一条待补信息的：#6797 报的是 40022。
错误说
input[95].id 里那个值含了额外字符，原文是 msg_resp_…|c_… 这种带竖线的 ID。维护者 18:55 回帖要上游渠道、模型名、两侧协议和完整请求日志。目前没有定论，先不当结论用。
上游与额度
- OpenAI 状态页全绿，0 个活动事件、0 个降级组件23。
- Anthropic 全绿，今天没有事件24。
- 谷歌云见上一节，事故仍在进行，根因已给，结束时间仍空。
- Codex 重置：最近一次是今天 14:33，五小时前，窗口内没有新重置。两家追踪站分别记 56 次与 64 次，中位间隔 3.1 天2526。
- 官方社区 Codex 分区窗口内 0 条新话题，最新仍是 14:51 那条用量归属帖27。
- 社区侧本轮只取到官方开发者社区这一路；Reddit 直连返回 403，本窗口未取到。
这一小时没有版本可升。
真要在今晚动手的，只有一件事：把重启的时间和跨天会话错开。日期钉活在进程里，重启就是清零，代价落在缓存未命中和那一串被丢掉的思考块上。
References
- 1CLIProxyAPI issue 6799
github.com
- 2
- 3同文件第 151–167 行
github.com
- 4v8.0.35 config_types.go 第 124–143 行
github.com
- 5CLIProxyAPI PR 6798
github.com
- 6
- 7dev antigravity_models.go 第 106–122 行
github.com
- 8CLIProxyAPI v8.0.35
github.com
- 9codex2api issue 810
github.com
- 10v3.1.1 antigravity_client.go 第 947–963 行
github.com
- 11
- 12sub2api issue 8239
github.com
- 13zdy-zg-QQ 17:56 的回复
github.com
- 14Silentbarber 19:19 的回复
github.com
- 15lzytaro 18:32 的回复
github.com
- 16v0.2.17 account.go 第 1419–1430 行
github.com
- 17
- 18Google Cloud 事故 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 19sub2api releases
github.com
- 20codex-proxy releases
github.com
- 21codex2api releases
github.com
- 22CLIProxyAPI issue 6797
github.com
- 23OpenAI Status
status.openai.com
- 24Anthropic Status
status.anthropic.com
- 25codex-reset.com
codex-reset.com
- 26OpenTheRank Codex Reset Tracker
opentherank.com
- 27Codex usage chart attributes ~80% of usage to gpt-6-astra
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.