10/16 凌晨续报：Antigravity 生产目录里的 Gemini 3.7 Flash，Pro 账号调用回 404
10 月 16 日凌晨这五十五分钟里，sub2api 上一张报障单把 Antigravity 的两个端点分开摆清了：Gemini 3.7 Flash 只在生产目录里出现，Google AI Pro 账号调用就是 404；四个仓库本窗口都没有新版本。
补报 10 月 16 日 04:26 到 05:21（北京）。第二十七期在北京 04:26 刊出，本期接在它后面。
这个窗口四个仓库都没有新版本，主干上也没有新提交，三家上游状态页同样没有新事件。
中转侧只有一条需要动手判断的动态：sub2api 上一张报障单，把「模型目录里看得见」和「真正调用回 404」摆在了同一张单子上。
结论可以先给：Gemini 3.7 Flash 只向企业档开放，Google AI Pro 账号打过去就是 404，原因是账号的档位不同。
这段时间先看这几件事：
- 没有要升的版本。 四个仓库本窗口都没有新版本，主干也没有新提交。1234
- 目录里出现的模型名，未必调得动。 Gemini 3.7 Flash 在 Free 与 Google AI Plus、Google AI Pro、Google AI Ultra 三档都拿不到，别按模型目录去开分组白名单。5
- 要核自己那版，看两处。
v0.2.16里目录发现固定先打生产端点，生成时 Pro 与 Ultra 账号才切到 daily，两个端点不是同一份名单。67 - 上游不用管。 OpenAI 状态页剩下的降级仍是 Compliance API 那条旧事件，Anthropic 与 Google Cloud 本窗口没有新事件。8
目录里有、Pro 账号打过去是 404
北京 10 月 16 日 04:22，一张 Google AI Pro 档的 Antigravity 报障单开在 sub2api 上，报的是模型目录里能看见 Gemini 3.7 Flash，调它却回 404。9
客户端发的是
antigravity/gemini-3.7-flash-high，账号里那条映射原样透传给上游，拿回来的是 404 NOT_FOUND，正文只有一句 Requested entity was not found.。9这条单子最值得看的是报障人自己做的那张逐端点对照表。9
生产端点
cloudcode-pa.googleapis.com 上，fetchAvailableModels 列出 gemini-3.7-flash 的 low、medium、high 三个档，还带着不为零的剩余额度与 Leaving Soon 标记。9同一账号、同一个项目，在
daily-cloudcode-pa.googleapis.com 上只拿到 22 个模型，没有一个 3.7 的 ID；把 User-Agent 换成 antigravity/hub/2.23.0 是 23 个，仍然没有。9他自己写明了 429 只是这次请求没成功，不能当成模型可用；也没有拿到任何一次成功的 Gemini 3.7 生成。9
它先打生产端点，只有传输出错或碰上特定状态码，才顺着往下试 daily。6
换句话说，只要生产端点回 200，目录就此定稿，不会再拿 daily 对一遍。6
v0.2.16 的 backend/internal/pkg/antigravity/client.go，高亮区间是第 655–711 行：第 671–672 行写着「固定顺序：prod -> daily」，第 676 行按这个顺序逐个试，第 690 与 707 行分别在传输出错和特定状态码下才降级到 daily。目录在生产端点拿到 200 就定稿。6也就是说，站点即使没接外部目录同步器，这个模型名也会出现在可选列表里。10
权限那一侧能独立对上。 Google 自己的 Antigravity 模型可用性表里，Gemini 3.7 Flash 只有 Enterprise 一列打勾，Free 与 Google AI Plus、Google AI Pro、Google AI Ultra 三列都是叉。5
同一张表里，Gemini 3.8 Flash 四列全勾，Gemini 4 Argon 只勾 Ultra 与 Enterprise。5
按这张表，Pro 账号拿到 404 是档位差异，生产目录上那一行对它没有效力。5
修这个落差的提交已经在主干，但不在任何版本里。 北京 10 月 15 日 01:06，维护者 baryon 提交了
373d4353，标题是 feat(antigravity): support Gemini 4 Argon and accurate upstream model catalogs，37 个文件 +1209/−169。11它把目录同步改成和生成用同一个端点：主干上抓目录时调
FetchAvailableModelsFromURL，地址参数就是生成侧那个 resolveAntigravityForwardBaseURL(account)。12它还换了 User-Agent 家族。
v0.2.16 拼出来的是 antigravity/<版本> windows/amd64，主干上变成 antigravity/hub/<版本> windows/amd64，回归测试的名字直接叫 BuildUserAgentUsesHubClientFamily。1314报障人问的「哪个发行版会带上这个改动」，答案是目前还没有。
v0.2.16 是北京 10 月 13 日 15:20 发的，比这笔提交早了一天多。2单据本身还开着。 开单 13 分钟后，另一个账号在下面回了一句
i so dumb / close issue please，维护者没有回应，单据到现在仍是 open、没有标签。15对运维意味着什么：模型目录反映的是生产端点，你手上这版不会替你核对生成端点。跑
v0.2.16 的站点，遇到 3.7 Flash 这类只开给企业档的模型，直接按不可用处理；等下一个发行版出来，再核目录同步那一行是不是换成了与生成同一个端点。6社区侧：一条 Plus 账号的额度报障
OpenAI 开发者社区的 Codex 分区里，本窗口出现一条新帖：ChatGPT Plus 账号用 Astra 跑一个约 30 秒的小任务，就弹出
Out of Codex usage limit。16发帖人按东非时间记的是 10 月 16 日。他说此前跑一小时以上的任务都能正常结束，这次连短任务也立刻耗光，并问是不是记账或额度口径变了。16
这条目前只有他一个人报，没有回复，也没有官方确认。同一个分区里更早的同类单可以追到 30 天前。17
对运维的用处是判断归属：下游有人报额度掉得异常快，先看它是不是这一类单账号体验。本窗口的官方状态页没有对应事件。8
上游状态与重置追踪：本窗口没有新事件
OpenAI 状态页整体仍写着「部分系统降级」，唯一降级的组件仍是 Compliance API 的成本数据延迟。8
上一期报过的那条登录与注册降级，最后一条更新仍是北京 10 月 16 日 02:56 的「已恢复」，本窗口没有新更新。18
Anthropic 状态页是全系统正常，当日无事件记录。19
Google Cloud 最近一条事件仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟。20
Codex 重置两站都没有新记录。codex-reset.com 仍记最近一次已验证的全局重置在北京 10 月 15 日 14:13，24 小时概率 18%、48 小时 33%，页面在北京 05:17 重算过一次。21
opentherank 停在同一天：最近一次记录是北京 10 月 15 日 12:55，累计 62 次，中位间隔 3.1 天。22
本期未闭合项
codex2api 的
#790 降智检测也仍开着、未合并。32References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5Choose a model · Google Antigravity Docs
antigravity.google
- 6
- 7
- 8OpenAI Status summary
status.openai.com
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16Sudden and Abnormal Codex Usage Limit Exhaustion on ChatGPT Plus (Astra)
community.openai.com
- 17BUG: Fresh Codex 5-hour reset exhausted in ~5 minutes
community.openai.com
- 18Widespread feature degradation
status.openai.com
- 19Claude Status
status.anthropic.com
- 20Google Cloud incidents.json
status.cloud.google.com
- 21Codex Reset Tracker
codex-reset.com
- 22Codex reset tracker
opentherank.com
- 23
- 24
- 25
- 26
- 27
- 28
- 29fix(typesafe): 透传 System One 图片开关请求头
github.com
- 30
- 31
- 32
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.