非流式请求回的是一整段 SSE：37MB 原文卡住网关六分钟；CLIProxyAPI 的用量账本只记出站
非流式请求回的是一整段 SSE、CLIProxyAPI 的用量账本只记出站、v8.0.40 会把 $ref 约束改松：本期给出三条的判据、代码位置与今天就能做的处置。
这一轮四个仓库都没有新版本：CLIProxyAPI 停在 v8.0.40，sub2api 在 v0.2.18，codex-proxy 是 v2.1.20，codex2api 是 v3.1.11234。两条主干也没动：CLIProxyAPI 的 dev 头停在北京 20:38，sub2api 的 main 停在 15:44。
窗口里落下的只有三条：一条「非流式请求回来的是整段 SSE」，一条维护者对用量账本的口头定论，一条把
$ref 约束改松的 schema 缺陷。三条都不用等发版就能核。
非流式请求回的是一整段 SSE
先看判据。请求里写
stream: false，回来的头是 Content-Type: text/event-stream，body 以 event: response.created 开头。客户端要的是一份 JSON 对象，拿到的是事件流。New API 这类网关直接报
invalid character 'e' looking for beginning of value。10 月 9 日开出的 #7978 是原始报障5。报障人用的是 0.2.15、模型 gpt-6-luna，绕开 Nginx 直连容器同样能复现，
Accept: application/json 也没用。10 月 16 日他换 0.2.17 又测了一遍，问题还在。
第一处成因：stream 被改成 true 之后才去读它
理由是 ChatGPT 内网接口只吃流式，这一层没有错。
错在下一步。规范化返回之后，代码又回头读了一次 body：
reqStream = gjson.GetBytes(body, "stream").Bool()7。读到的是刚被改成 true 的那份，于是恒为 true。后面的路由按
reqStream 走流式转发，把 SSE 原样交给客户端，聚合那一步一次都没被调用。
openai_gateway_passthrough.go 第 168–192 行：第 174 行先做 OAuth 规范化，第 181 行才读 stream——读的是规范化之后的 body，所以 reqStream 对每个非 compact 的透传请求都是 true。7第二处成因：认不出终局事件，就把原文回传
响应侧还有一条路。上游确实回了 event-stream 时，非流式路径会调
handlePassthroughSSEToJSON，把事件流拼回一份 JSON8。上游以
response.incomplete 或 response.cancelled 收尾时，它返回 false。于是整段原始 SSE 被当响应体写回去，contentType 还照抄了上游那份 text/event-stream。
openai_gateway_passthrough.go 第 2438–2470 行：第 2445 行先把上游响应头整份写入，第 2449–2453 行在拼不出终局时把 contentType 退回上游值，第 2456 行用这个类型把 SSE 原文写出去。8今天多了一条生产案例
PR #7979 上，北京 21:36 有人补了一个线上案例10。
他的网关把非流式
/chat/completions 转成 /v1/responses 发给 sub2api。10 月 22 日有个请求的工具参数失控，上游推了约 12.8 万个 response.function_call_arguments.delta，以 response.incomplete 收尾。因为是非流式请求，sub2api 走了上面那条退回分支，把约 37MB 的原始 SSE 整段当响应体返回。网关同步解析，事件循环卡住，整个服务停摆约 6 分钟。
他已经在网关侧加了错误体截断兜底。根源那半边还在 sub2api。
补丁开着，已经第十四天
#7979 是 10 月 9 日开的，三个文件 +174/−1，
mergeable_state 是 clean11。三笔提交停在 10 月 14 日，之后再没有代码变化。今天的窗口里它只多了一条评论，没有新提交。
改法两条：保留客户端原始的
stream 标志，只有 compact 请求强制非流式；两个 SSE 转 JSON 的处理函数在写响应体之前显式声明 application/json。同一处还有一张更早的单 #7832，10 月 3 日开，
mergeable_state 是 unstable12。补评论的人建议二选一，合 #7979 就够。今天能做的三件：查自己有没有 OAuth 透传账号在跑非流式；给网关加响应体上限，别让一条 SSE 撑死事件循环；非流式调用尽量走
/v1/chat/completions。用量账本只记出站，冷却拒绝永远不在里面
第二条是定论，不是新缺陷。
报障人怎么发现的：某个模型的可用凭证全在冷却时，
/v1/responses 回 429 model_cooldown（他跑的是 v8.0.23）。这条请求在主日志和错误日志里都在，下游的用量消费端一条记录都没有。他的原话是：客户端在等或在重试，账本上却像没有失败过。
代码上看，为什么必然这样
用量记录由执行器里的 reporter 发出。选号在读执行器之前就失败了，那一步没有 reporter。
这条链路上唯一的补记，是给「没经过执行器 UsageReporter 的上游 401」发一条零 token 的记录。源码注释写得很直白15。
sdk/cliproxy/auth/home_result.go 第 12–32 行：第 15–16 行注释写明这条零 token 记录只服务「没经过执行器 UsageReporter 的上游 401 尝试」，其余在选号阶段发生的拒绝没有对应物。15它不是上游的错误，是本地的判定。既没有上游 usage，也没有走那条 401 补记。
对账要改口径
如果你拿 CLIProxyAPI 的用量去对上游配额或成本，口径要写成「只覆盖出站尝试」。
入站失败那一段，得从反代日志和它自己的 error log 补。两边的请求 ID 对不上时，先接受「这一段是空的」这个事实，别去猜。
他把额度与错误契约那一半单列在 #664617，那张不在本窗口。
v8.0.40 把 $ref 上的约束改松了，dev 已经修掉
第三条是 schema。它不报错，它把校验变松。
最小复现是这样的18：
$schema 声明 draft 2020-12，$defs.A 是 type: string, minLength: 5；属性 x 写 $ref 指向它，同时带一个 minLength: 1。按 2020-12，引用目标与兄弟关键字同时生效，
{"x":"a"} 应当不合法19。清完之后，输出只剩
minLength: 1。目标上的 5 被兄弟的 1 盖掉了。覆盖就发生在两行之间
同一个 map，后写的赢。机制就这么简单。
internal/util/gemini_schema.go 第 1090–1116 行：第 1097–1102 行把 $ref 目标的键写进 out，第 1103–1111 行再把引用对象的兄弟键写进同一个 map，同名键被后者覆盖。20它影响的是工具参数。模型可以交出比声明更短、更松的值，而上游照单全收。
修复在 dev，不在发行版
北京 20:38，一笔提交落在 dev：
29150a2，三个文件 +539/−48，说明第一行是 fix(schema): preserve Gemini $ref sibling constraints，末行 Closes: #689721。本窗口里的动作是关联与打标：北京 21:31 关联到这笔提交，21:33 把
pending 换成 Fixed。单到今天仍是 open。v8.0.40 里没有这笔修复。报障人自己在 01:34（北京 09:34）用 v8.0.40 的 commit 重跑过，结果一样18。
今天能做的：带 draft 2020-12
$schema 的工具 schema，别指望中转把它完整送到上游。关键约束在工具侧或客户端侧再校验一次。上游与额度
OpenAI 状态页全绿，25 个组件零降级，窗口内没有新事件22。最近一条仍是上午的客服响应延迟，北京 11:41 到 13:58，已恢复。
OpenAI 侧的社区这一窗口很吵，但吵的不是新事。
一张叫「Codex 用量异常消耗与记账不一致」的跨报告追踪帖，北京 22:19 又被顶起，已经 72 条评论25。它把多张单按证据类型归类，本身不给根因。
同一小时新开一张催办单，作者说 GPT-6.1 Sol 的用量消耗仍然过快，要求官方做账号级审计26。这张 0 回复。
Claude 侧这一小时新开 12 条，全是界面与功能类，只有一条碰到额度：有人希望周额度打满时自动切到 Opus，而不是卡在同意提示上27。
Gemini 官方论坛两个分区窗口内都没有新帖，最新的两条都在窗口之前：21:14 的 4K 生图问题与 20:06 的位置报错28。
OpenAI 开发者社区 Codex 分区也安静，窗口内 0 条新话题，最新一条是北京 20:35 的环境迁移帖29。
Codex 重置这边，今天（UTC）还没发生。最近一次已验证落在 10-22 17:10 UTC，也就是北京 10-23 01:10，21 小时前；累计 57 次，10 次存着，节奏约每 2 天30。
另一家记 65 次、中位间隔 3 天、最长 68 天31。
还有一条没到点的预告。Tibo 在北京 10-23 12:47 说「明天太平洋时间上午 10 点前落地」，换算过来是北京 10-24 01:0032。离发稿还有两个多小时，追踪站仍把它记成未验证。
今天要做的三件事
先查非流式。请求写
stream: false 时看一眼回来的 Content-Type；是 text/event-stream 就说明你踩在 #7978 上，先给网关加响应体上限。再改用量的口径。CLIProxyAPI 的用量只覆盖出站尝试，冷却拒绝要靠 error log 与反代日志补；拿它做成本对账时，把这句话写进口径说明。
最后别指望 schema。带
$ref 与兄弟约束的工具 schema，在 v8.0.40 上会被改松；要么等下一版，要么自己在工具侧再校验一次。三件事都不用等发版。
References
- 1CLIProxyAPI 发行记录
github.com
- 2sub2api 发行记录
github.com
- 3codex-proxy 发行记录
github.com
- 4codex2api 发行记录
github.com
- 5
- 6openai_gateway_request_body.go v0.2.18
github.com
- 7openai_gateway_passthrough.go v0.2.18
github.com
- 8openai_gateway_passthrough.go v0.2.18
github.com
- 9
- 10PR 7979 评论：37MB SSE 卡住网关
github.com
- 11sub2api PR 7979
github.com
- 12sub2api PR 7832
github.com
- 13CLIProxyAPI #6839
github.com
- 14维护者关闭理由
github.com
- 15home_result.go v8.0.40
github.com
- 16selector.go v8.0.40
github.com
- 17CLIProxyAPI #6646
github.com
- 18CLIProxyAPI #6897
github.com
- 19JSON Schema draft 2020-12 §8.2.3.1
json-schema.org
- 20gemini_schema.go v8.0.40
github.com
- 21提交 29150a2：保留 $ref 兄弟约束
github.com
- 22OpenAI Status
status.openai.com
- 23Anthropic Status
status.anthropic.com
- 24Google Cloud Status
status.cloud.google.com
- 25openai/codex #41220
github.com
- 26openai/codex #56479
github.com
- 27anthropics/claude-code 新开条目
github.com
- 28Google 官方开发者论坛
discuss.ai.google.dev
- 29OpenAI 开发者社区 Codex 分区
community.openai.com
- 30Codex Reset
codex-reset.com
- 31OpenTherank Codex Reset
opentherank.com
- 32
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.