怎么判断 Codex 5.6-sol 被降智到了 Luna？

最近我们在测试 Codex API (backend-api/codex/responses) 时，发现了一个非常隐蔽的现象：明明请求的是最强的 gpt-5.6-sol，返回的模型名也是它，但实际跑起来的“智商”却像是被降级成了 luna。

通过抓包和分析 WebSocket 遥测数据，我们终于找到了确凿的证据，并初步摸清了 OpenAI 这套动态路由（也就是大家常说的“限流”或“降智”）的黑盒逻辑。

1. 怎么确认自己被“降智”了？

以前判断是否被降智很玄学，只能靠回答问题的质量猜。但现在，我们可以通过 WebSocket Timing 里的真实引擎 ID 来直接“验尸”。

关键证据链

当我们发送一个标准的 response.create 请求时，服务器会返回一系列事件。正常情况下，我们应该看到以下一致性：

1. 客户端请求：model = "gpt-5.6-sol"
2. 最终响应名称：response.completed.response.model = "gpt-5.6-sol"
3. 底层引擎 ID：timing_metrics.engine_ids = "gpt56sol-codex-..." ✅

但是！在“降智”发生时，会出现这种“表里不一”的情况：

• 请求模型：gpt-5.6-sol
• 展示模型：gpt-5.6-sol
• 底层引擎 ID：gpt56lun-codex-... ❌ (注意这里变成了 luna)

结论：只要 engine_ids 里出现了 gpt56lun，不管前端显示什么，你实际上都在跑 Luna 模型。这是目前最准确的判断标准。

2. 触发降智的“开关”在哪里？

除了看引擎 ID，我们在 HTTP 响应头里还发现了一组非常关键的字段，它们揭示了 OpenAI 内部的资源调度逻辑：

x-codex-primary-used-percent: 100       ← 算力预算使用率 (0~100)
x-codex-primary-window-minutes: 10080   ← 统计窗口期 (7天)
x-codex-active-limit: premium           ← 当前账户等级
x-codex-safety-buffering-faster-model: gpt-5.6-luna ← 备胎模型

核心发现：
当 x-codex-primary-used-percent 达到 100 时，意味着你的账号在该时间窗口内的“高速算力预算”已耗尽。此时，OpenAI 会自动把你路由到 x-codex-safety-buffering-faster-model 指定的备胎模型——也就是 gpt-5.6-luna。

简单来说：不是你不配用 Sol，是你的“油表”空了，系统自动切到了省油的备用模式。

3. 不同账号类型的“降智”表现

我们用 Pro、Team、Plus 等不同类型的账号做了大量对比测试，发现了一些规律：

🔹 Pro / Plus 账号

• 正常情况：如果是正价号、iOS 支付号或者菲区号，在并发正常、IP 干净的情况下，基本稳如泰山，不会轻易降智。
• 异常触发：一旦使用了中转站，或者短时间内并发/额度消耗过快，很容易瞬间触顶，路由到 Luna。
• 玄学的 IP 效应：
  • 在 AWS 光帆机（支持重启换 IP）上测试发现，更换 IP 确实能显著改善“智商”。
  • 有些正价 Pro 号之前一直被路由到 Luna，换个干净的 AWS IP 后，立刻恢复 Sol 水平。
  • 注：但这事儿有点玄学，不能保证 100% 成功，可能跟 IP 信誉度有关。
• 自救方法：部分账号降智后，登录并更改绑定邮箱可以重置状态，恢复 Sol；但也有少数案例，换了邮箱依然被路由到 Luna。

🔹 Team 账号

• 注册来源决定命运：
  • 手动正规注册：表现类似 Free 号，有时好有时坏，存在随机性。
  • 协议批量注册：降智速度极快，几乎一上来就给你走 Luna。
  • 注：由于 5xteam 号商邀请样本较少，此点仅为初步观察。

🔹 Plus 账号

• 正价号和首月优惠号的差距不大。目前市面上能买到的 Plus 号多为批量注册，因此普遍存在较快的降智倾向。

4. 总结与建议

目前的账号降智机制确实非常黑盒，没有明确的官方文档说明。但通过上述分析，我们可以得出一些实用的经验：

1. 不再盲猜：直接监听 websocket_timing.engine_ids，如果是 gpt56lun-*，那就是真降智了。
2. 关注“油表”：如果响应头里 primary-used-percent 接近 100，大概率接下来会被切到 Luna。
3. 环境优化：
   • 避免使用高频率的中转站。
   • 对于 Pro/Plus 用户，尝试使用高质量的独立住宅 IP（如 AWS 实例），可能对稳定路由有帮助。
   • 控制并发节奏，避免在短时间内打满算力预算。

这只是一个抛砖引玉的观察报告，后续还需要更多的账号和数据来验证这些规律。希望这些信息能帮大家在开发 Codex 应用时少走弯路！