10/17 下午再报：一个能发 tools 的请求就能占满 v8.0.32 一个核；坏 JSON 不拦，代理把上游 400 当自己的答复
10 月 17 日北京 15:20 到 16:22 这六十来分钟里四个中转仓库没发新版本：v8.0.32 有两处平方级开销，一个能发 tools 的已认证请求就能占满一个核；五个推理入口都不校验请求体，坏 JSON 会被改写后转给上游。
10 月 17 日北京 15:20 到 16:22 这一个小时，四个中转仓库没有发新版本，也没有合并落地。
窗口里值得今天就看完的内容，全在未合并的报障单与 PR 里：两处平方级开销、一个不校验请求体的入口缺口、一条可执行的回退路径。
前两条的触发条件很轻：任何已认证、能发 tools 的调用方都够。
结论与影响面
- 一个能发 tools 的请求就能占满 v8.0.32 的一个核。 报障人在 main 上实测：1.38 MB 的平铺 schema 花 12.7 秒，1.18 MB 的混合 schema 花 170.5 秒。1
- 同一份工具清单还会被逐个声明重写整份文档。 1000 个普通工具、3.23 MB 请求体：41.8 秒、分配 30.5 GB；8000 个小工具：2 分 5 秒、54.4 GB。2
- 五个推理入口都不校验请求体是不是合法 JSON。 坏 body 被改写后发上游，客户端拿到的是上游的 400。3
- 每一次这样的请求照旧消耗一次凭证的上游调用。 3
- sub2api 的充值回调有了回退路径： 有人报「回退到 0.2.16 就好了」。4
- 管理端 v8 新增 Codex 设备码登录，仍是一份未合并的 PR。5
主线一：两处平方级开销，同一分多钟开出
其中两张说的是同一类事：工作量随输入变大而平方增长。两者机制不同，都还没有对应 PR。
第一处：每命中一条路径，整份文档复制一次
cleanJSONSchema 对一份 schema 跑大约二十个阶段。1多数阶段先用一次走查收集命中路径，再对每条路径做两件事。6
写回是整份文档复制，所以单个阶段的开销等于「命中路径数 × 文档大小」。两个因子都随 schema 变大。1
报障人点名的受影响阶段包括
convertConstToEnum、convertEnumValuesToStrings、moveConstraintsToDescription、removeUnsupportedKeywords、removeKeywords、cleanupRequiredFields、sanitizeArrayItems 与 sanitizeObjectProperties。1
v8.0.32 的
internal/util/gemini_schema.go 第 184–233 行：sanitizeObjectProperties（第 187 行）与 sanitizeArrayItems（第 212 行）都先 findPaths 收集全部路径，再在循环里逐条 gjson.Get 读出、sjson.SetBytes 或 sjson.Delete 写回——第 202–203、223–226 行就是那次整份复制。报障人的实测（main，一次调用）：
| 平铺 schema | 耗时 | 混合 schema | 耗时 |
|---|---|---|---|
| 0.17 MB | 0.21 s | 0.15 MB | 2.5 s |
| 0.34 MB | 0.84 s | 0.29 MB | 10.3 s |
| 0.69 MB | 3.2 s | 0.59 MB | 44.4 s |
| 1.38 MB | 12.7 s | 1.18 MB | 170.5 s |
每翻一倍，耗时涨四倍。1
这条链路不只在 Antigravity 上跑。本刊在 v8.0.32 整包里核过调用点：Antigravity 执行器第 235 与 237 行调这两个清洗器。7
Responses 转 Gemini 的工具构造同样走它。10
第二处：工具清单被逐个声明重写
第二个机制在 Antigravity 的请求侧，与 schema 大小无关，与工具个数有关。2
sanitizeAntigravityToolSchemasForModel 先把 request.tools 单独摘成一份小文档，再交给 sanitizeAntigravityToolSchemaDocumentForModel。11那份小文档里的每个 function declaration 都要被改写一次。11
改名循环对每个
parametersJsonSchema 调一次 util.RenameKey，内含一次 sjson.SetRawBytes 加一次 sjson.DeleteBytes，各复制一份。11于是每个声明要付三份完整复制，外加若干次从头扫描。2
v8.0.32 的
internal/runtime/executor/antigravity_executor_request.go 第 211–261 行：第 217–228 行是逐声明的改名循环（第 222 行 util.RenameKey），第 244–259 行是逐声明的清洗与写回（第 245 行 gjson.Get、第 253 行 sjson.SetRawBytes）；两个循环都作用在同一份 payloadStr 上，所以每个声明都要复制整份工具文档。报障人的实测（main，一次调用，单个
functionDeclarations 数组）：| 声明数 | 请求体 | 耗时 | 分配 |
|---|---|---|---|
| 250 个普通工具 | 0.81 MB | 3.1 s | 2.0 GB |
| 500 个普通工具 | 1.61 MB | 10.2 s | 7.7 GB |
| 1000 个普通工具 | 3.23 MB | 41.8 s | 30.5 GB |
| 4000 个极小工具 | 0.38 MB | 30.0 s | 13.7 GB |
| 8000 个极小工具 | 0.76 MB | 2 分 5 s | 54.4 GB |
这一处同样每翻一倍涨四倍，而且请求体可以很小。2
与上午 07:41 那批单不是一回事
上午报过的 #6696 说的是
$ref 走查在共享定义上指数级增长。12所以 #6696 提的那份「每次遍历一万节点」的预算，管不住这两处。1
对运维意味着什么
触发条件只有一个：调用方在请求里带上
tools。任何已认证的客户端都满足。2报障人的结论是：任何能发 tools 的已认证客户端，一个请求就能钉住一个核，并把进程推向 OOM。2
这类请求不报错，只是慢。同一台机器上其它用户的请求会跟着排队，而你在面板上看不出是谁干的。
今晚能做的三个选项
一是给请求体设上限。 v8.0.32 已有这个开关：
server.max-request-body-bytes，默认 0 表示不限，超过上限的请求直接回 413。13中间件同时检查
Content-Length 与分块传输的流。14平方级开销意味着上限砍半，最坏耗时降到四分之一。代价是超长 tools 的合法请求也会被拒，值该按你实际最大的 schema 定。
二是盯一次请求的 CPU 曲线。 面板上看不到这类开销，只能在进程侧看：单个请求吃满一个核、持续几十秒，基本就是它。
主线二：坏 JSON 不拦，客户端拿到的是上游的 400
同一批里还有一张单说的是另一件事：代理不检查请求体本身是不是合法 JSON。3
报障人在本地起了一个会记录 body 的假上游，五种输入的结果如下。3
| 入口与客户端 body | 上游实际收到 | 客户端看到 |
|---|---|---|
/v1/messages，缺最后一个 } | 仍不合法，"stream":false 被写进最后一条 message | 上游 400 |
/v1/messages，合法 body 后跟 trailing | 合法，尾随字节被静默丢掉 | 正常 |
generateContent，缺最后一个 } | 仍不合法，safetySettings 与 model 被写进 contents | 上游 400 |
/v1/chat/completions，缺最后一个 } | 一份完整合法的 Claude 请求，被真的执行 | 上游 400 |
/v1/responses，缺最后一个 } | 同上 | 上游 400 |
代码对得上。OpenAI 侧走
ReadRequestBody，identity 路径在第 36–37 行直接把原文返回。15json.Valid 只出现在解压失败那条兜底分支里。15
v8.0.32 的
sdk/api/handlers/request_body.go 第 21–56 行：第 36–37 行在 Content-Encoding 为空或 identity 时直接 return raw, nil，没有任何 JSON 校验；第 46 行的 json.Valid 只在解码出错、且原始字节本身合法时才放行——也就是说，最常走的那条路根本不检查。Gemini 的 generateContent、streamGenerateContent 与 countTokens 也是同一种取法。17
全仓只有一个处理器校验了 JSON，就是 Gemini Interactions。18
三条影响
第一，客户端拿到的是上游的 400，不是代理的 400。排障时你会先怀疑账号、模型与上游，而问题在客户端。
第二，每次坏请求都照旧消耗一次凭证的上游调用。配额被无效请求吃掉，失败计数也可能算到凭证头上。3
第三，有两条路径会把坏 body「修好」并执行。客户端以为自己发的是什么，服务端并不知道。3
今天能做的
在入口层判一次。 前置的反向代理或网关照旧能先拒掉非法 JSON，这比等版本快。
把请求体上限设上。 同一个
server.max-request-body-bytes 对这条也有效：超大坏 body 连解析都进不来。13别把代理返回的 200 当证据。 这一版里，代理不保证它转出去的请求体与你收到的一致。
次条：sub2api 充值回调出现「回退就能恢复」
15:56，
gao5253678 在那张单下写：「我也是这个问题，回退到 0.2.16 就好了」。4这张单 10:19 由
ding-1988 开出，最初只有一句「升级到 v0.2.17 后充值无法回调」与一张截图。4四条评论按时间是：11:00「没问题啊」，13:13「+1」，15:00「正常充值成功，显示被取消」，15:56 那句回退。4
现在四条里三条指向同一件事，症状还比开单时更具体：钱到了，订单状态是取消。
sub2api 的 main 停在 10 月 16 日 12:42，没有相关修复。19
当前发行版仍是 v0.2.17。20
v0.2.17 的发行说明列了五条资金链路改动，其中一条正是「不支持的订单类型导致支付回调无法确认」，改法是下单时就校验订单类型。21
回退能恢复，把原因指向 v0.2.17 那组资金改动；维护者还没给这条单定性。
真要回退，先备份库再动：订单与退款状态都写在库里，回退不会替你撤回已经写入的资金记录。
次条：管理端多了设备码登录这条路
16:09，
JustYannicc 开了 PR #6715，base 是 dev。5GET /v8/management/oauth/auth-url?provider=codex&flow=device 会先返回验证地址与用户码，再轮询结果。5不带
flow=device 仍走浏览器回调，v0 路由不变。5v8.0.32 里这个端点只有浏览器回调一条路。22
对运维的用处很具体：服务器上没有浏览器、也接不到 localhost 回调时，设备码可以在任意一台机器上完成登录。
PR 仍是 open，没有人工评审，测试用的是假认证器，没有做真实登录。5
跟进：配置热重载那条修复合成了两份 PR
上午报过的「rename 覆盖后热重载静默停掉」，现在有两份改法。23
#6701 用目录监听加软链解析；#6710 换成替换后重挂监听，并每 5 秒读一次文件做 SHA-256 比对，把目录监听去掉了。23
两份都还开着。v8.0.32 的监听器仍只
Add 配置文件与 auth 目录，配置事件只触发一次重载，不重挂。24对读者的结论没变：改完配置要确认真的生效，必要时重启。
上游与额度
OpenAI 状态页全绿，没有降级组件，也没有活动事件；最近一条仍是 Compliance API 成本数据延迟，10 月 16 日 18:44 恢复。25
Anthropic 全绿，10 月 17 日当天没有事件。26
Google Cloud 仍是 7 条事件，最近一条是 10 月 8 日到 9 日的 Cloud Storage。27
Codex 今天 UTC 仍未重置，最近一次已验证的全局重置在 10 月 15 日 14:13。28
同一页记着累计 54 次全局重置、10 次 banked，节奏约每四天一次；模型口径 18%／33%，把提示计入后是 45%／70%。28
另一家追踪站记的是 62 次、中位间隔 3.1 天、最长 68 天，最新记录停在 10 月 15 日 12:55。29
官方开发者社区 Codex 分区窗口内有一条新话题，15:30 发的「什么时候该放弃当前对话重开一个」，与额度、风控无关，未收。30
@thsottiaux 窗口内没有新帖。最近一批在 13:09 到 14:21，全是闲聊，没有重置信号。31
沾边的三条都没收：r/OpenAI 有一条 16:10 的外链帖，指向个人博客，1 分 0 评论，正文不在 Reddit；r/GeminiAI 有一条问 Pro 档是不是只剩 3.8 Flash，属于订阅档位体感；r/ClaudeAI 一条作品展示。3234
本窗口核对过的空状态
codex-proxy 窗口内零条目。codex2api 只有一条 10 月 14 日开出的低配设备内存占用报障在 16:01 被顶起，诊断正文由报障人自己补写，未核、未收。40
CLIProxyAPI 另有一条测试抖动的单（#6712），不影响部署，未收。
References
- 1CLIProxyAPI issue #6713
github.com
- 2CLIProxyAPI issue #6714
github.com
- 3CLIProxyAPI issue #6711
github.com
- 4sub2api issue #8171
github.com
- 5CLIProxyAPI PR #6715
github.com
- 6gemini_schema.go v8.0.32
github.com
- 7antigravity_executor_request.go v8.0.32
github.com
- 8gemini_claude_request.go v8.0.32
github.com
- 9gemini_openai_request.go v8.0.32
github.com
- 10responses_tools.go v8.0.32
github.com
- 11antigravity_executor_request.go v8.0.32
github.com
- 12CLIProxyAPI issue #6696
github.com
- 13config.example.yaml v8.0.32
github.com
- 14server_middleware.go v8.0.32
github.com
- 15request_body.go v8.0.32
github.com
- 16code_handlers.go v8.0.32
github.com
- 17gemini_handlers.go v8.0.32
github.com
- 18interactions_handlers.go v8.0.32
github.com
- 19sub2api main 提交
github.com
- 20sub2api releases
github.com
- 21sub2api v0.2.17 发行说明
github.com
- 22server_management_v8.go v8.0.32
github.com
- 23CLIProxyAPI PR #6710
github.com
- 24events.go v8.0.32
github.com
- 25OpenAI Status
status.openai.com
- 26Anthropic Status
status.anthropic.com
- 27Google Cloud Status
status.cloud.google.com
- 28Codex Reset
codex-reset.com
- 29OpenTheRank Codex Reset
opentherank.com
- 30OpenAI Developer Community
community.openai.com
- 31Tibo (@thsottiaux)
x.com
- 32r/OpenAI
reddit.com
- 33r/ClaudeAI
reddit.com
- 34r/GeminiAI
reddit.com
- 35CLIProxyAPI releases
github.com
- 36codex-proxy releases
github.com
- 37codex2api releases
github.com
- 38CLIProxyAPI dev 提交
github.com
- 39CLIProxyAPI main 提交
github.com
- 40codex2api issue #787
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.