10/16 深夜速报：带 reasoning_effort 走 AI Studio 的 gemini-3.8-flash 被上游 400 拒掉；Meta（Muse）流正常收尾却被记成 499 失败
10 月 16 日深夜这七十来分钟里四个仓库都没发新版本：AI Studio 通道上带 reasoning_effort 的 gemini-3.8-flash 被上游 400 拒掉，本刊核到上游收到的是别名之后的 2.5 型预算写法；另一条报障说 Meta（Muse）流在客户端正常收尾后却被记成 499 失败。
10 月 16 日北京 20:47 到 21:57 这七十来分钟里，四个仓库都没有发出新版本。
四个仓库的主干在本窗口也没有新提交。
今晚的动静都落在条目里：CLIProxyAPI 新开两条报障，上一期登记的那张修复 PR 转成了可评审状态，sub2api 关掉一条挂了三个月的代理改动。
要当场拿定主意的是两件事。一件是 AI Studio 通道上带
reasoning_effort 的 Gemini 请求为什么被上游 400 拒掉、要不要动别名。另一件是 Muse 凭证的失败计数被记错之后，还能不能照旧按失败率看号池。
一、AI Studio 通道上带 reasoning_effort 的 gemini-3.8-flash 被上游 400 拒掉
CLIProxyAPI 的报障 #6687 在北京 20:47 开出，open、0 评论、没有标签5。
报障人跑的是 v8.0.30。他用一个 OpenAI 兼容客户端往
/v1/chat/completions 发 gemini-3.8-flash，带上 reasoning_effort: "medium"5。这类报障的关键在上游实际收到的请求体，报障日志里留全了。
那个请求体里的模型名是
gemini-flash-latest，思考段写成 thinkingConfig: {thinkingBudget: 8192, includeThoughts: true}5。本地发的是档位（
medium），上游收到的是预算（8192）。
internal/thinking/convert.go 第 12–21 行：这张表把思考档位换算成预算，报障日志里那个 8192 对应的就是第 16 行的 "medium"6为什么本地发档位、出去成了预算？思考段写成哪种格式，是代理按模型名查能力表定的。
这个请求出去时的模型名已经被别名换成了
gemini-flash-latest。查表命中哪一条，直接决定输出是档位还是预算。
所以 8192 这个数是别名换名之后的产物：它按 2.5 型画像算出来，再发给了一个被指向
-latest 的上游。那 400 是谁拒的？报障人给了两个候选，本刊核了源码侧能核的那一条。
第一个候选是「把预算格式塞给一个只认档位格式的型号」。
第二个候选是
safetySettings。这段代码给这条路径上的每一条 Gemini 请求都带上五条安全设置。同一页的类别一栏列的是骚扰、仇恨言论、色情、危险内容与越狱五类11。
BLOCK_NONE 这个写法与 civic integrity 这一类都在这五类四档之外。这两条候选一步就能分开：把
reasoning_effort 去掉，同一个请求再发一次。仍然 400，就往 safetySettings 那条查；恢复正常，问题就落在思考段。今晚的处置按这个顺序走。第一步先让复现的客户端不带
reasoning_effort，报障先止住。第二步把指向
*-latest 的别名换成明确的模型名，让登记表按 gemini-3.8-flash 那一条给格式。第三步改完各发一次，核对上游收到的请求体。影响面跟着别名走。AI Studio 通道上凡是指向
*-latest 的别名，只要客户端默认带 reasoning_effort（ChatWise 这一类 OpenAI 兼容客户端多数会带），请求就会变成上面那个形状。二、Meta（Muse）流正常收尾，却被记成 499 失败
第二条报障 #6688 在北京 21:50 开出，open、0 评论12。
现象是这样：客户端读到
message_stop 就关掉连接。它拿到的回答是完整的，代理自己的访问日志记的是 20012。但用量记录和凭证的失败计数把这条请求记成 499、输入输出各 0 token12。
报障人在
muse-wonder-full-1.0 上连发 16 条，其中 15 条被这么记12。他按 request ID 对齐了三条：请求日志都以
message_stop 收尾、状态 200，对应的用量记录分别是 499 失败、耗时 332.4 秒、287.0 秒与 3.2 秒12。本刊按 v8.0.31 核了源码。
meta_executor_stream.go 一共 186 行，收尾就在最后。这个文件在主干上与 v8.0.31 逐字节一致，报障人写的「主干上没变」核得回来13。
客户端在这一刻先挂断，循环下一次读到的就是
context canceled。
internal/runtime/executor/meta_executor_stream.go 第 166–186 行：第 158–175 行是已经走完的 finish 分支与它的错误分支，第 176 行起的 scanner.Err() 分支直接上报失败，中间没有终局判断13同类保护在别处已经有了。
terminalDelivered 这个终局标记只出现在两个文件里：antigravity_executor_stream.go 与 gemini_vertex_executor.go1415。整个仓库搜不到第三处。
报障人说这条与 #5866、#6376、#6421 同类。那三条也是同一个保护缺失，只是落在别的执行器上。
他还附了写好的补丁和一份回归测试：终端事件转发过之后，再遇到
context.Canceled 就当成功返回；在终端事件之前断开的连接，仍然记 49912。他写自己在 v8.0.31 上跑过这份补丁，之后同一客户端的 Muse 请求被记成 200 并带上了 token 数12。
影响面落在两处：Muse 凭证的失败计数会虚高，token 用量不入账。按失败率判断号池健康、或者按用量做成本核算的，这两项都会被这条偏差带偏。
今晚的处置：Muse 凭证的失败计数先搁一边。要确认某条请求到底成没成，看代理的访问日志，那里记的是 200。
这条报障刚开出，改动落到哪个版本要等它合并。
三、上一期那条草稿转正了，并在两轮自动审查之间连推两次
上一期登记的 CLIProxyAPI PR #6686 在北京 20:59 被作者标成可评审，脱离草稿状态16。
标成可评审一分钟后就触发了自动代码审查，审查结论里有一项未解决的发现16。
之后作者在 21:22 与 21:38 两次强制推送头分支16。
两条未解决的 P2 意见都落在新增的
internal/runtime/executor/helps/gemini_malformed_call.go 上，讲的其实是同一件事：函数名里带冒号。第一条讲的是，Gemini 的函数名可以合法含
:，翻译层用 util.SanitizeFunctionName 把它保留下来。形如
call:default_api:name:with:colons{ 的坏调用头按两级拆会拆出多于两段，这条请求就被判成不可恢复，客户端仍然收到那个坏调用错误16。第二条讲的是，改版之后的统计按裸子串数
call:。处置：这张 PR 还没有合并，今晚没有可用修复。它现在进了自动审查的循环，值得等一下一轮。
四、同一窗口里的短条目
sub2api PR #4498 在北京 20:52 关闭、没有合并17。它 7 月 17 日开出，8 个文件 +340/−6。
它的用途是给 Grok 的受保护视频内容加一条代理：客户端手上只有 Sub2API 的用户 key，而内容端点要的是被选中那条上游凭证，直接返回上游 URL 会在下载时得到 40117。挂了三个月，以关闭收场；在等这条路的人可以放下。
sub2api issue #8132「你们 antigravity 正常么」在北京 21:14 又有新回复18。
发帖人写官方客户端能正常用，走这个项目的请求返回是空的；一位访客回帖说 gemini 和 antigravity 都不正常；发帖人最新一条说一个月都没成功过18。这条仍开着、没有维护者定性，本刊登记不展开。
codex-proxy 与 codex2api 窗口内 0 条条目更新；codex-proxy 的预发布版仍没有占上
latest4。五、上游与额度侧
OpenAI 状态页在本窗口是全绿：All Systems Operational、活动事件 0 条、没有降级组件19。上一期那条转正之后没有再反复。
Anthropic 状态页是 All Systems Operational，10 月 16 日一栏写着 No incidents reported today20。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 到 9 日的 Cloud Storage21。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 32 小时前，即 10 月 15 日 06:13 UTC、北京 14:1322。
累计是 54 次全局、10 次 banked，节奏约每 4 天22。
counted 口径仍是 24 小时 50%、48 小时 75%，公告区写着当前没有官方信号22。
另一个追踪站记最近一次为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天23。
官方开发者社区 Codex 分区窗口内新增一条，北京 21:52 发出，说的是手机端远程控制读远程文件超时24。这是客户端侧的行为，与中转运维没有直接关系，登记不展开。
两条都是消费端体感，按收录口径不收为条目；r/OpenAI 与 r/ClaudeAI 窗口内没有额度或风控条目。
六、未闭合项（下期继续跟，不作结论）
- CLIProxyAPI：本窗口登记 #6687、#6688，#6686 转正；继续跟 #6686 会不会合并、两条 P2 意见怎么处理，以及 #6681、#6683、#6679、#6680、#6676、#6677、#6515、#6675、#6605、#6669、#6670、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500
- sub2api：本窗口关闭 #4498，#8132 仍在更新；继续跟 #8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793 有没有维护者定性
下期优先回看三条：#6687 有没有人答复、别名换掉之后还报不报 400；#6688 的补丁会不会被采纳、别的执行器会不会一起补上终局保护；#6686 会不会合并。
References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5CLIProxyAPI #6687
github.com
- 6convert.go 第 12–21 行
github.com
- 7models.json
github.com
- 8Gemini 3 developer guide
ai.google.dev
- 9Thinking
docs.cloud.google.com
- 10safety.go 第 10–30 行
github.com
- 11Safety settings
ai.google.dev
- 12CLIProxyAPI #6688
github.com
- 13meta_executor_stream.go 第 166–186 行
github.com
- 14
- 15gemini_vertex_executor.go 第 764–800 行
github.com
- 16CLIProxyAPI #6686
github.com
- 17sub2api #4498
github.com
- 18sub2api #8132
github.com
- 19OpenAI Status
status.openai.com
- 20Claude Status
status.anthropic.com
- 21Google Cloud Status
status.cloud.google.com
- 22codex-reset.com
codex-reset.com
- 23opentherank
opentherank.com
- 24Codex 远程控制帖
community.openai.com
- 25r/GeminiAI 1x7fhxb
reddit.com
- 26r/GeminiAI 1x7g87t
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.