10/19 午间速报：一个元数据事件堵死了 sub2api 的 overload 换号，v0.2.17 上 47 次只救回 2 次
这一小时四仓都没发版：一个 response.metadata 事件让 sub2api 在 v0.2.17 上的 overload 换号失效，生产数据是 47 次只救回 2 次；同一窗口还有 home 模式空目录回 502 的修复，以及 codex-proxy 额度分组与热路径落盘的两条排期。
这一小时四个仓库都没有发版。
codex-proxy 稳定版 v2.1.18（10-17 03:29 发布）、预发布 v2.1.19-beta.f824033（10-18 23:37）也都在原地。5
本期覆盖北京时间 10-19 10:24 到 11:20，共 56 分钟。
这一小时值得动手的只有一件：sub2api 的 overload 换号在 v0.2.17 上是失效的，有人拿生产数据把它钉死了。
sub2api 的 overload 换号在 v0.2.17 上失效，生产数据是 47 次只救回 2 次
先交代这张单。#8139 在 10-16 11:19 开出，作者 zenggang，改三个文件共 +15/−1，到今天仍是 open。6
北京 10:53，hellpup 在单下补了一份生产复现。环境是 sub2api 从 0.2.16 升到 0.2.17 的官方二进制，OpenAI OAuth 号池，前置 LiteLLM 走
/v1/responses 流式。7他记的现象很具体：10-16 起，上游 overload 的
response.failed 从 sequence 3 推迟到 4，多出来的那个事件是 response.metadata。代价写在他的表里。10-12 到 10-15，每天 61 到 232 次 overload，其中没救回的只有 1 到 7 次；10-16 那天 47 次 overload，45 次没救回。
抓包的前缀两边一致，且整条流里没有任何可见输出：
response.created | response.in_progress | response.metadata | response.failed (server_is_overloaded)。sub2api 这边的记录是 recovered=0、最终 503。也就是说，换号那次机会从头到尾没被触发。
根因在一条白名单上。sub2api 在 HTTP 200 的 SSE 里判断「客户端是否已经收到模型输出」，这个判断决定还能不能在输出前换号。8
backend/internal/service/openai_gateway_passthrough.go 第 1088–1095 行：注释写明生命周期元数据与传输心跳都不算模型输出，但 case 里只有 response.created、response.in_progress、keepalive 三个名字，response.queued 与 response.metadata 落到第 1092 行的 default 返回 false8返回 false 的后果在下一层。第 1195 行与第 1273 行都用
!openAIStreamEventIsMetadata(eventType) 当作「这一帧算输出」，未知事件于是被当成已经开始输出。9一次尝试就此被提交。紧接着的
response.failed 再进来，已经落不进输出前那条重试与换号分支，只能把 503 原样回给客户端。同一份判定还管首 token 计时。PR 说明里写，
response.metadata 会让语义 TTFT 提前开始、首输出超时提前解除，所以监控上看到的延迟也会偏。今天的处置只有一条正路：把这 15 行补丁打上再重编。补丁只往白名单加两个事件名，重试次数、账号调度、错误分类都不动。
报障方已经在 v0.2.17 上验证过。他写的基线是
060d0160，那正是 v0.2.17 标签指向的提交；go test ./internal/service/ 全量通过，含新增的 TestOpenAIStreamMetadataAndKeepaliveBeforeOverloadFailOver。10他准备先部署这个补丁版本，上线后回帖救回率的对比。在那之前，这段数据只能当「补丁在他那套环境上有效」。
线上有没有中招，可以在自己的链路上确认。在 LiteLLM 或前置反代记 SSE 的事件前缀，出现
metadata 之后紧跟 failed、而 sub2api 侧 recovered 为 0，就是这一条。配置里没有开关。v0.2.17 里这三处判定共用同一张白名单，没有把未知事件当元数据的选项。
单子本身还没人处置。开出到今天三天，两条评论都来自用户，维护者没有表态，mergeable 是 clean。
CLIProxyAPI：home 模式下模型目录为空，会把 /v1/models 变成 502
北京 10:49，hkfires 开了一个 PR #6765，base 是 dev，两个文件 +134/−3，open、mergeable clean。11
它修的是 home 模式的一条误判。home 模式下
/v1/models 与 /v1beta/models 不再读本地注册表，改为向 home 控制中心要目录。当这把 key 的 scope 一条模型路由都没有，home 返回空对象
{}。v8.0.33 把空目录当成畸形数据。第一处判定在第 1167 行：解包后的 section 数为 0，直接报
home models payload has no sections。12第二处更靠后。即使 section 存在、只是每条都没有可用模型 ID，第 1225 行也会报
home models payload contains no models。13
internal/api/server_routes.go 第 1158–1169 行：第 1159 行先挡空载荷，第 1163–1166 行解包成 section 到模型列表的映射，第 1167–1168 行把「section 数为 0」直接判成 no sections 错误，空目录与畸形载荷在这里被合并处理12两处错误都从同一个调用点出去。第 1045 行拿到解码错误，回 HTTP 502、错误类型
server_error。14受影响的端点有四个入口：
/v1/models 按 OpenAI、Claude、Codex、Grok 四种客户端形状各走一遍，/v1beta/models 与 /v1beta/models/{model} 是 Gemini 那两个。对客户端来说，结果就是启动探活拿到 502。多数客户端把 502 当实例不可用，实际只是这把 key 没有任何模型路由。
PR 的改法把两种情况分开。空对象、空 section 返回空目录；
null、非对象、section 非空但没有可用模型 ID、上游错误信封，照旧报错。测试覆盖六种客户端形状，都要求 200 加空数组；不可达的单模型仍返回 404。11
今天的处置：给这把 key 配上路由，或者用有路由的 key 做探活。v8.0.33 整包里还是旧逻辑，等合并发版。
codex-proxy：额度卡片按官方两组展示已排期，热路径同步写盘也给了改法
北京 10:28，同一个维护者 SsuJojo 连着回了两张单。
#874 在 10-15 15:51 开出，请求按 Google AI Pro 的官方配额分组展示额度。答复是「已排期」，方案分五步。15
数据源上，
AntigravityUpstream.fetchQuota() 加一条 Quota Summary 拉取路径，返回 Gemini Models（共享池）与 Claude and GPT models（独立固定配额）两组，各带 Weekly 与 Five Hour 两个窗口；旧接口不可用时回退到现在的逐模型 buckets。接口与前端跟着改：额度端点输出
groups 加 buckets，前端默认只画两组聚合进度条，回退模式下才逐模型展开；AI credits 与套餐内额度分开展示。他明确不加数值推算。官方文档没有承诺固定请求数或 token 数，展示以接口返回的剩余比例为准。16
官方的口径可以核。5 月 19 日的公告把 Gemini Flash 与 Gemini Pro 各自独立的限额合并成一条，按 API 价目扣减。17
同一份公告写明非 Gemini 模型因为容量原因维持另一组固定限额；AI credits 从基础套餐里拿掉，只作超额使用。
Pro 的窗口在计划页上：每五小时刷新一次，直到撞上每周上限为止。18
这解释了卡片为什么长。#874 描述一个 Pro 账号可能出现二十多条进度条，逐模型各一根。v2.1.18 的额度端点确实只回 buckets。19
src/routes/auth.ts 第 99–110 行：第 99 行取一次 retrieveUserQuota，第 100–102 行只认响应里的 buckets 数组，第 103–110 行逐个映射成 modelId、remainingFraction、resetTime 三项，没有分组的字段看卡片时记住这个结构：二十多条进度条分摊同一张共享池加一组固定额度，逐模型见底就是整组在减。排期落地后会变成两组。
#871 是同一天的另一件事，10-14 22:08 开出，说 Antigravity 每次请求都会同步写
api-keys.json。答复是「已确认按热路径 debounce 批量落盘修复」，暂不迁移存储介质。20改法四条：
markUsed() 与 recordUsage() 只更新内存并标 dirty，秒级 debounce 批量落盘；正常退出时 flush，异常退出最多丢一个窗口的计数；增删改 key、启停账号等配置变更仍即时持久化；补四类回归测试。21
src/auth/api-key-pool.ts 第 289–312 行：markUsed() 改完 requestCount 与 windowRequestCount 后第 297 行调 persist()，recordUsage() 改完 token 计数后第 312 行再调一次；persist() 走默认实现，第 105 行是 writeFileSync 写临时文件再加 renameSync两张单都还在路上。v2.1.19-beta.f824033 与 dev 分支上，这两处调用仍是逐次
persist()，额度端点也仍只回 buckets。今天不用改任何配置。等含这两项的版本发出来，再按需要看卡片分组、按请求量决定要不要调 debounce 窗口。
上游与额度这一小时
三家状态页全绿。status.openai.com 是 All Systems Operational，活动事件 0；最近一条已结束的是 Compliance API 的数据延迟，10-16 18:44（北京）恢复。23
status.anthropic.com 同样全绿，10-19 无事件。status.cloud.google.com 仍是 7 条，最近一条停在 10-08 到 10-09 的 Cloud Storage。2425
额度侧没有新信号。codex-reset.com 记今日 UTC 尚未重置，最近一次已验证的全局重置在 31 小时前，北京 10-18 04:41。26
页面上是 55 次全局重置、10 次 banked，节奏约每 3 天；把 Tibo 的提示计入后，24 小时 45%、48 小时 70%。
opentherank.com/codex-reset/ 记最近一次在 10-17 21:12 UTC，累计 63 次，中位间隔 3.1 天，最长 68 天。27
@thsottiaux 窗口内没有新帖。最新一条是北京 09:18 的「桌面端可以编辑历史消息」，在窗口之前。28
官方社区 Codex 分区最新一条停在北京 10-19 05:27，窗口内 0 条。29
Reddit 三个板块窗口内只有 r/OpenAI 一条，11:11 的「想从 GPT Plus 换到 Google AI Pro」，属套餐选择，未收。30 r/ClaudeAI 与 r/GeminiAI 的最新帖都在窗口之前。
另有一条 11:17 开出的报障没写环境、没贴日志，只链到另一个项目的单，称 Codex 桌面版 26.1013 起限制浏览器访问，暂不采信。31
还没落地的东西
- #8139 什么时候有人 review，会不会进下个版本。
- 报障方把补丁部署到生产之后，overload 救回率的对比数据。
- #6765 合并后，空目录该回 200 空列表还是 404，维护者的取舍还没出现。
- codex-proxy 两项各自的落地版本，以及 debounce 窗口最终取多少秒。
References
- 1CLIProxyAPI Releases
github.com
- 2提交 9d453bc0
github.com
- 3sub2api Releases
github.com
- 4codex2api Releases
github.com
- 5codex-proxy Releases
github.com
- 6sub2api PR #8139
github.com
- 7#8139 的生产复现评论
github.com
- 8v0.2.17 的元数据判定
github.com
- 9同一文件的两处调用
github.com
- 10v0.2.17 标签指向 060d0160
github.com
- 11CLIProxyAPI PR #6765
github.com
- 12v8.0.33 的目录解包
github.com
- 13同一文件的空目录判定
github.com
- 14v8.0.33 的错误出口
github.com
- 15codex-proxy #874
github.com
- 16#874 的排期答复
github.com
- 17Antigravity 计划调整公告
antigravity.google
- 18Antigravity Plans
antigravity.google
- 19v2.1.18 的额度端点
github.com
- 20codex-proxy #871
github.com
- 21#871 的修法答复
github.com
- 22v2.1.18 的账号池
github.com
- 23OpenAI Status
status.openai.com
- 24Anthropic Status
status.anthropic.com
- 25Google Cloud Incidents
status.cloud.google.com
- 26Codex Reset
codex-reset.com
- 27OpenTheRank Codex Reset
opentherank.com
- 28
- 29OpenAI 开发者社区 Codex 分区
community.openai.com
- 30r/OpenAI 那条帖子
reddit.com
- 31sub2api #8207
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.