Fable 5.1 又报错，中转这侧另有两处让整轮失败：多一个事件、少一个 finishReason
Claude Fable 5.1 在 16:17 又开出一条 major 事故；同一小时里两处客户端兼容缺口同样会让请求整轮失败——Responses 流多转发了上游一个私有事件，Gemini 格式的流少发了一个结束原因。
Claude 状态页在 16:17 开出一条新事故：Fable 5.1 报错，影响标为 major，claude.ai、Claude API、Claude Code、Claude Cowork 四个组件同时 partial_outage。到发稿仍是 identified，没有修复时间。1
上一条事故在 15:53 标成已解决。它自己的解决说明写着影响发生在 14:05 到 14:35，也就是状态页把「已解决」多挂了 78 分钟。2
这一小时四个仓库没有新版本，主干也没有新提交。动作停在两张今天下午开出的单上：一条说 Responses 流多转发了上游的一个私有事件，另一条说 Gemini 格式的流少发了一个结束原因。两条都出在我们这一侧。
先分清这次的红灯在哪一侧
事故 08:17:08Z 开出，10 秒后从 investigating 走到 identified，两条更新都只说「正在修」。页面整体口径是 Minor Service Outage，Claude Console 与 Claude for Government 仍 operational。3
事故页同一屏给出的两条更新与受影响组件清单，时刻按页面显示为 UTC。
和上一条对比，能看出这次的边界窄得多。上一条点名五个模型——Mythos 5.1、Fable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5；这条只点名 Fable 5.1。
对混跑多个 Claude 模型的池子，这是今天最有用的一条判断依据：只有 Fable 5.1 那批请求在报错、其它 Claude 模型照常，那是上游按模型的问题。
近 33 小时里，这已经是第五条模型类事故。前四次分别是：10-23 23:37 三条模型同时报错，34 分钟；10-24 00:31 Opus 5.5，6 分钟；10-24 05:16 Fable 5 与 5.1，37 分钟；10-25 06:14 五条模型，影响 30 分钟。2
这段错误不要记到账号上。CLIProxyAPI 对 529 落在
default 分支，按模型级冷却 60 秒处理；sub2api 在非池模式下会把整个账号摘走 10 分钟。若错误体里只有 Fable 5.1，先按上游处理。多出来的一个事件：response.metadata
Codex 后端现在会发一个
response.metadata 事件，内容是 prompt-moderation 标记（源自 #6856）。它不属于公开的 Responses 事件，而 CLIProxyAPI 会把上游事件原样转给每一个 Responses 客户端。按封闭事件列表解析的客户端读到这个类型就结束整轮：Grok Build 1.0.60 与 1.0.70 报的是
unknown variant response.metadata。4过滤逻辑在
shouldFilterPrivateEvent：官方 Codex 客户端提前返回、保留全部事件；标准客户端只滤掉 codex. 前缀的私有事件。response.metadata 没有这个前缀，一路穿过去。5
V8.0.42 的
sdk/api/handlers/openai/openai_responses_handlers.go 第 156–172 行：Codex 客户端分支保留全部事件，标准客户端分支只拦 codex. 前缀。PR #6970 的改法就是给这行加一个
|| name == "response.metadata"，并补两张测试：标准客户端收不到该事件，官方 Codex 客户端仍收得到。到发稿未合并，dev 上第 165 行仍是 strings.HasPrefix(name, "codex.")。sub2api v0.2.18 上同名事件只被当作「还没产生可见输出」的元数据，用来判断能否安全换号。它的透传路径把上游事件原样写回下游，整包里没有按客户端筛事件的代码。6
所以两条中转上是同一个后果：下游只要有严格枚举 Responses 事件的客户端，且上游走 Codex，那一轮就可能死在这一个事件上。
能做的有两条。把这类客户端改走
/v1/chat/completions，那条路不产生这个事件；或者等 #6970 合并且发了新版再升。少掉的一个终点：缺 finishReason
第二条出在 Gemini 格式。
/v1beta/models/<model>:streamGenerateContent?alt=sse 的流在正常结束时没有 finishReason，gemini-cli 0.65.0 每一轮都报 Model stream ended without a finish reason.7报障人在 v8.0.35 上做了三次对照：claude-haiku-5-5 两块、带 STOP；gpt-6-luna 三块、没有；vLLM 的 glm-5.3-flash 两块、没有。Claude 模型那条路是通的。
两个独立成因，都在翻译层。
Codex→Gemini 的完成分支把
response.completed 与 response.incomplete 写在同一个判断里，但 finishReason 只在 incomplete 时设置。正常收尾的那一轮，什么也不写。8
V8.0.42 的
internal/translator/codex/gemini/codex_gemini_response.go 第 334–347 行：finishReason 只在第 344 行的 response.incomplete 分支里写入。OpenAI→Gemini 这条路更隐蔽：带内容或推理的块一进来就
return true，同一块里带的 finish_reason 根本走不到下面那段处理。v8.0.36 只补了带工具调用的那一条。9
同版本
internal/translator/openai/gemini/openai_gemini_response.go 第 147–152 行：chunkOutputs 非空且没有 tool_calls 时直接 return，第 214 行起的 finish_reason 处理不会执行。issue #6971 现在是 open，一条评论。作者在 main（bc064340）上验证了上面两处 diff：加上之后两个回归测试通过，不加两个都失败。我们核了 main 与 v8.0.42，两处代码都没变。
对读者来说，组合很清楚：把 gemini-cli 指到代理、上游是 Codex 或 openai-compatibility，这些模型就是坏的；上游是 Claude 则正常。临时办法是让这类客户端改走 OpenAI 格式的
/v1/chat/completions。这一小时没有新版本
四仓现状：CLIProxyAPI v8.0.42（10-24 22:21 发布，main 停在 22:17，dev 头 11:39）、sub2api v0.2.18（10-23 15:44，main 13:32）、codex-proxy v2.1.20（10-22 20:00，dev 19:54）、codex2api v3.1.1（10-16 21:42，main 10-24 19:52）。10
上游另外两处都安静：OpenAI 状态页回到 All Systems Operational，Responses 与 Codex in ChatGPT Desktop 都是 operational；Google Cloud 仍是 8 条事故，最新一次更新停在 10-22。1112
Codex 重置那边也没有新的：追踪站最新帖还是 06:07:41Z 那条「By midnight PST」，登记状态 pending、生效时刻为空；官方社区 Codex 分区窗口内 0 条新话题，最新一条停在 10-24 19:34。1314
处置顺序
先定侧别。错误体只点名 Fable 5.1、其它 Claude 模型正常，记上游；四个组件同时挂、时间也对得上，就别去动账号。
再看客户端协议。Responses 客户端会被那一个多出来的事件打断，Gemini 格式客户端会被缺失的 finishReason 打断，两者换到
/v1/chat/completions 都能绕开。等 #6970 合并、等 #6971 的 diff 进版，再把它们挪回去。References
- 1Claude 状态页这条事故
status.claude.com
- 2Claude 状态页 incidents 接口
status.claude.com
- 3Claude 状态页 summary 接口
status.claude.com
- 4CLIProxyAPI PR #6970
github.com
- 5
- 6
- 7CLIProxyAPI issue #6971
github.com
- 8
- 9
- 10CLIProxyAPI 发行记录
github.com
- 11OpenAI 状态接口
status.openai.com
- 12Google Cloud 事故列表
status.cloud.google.com
- 13Codex 重置追踪接口
codex-reset.com
- 14OpenAI 开发者社区 Codex 分区
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.