10/17 夜间速报：上游断流改判成 502，只在 dev 分支；adaptive-only 模型还在发 enabled
10 月 17 日北京 20:23 到 21:20 四仓未发新版：CLIProxyAPI 把上游断流从「补成正常收尾」改判成 502，但只落在 dev 分支；sub2api 的 adaptive-only 模型仍收到 thinking.type=enabled，PR 还没合。
10 月 17 日北京 20:23 到 21:20 这一小时里，四个中转仓库都没有发新版本：sub2api v0.2.17、CLIProxyAPI v8.0.32、codex-proxy v2.1.18、codex2api v3.1.1 仍是各自的最新版。1234
CLIProxyAPI 的 dev 分支在这小时里落地了一笔截断检测，sub2api 收到两份 PR，都还没合并。
截断检测进了 dev，v8.0.32 还没有
北京 20:42，CLIProxyAPI 的 dev 分支多了一笔提交
4f2e5270，标题是 feat(runtime): detect upstream stream truncation across executors and proxy handlers，提交信息最后一行写着 Closes: #6707。这笔提交改了 9 个文件、+1761/−45，其中 937 行与 483 行是两份新增测试。5主分支仍停在 10 月 17 日凌晨 02:56（北京）的那一笔，v8.0.32 里搜不到这笔提交引入的函数。要等这个行为，只能等下一个发行版。6
它改的是一件事：上游流没有正常收尾时，别再替它补一个“已说完”。
| 通道 | 什么情况算截断 | 现在的返回 |
|---|---|---|
原生 /v1/messages（Claude 执行器） | 流结束，但没见过 message_stop，也没有 error 事件 | 502 upstream stream closed before message_stop |
| Claude 格式经 Gemini / Vertex | 整条流里没有 finishReason，也没有 blockReason | 502 upstream stream closed before finishReason |
| Claude 格式经 OpenAI 兼容执行器 | 既没有 finish_reason，也没有 [DONE] | 502 upstream stream closed before [DONE] |
| Kimi 执行器 | 读上游时出错 | 先抛错误，不再先补 [DONE] |
| 其它输出格式 | 不适用 | 未改动 |
具体到一行，是第 431 行：扫描器没报错、上下文没取消、
upstreamCompleted 仍是 false 时，错误被兜成 502。7客户端那一侧的状态码改不过来。handler 在写出第一个字节之前就把 200 提交了，最后一帧只能补一条
event: error，状态码仍是 200。只看 HTTP 状态码的监控，看不到这次失败。8对号池的影响
这笔提交把一个原本“成功”的结局改判成失败。失败会照 502 走瞬时错误冷却，默认 60 秒：配置项是
routing.cooldown.transient-error-cooldown-seconds，写 0 沿用 60 秒，写 -1 关掉。9冷却之外还有一层区别，取决于断在哪一刻。截断落在第一段内容之前时，请求会换下一个凭证重试。已经吐出内容之后再断，客户端只收到一条错误帧，请求到此结束。
两种情形下，这张凭证都按 502 记一次失败。多号池跑一个断流严重的上游站点，会看到凭证一张接一张进冷却。
会误伤的站点
v8.0.32 在这条路上原本是刻意放宽的：
Other protocols retain compatibility with providers that omit [DONE]. 这句注释就在旧代码里，除 Responses 之外，省略 [DONE] 的上游一律按正常结束处理。10现在 Claude 格式不再享受这个宽容。内容完整、只是省了终止帧的上游，会从“成功”变成 502。
灰度前值得先做一次核对：拿你手上的上游站点跑一条长流式请求，看结尾到底有没有
message_stop、finishReason、finish_reason 或 [DONE]。缺哪个，就在哪条链路上会被判失败。判断依据是线上日志里是否出现上面那三句错误文案。同一个问题有两套实现
issue #6707 是同一天 14:27 开出的报障，社区 PR #6708 在它之后三秒被提交，20:35 还在更新，到现在仍是 open，
mergeable_state 是 dirty。11 维护者自己那笔提交在 20:42 先落进了 dev，贡献者的这份没有合。两份改动覆盖的范围接近，实现不同：一个走 handler 的
CloseError 回调，一个在四个执行器里各自补判定。发行版里还没有这个行为，而主干上已经有两套写法。
message_stop 时，第 431 行把结局兜成 502。高亮原文见该文件。sub2api：adaptive-only 模型只认 adaptive，转换层还在发 enabled
sub2api 这边的问题出在思考档位的写法。Fable 5/5.1、Opus 4.7/4.8/5、Sonnet 5 这一批模型只接受
thinking.type=adaptive，深度交给 output_config.effort；收到 enabled 加 budget_tokens，上游直接 400。12报障原文是这句：
"thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.v0.2.17 里哪一段还发 enabled
responses_to_anthropic_request.go 里有两段互斥的写法。文件上半部分是 5.5 家族的专属分支：Opus 5.5、Sonnet 5.5、Haiku 5.5 各按自己的规则写 adaptive、between_tools 或 disabled。下半部分才是通用分支，第 134–143 行：
reasoning_effort 非空、映射后的档位不是 low，就写 Type: "enabled" 加 defaultThinkingBudget(effort)。134.7、4.8、5 和 Fable 5/5.1 不在 5.5 那三个判断里，于是都落进通用分支。中招名单正好是这批模型。
同一条问题还有第二条入口：原生
/v1/messages。v0.2.17 在这里只做了一件事——按模型改中文 LLM 的 thinking.type 协议差异，注释写明 claude-* 不会进这段。14客户端自己发
enabled，代理原样转给上游。谁会撞上
一类是客户端只对旧模型 ID 做 adaptive 判断。PR 引的是 XiaomiMiMo/MiMo-Code 的 #1765，用
claude-sonnet-5 复现：客户端认得的模型名发 adaptive，认不得的照旧发 enabled。另一类是从 Chat Completions / Responses 进来、带了
reasoning_effort 的请求：只要映射后的档位不是 low，就落进通用分支。模型映射救不了。转换那一步用的是请求里的模型名，旧模型落进通用分支发
enabled；映射到 adaptive-only 模型之后，请求体里的 enabled 一个字没变，照样撞上 400。合并前能做的三件事
- 别给这批 adaptive-only 模型设
reasoning_effort。不传这个字段，就不会生成thinking，也就没有 400。 - 原生
/v1/messages的客户端改成thinking.type=adaptive，把budget_tokens去掉。 - 一定要用
reasoning_effort的，先走 5.5 家族——专属分支已经把adaptive写对了。
PR #8180 在 20:46 开出，7 个文件、+303/−7，仍是 open，
mergeable_state 是 unstable，没有评审。它新增了 claude.RequiresAdaptiveThinking 来识别这批模型，并把转换层与原生转发两处都改成 adaptive。作者在 PR 正文里说，生产环境的
claude-fable-5-1 经 /v1/chat/completions 已经实际命中过这个 400；这句是报障人的自述，本刊没有独立复现。
switch effort 之后是 5.5 的专属逻辑，第 138–142 行才是所有其它模型的通用写法，Type: "enabled" 加 defaultThinkingBudget。原文见该文件。另外三条
sub2api #8179：给 Anthropic OAuth 加请求补丁挂点。 20:44 开出，27 个文件、+1513/−149，open，
mergeable_state 是 unstable，21:06 还在更新。15 它新增能力名 anthropic.oauth.request_patch.v1：插件返回最终请求头和 JSON 正文补丁，OAuth、代理、TLS、连接池、重试、SSE 与计费仍走宿主自己的链路。补丁 RPC 最多 5 秒，正文上限 64 MiB，会挡掉认证、Cookie、代理凭据与 URL 里的 userinfo 和查询串。不覆盖 API Key、Setup Token、Vertex、Bedrock、OAuth 登录和 Token 刷新。这直接回应上期登记的 #8178。v0.2.17 的插件清单里只有 OpenAI OAuth 的 outbound transport，没有这个能力；要靠插件改 Claude 请求体的部署，得等它合入并发版。
codex2api #795：降智检测的题面缺了离线约束。 20:44 开出，默认题面
CandyPrompt 里没有“不允许调用工具和联网”，结尾的“只回复数字结果”写成了“只恢复数字结果”。16已经有部署的话，升级不会自动改题面：默认设置只在库里没有这一行时写入，
ON CONFLICT(id) DO NOTHING。18 题面要自己在管理页里改。
INSERT ... ON CONFLICT(id) DO NOTHING 落库，已有实例的题库不会被升级覆盖。原文见该文件。上期三条仍在原地。 CLIProxyAPI 的 #6716（按需 compaction 被注入的
context_management 顶回 400）、#6717（response.metadata 透传）、sub2api 的 #8177（Gemini 拦 prompt 时 input_tokens 记负数）都还是 open，本窗口没有新评审。机制上期讲过，这里只记状态。上游与额度：本窗口没有变化
OpenAI 状态页全绿，活动事件 0；最近一条仍是 Compliance API 的成本数据延迟，10 月 16 日 18:44（北京）标记解决。19 Anthropic 全绿，10 月 17 日没有事件。20 Google Cloud 的 incidents.json 仍是 7 条，最近一条停在 10 月 8 日到 9 日的 Cloud Storage。21
Codex 重置今天按 UTC 还没发生：最近一次已验证的全局重置在 10 月 15 日 14:13（北京），累计 54 次全局重置、10 次 banked，节奏约 4 天一次，24 小时内 42%、48 小时内 66%。22 Codex 负责人 @thsottiaux 本窗口没有新帖，最近一条是 10 月 16 日 13:51（北京）的“Either we are out of ideas or we are cooking”。23
OpenAI 开发者社区的 Codex 分区窗口内没有新话题，最新一条停在 19:58（北京）。24
References
- 1sub2api releases
github.com
- 2CLIProxyAPI releases
github.com
- 3codex-proxy releases
github.com
- 4codex2api releases
github.com
- 5提交 4f2e5270
github.com
- 6issue #6707
github.com
- 7claude_executor_stream.go 第 411–443 行
github.com
- 8code_handlers.go 第 496–512 行
github.com
- 9config.example.yaml 第 205–219 行
github.com
- 10
- 11PR #6708
github.com
- 12PR #8180
github.com
- 13
- 14gateway_forward.go 第 370–382 行
github.com
- 15PR #8179
github.com
- 16engine.go 第 41 行
github.com
- 17engine.go 第 44 行
github.com
- 18
- 19status.openai.com
status.openai.com
- 20status.anthropic.com
status.anthropic.com
- 21status.cloud.google.com
status.cloud.google.com
- 22codex-reset.com
codex-reset.com
- 23@thsottiaux
x.com
- 24Codex 分区
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.