fable5.1分析GPT6降智：基于 codex 源码、GitHub issue 抓包与中英文社区观测的机制拆解

作者：#kafukasun 板块：#搞七捻三 我最近几天一直在跟我hermes里的fable5.1讨论GPT6降智的机制，我说我要对我之前的帖子进行跟进，和佬友共同分析。我说你是世界上最强的模型，你给我仔细分析，然后他写了下面内容。最后一段话也是它写的，不是我加的。 GPT-6 Astra「降智」不是一个开关，是六条独立管道——基于 codex 源码、GitHub issue 抓包与中英文社区观测的机制拆解 本文为楼主跟进帖。分析由 Claude（fable 5.1）基于 2026-09-14 之前公开可查的材料完成，楼主复核并补充了自身账号实验。所有判断按证据强度分级标注：【实锤】= 有源码/抓包/官方原话；【多源观测】= 至少两名互不相识的用户独立复现；【推断】= 逻辑自洽但尚无直接证据。欢迎打脸。 0. 先纠正一个前提：不只是中文圈 上一帖我说「X 上抱怨的基本都是简体中文用户」。这两天扩大搜索范围后，这个判断要修正。英文社区的同类报告其实不少，只是它们分散在 openai/codex 的 GitHub issue、OpenAI 开发者论坛和 Reddit r/codex 里，而且措辞是 “quality drop”“silent reroute”，不是「降智」： • openai/codex#45037（9 月 12 日）：Linux 用户在 TUI 选了 gpt-6-astra，HAR 抓包显示 WebSocket 里实际发出的 response.create 是 model: gpt-5.6-luna，同一连接的头里带 x-codex-routing-hint: model=gpt-5.6-luna;tier=priority（issue 作者写的是响应头，但按源码这是客户端发出的请求头——恰恰说明是客户端自己改了模型，见管道 A）。 • openai/codex#44637（9 月 10 日）：macOS Pro 用户，Astra 线程触发「额外安全检查」提示后，当天大部分请求被静默改到 gpt-5.5，UI 全程显示 Astra，本地 session 文件也没记录任何改道。 • openai/codex#43446（9 月 7 日）：UTC+8 用户，反复 503 overload 后成功的那次请求，模型自称「我不是 Astra」。 • Reddit r/OpenAI：「Codex 反复把 Sol-High 静默降到 Luna-Low」「GPT-6 Astra 已经被降级了？」；r/codex：「Astra 每 30 秒轮询 Luna worker 烧掉大部分配额」。 • X：@karinadoteth「多个 Codex CLI 会话因为 Astra 排队被降到 Luna」；@Enheduanni「官方宣布修复后 Astra Max 依然路由到 Luna」；Opencode 作者 Dax Raad 整个团队退回 Sol。 所以「为什么是中文用户」的正确问法是：为什么中文用户命中率更高、且更能精确指认。后面第 4 节回答。 1. 客户端能看到什么：codex-rs 源码里的路由契约 先把服务端和客户端之间关于「用哪个模型」的协议摆出来，这是理解一切的地基。以下来自 openai/codex 主分支（commit 3abbf9f，9 月 14 日）。 请求方向（客户端→服务端）： • x-codex-routing-hint: model=<slug>;tier=<service_tier>——客户端告诉服务端「我想要什么模型、什么服务层级」。注意它叫 hint（提示），不叫 requirement。 • x-codex-turn-state——粘性路由 token。服务端在一个 turn 开始时下发，客户端在同一 turn 内的所有后续请求必须原样带回，跨 turn 必须丢弃。源码注释原话：「Reusing it across turns would replay the previous turn’s sticky-routing token into the next turn, which violates the client/server contract and can cause routing bugs.」 • x-codex-turn-metadata——一个大 JSON 块，包含 installation_id、session_id、thread_id、turn_id、window_id、subagent 信息、sandbox 模式、工具清单、analytics 开关等几十个字段。 • x-codex-installation-id、x-codex-beta-features、x-codex-parent-thread-id、x-codex-window-id。 • 另外，环境上下文（<timezone>America/Los_Angeles</timezone> 这种）是写在 prompt 里发给模型的，不是 header。 响应方向（服务端→客户端）： • openai-model / x-openai-model 响应头——服务端告知实际服务模型。客户端只在 WebSocket 握手时和 SSE 响应头里读它，不读 response.model 字段。 • response.metadata 事件里的 safety_buffering 对象，字段：model、use_cases[]、reasons[]、retry_model。这就是「此请求需要额外安全检查」提示的数据源，retry_model 就是提示里「用更快的模型重试」的那个模型。 • ModelRerouteEvent { from_model, to_model, reason }，而 reason 枚举目前只有一个值：HighRiskCyberActivity。触发时客户端会弹警告：「Your account was flagged for potentially high-risk cyber activity and this request was routed to gpt-5.2 as a fallback」（文案还停留在 5.3-codex 时代，说明这条路径很久没人维护）。 • ModelReroute 和 SafetyBuffering 事件在 rollout/src/policy.rs 里被标为 transient，不写入 session 文件。 由此得出三个【实锤】结论： 1. 服务端有一条「账号级」改道路径（HighRiskCyberActivity 是 account flag，不是 request flag）。 2. 服务端有一条「请求级」改道路径（safety_buffering 按 use_cases/reasons 分类，给出 retry_model）。 3. 客户端识别改道的唯一信号是 openai-model 响应头。WebSocket 连接一旦建立会复用数小时（#44637 的用户 16 小时线程只有两次握手），握手时发的头无法反映后续改道；如果服务端选择不发这个头，客户端就完全不知道，UI 继续显示 Astra，磁盘上也不留痕。#44637 的作者查了自己 app-server 日志里 9 月 2 日以来全部 55 次握手，没有一次带 openai-model。 换句话说：协议在设计上允许服务端静默换模型，而客户端在实现上无法发现。这不是阴谋论，是源码。 2. 六条管道 把所有一手材料按「谁决定换模型、为什么换、换成什么」归类，我数出六条彼此独立的机制。它们可以叠加，这是「逻辑不明」的根本原因——不同人踩的是不同组合。 管道 A：客户端 Luna Reserve 自动切换【实锤】 openai/codex 9 月 2 日 commit 5037919「Add Luna Reserve usage fallback to the TUI」：当 /wham/usage 返回 ordinaryUsageAllowed: false 且 gpt-reserve 池有余量时，TUI 自动把当前任务切到 Luna Reserve，保留原模型设置，等配额恢复后切回。伴随一条可关闭的 banner：「You’re now using Luna, a faster model for simpler tasks.」 #45037 的抓包就是这条管道的样子：analytics 事件仍记 model_slug: gpt-6-astra，但真正发出去的是 gpt-5.6-luna。用户以为服务端偷换，其实是自己的客户端换的。这条管道 9 月 8 日前后随 0.153/0.154 铺开，与降智集中爆发的时间窗完全重合。 关键点：ordinaryUsageAllowed 是服务端下发的布尔值。它为 false 的原因可以是配额真的用完，也可以是任何服务端想让它为 false 的原因。#44229 报告周配额从 83% 瞬间掉到 36%，另两人从 70%/52% 瞬间归零——配额记账本身在 9 月 9 日前后就不稳定。 管道 B：服务端安全改道【实锤 + 多源观测】 源码里的 safety_buffering → retry_model 路径，