完善 GPT-5.6 三模型元数据与 Fast 兼容 / Complete GPT-5.6 metadata and Fast compatibility

[Yuimi-chaya]

Important

2026-07-13 官方上下文回滚提醒

官方于 2026-07-13 宣布：GPT-5.6 Sol 的上下文上限已从 372K 临时回滚至 272K，并计划在后续数日重新开放 372K。为避免 Codex++ 在服务端实际上限仍为 272K 时错误声明 372K、延迟压缩并造成上下文超限，本 PR 已同步撤回 372K 元数据，当前三款 GPT-5.6 兼容目录均保守使用 272K。模型识别、推理档位和 Fast 兼容修复不受影响；待官方确认恢复后再单独跟进。

Official context rollback notice (2026-07-13)

OpenAI announced on 2026-07-13 that GPT-5.6 Sol's context limit was temporarily rolled back from 372K to 272K, with 372K planned to return in the following days. To avoid advertising a window larger than the active server limit, delaying compaction, and causing context-limit failures, this PR now withdraws its 372K metadata and conservatively reports 272K for all three GPT-5.6 compatibility entries. Model recognition, reasoning-effort, and Fast compatibility fixes remain unchanged; 372K can be revisited after the official rollout is confirmed.

中文说明

摘要

本 PR 独立完善 GPT-5.6 Sol / Terra / Luna 在 Codex++ 启动链中的模型元数据、推理档位、当前 272K 上下文与 Fast 能力兼容。

本 PR 不再提供自定义 Max 按钮或请求覆盖。Codex App 已通过“设置 → 配置 → 模型功能 → 可用推理强度”开放原生 max；在 API Key / 第三方 Responses 场景中，已真人验证选择“最高”后，新会话第一条请求会直接以 reasoning.effort=max 到达 NewAPI。

为什么仍需要这个 PR

官方原生 Max 解决了推理请求本身，但没有解决第三方供应商经 Codex++ 启动时的模型目录兼容问题：

• 直接启动 Codex App 时，既有 GPT-5.6 会话可能显示为“自定义模型”，但原生推理档位完整。
• 经 Codex++ 启动时，Sol / Terra / Luna 能显示为独立模型；如果只注入简化目录，App 会把它们降级为通用自定义模型元数据，导致推理档位减少、上下文信息不完整，Fast 能力也可能被误判为不支持。
• 新版 Codex 已整合进 ChatGPT Desktop，dispatcher 的导出位置和形态会变化；继续依赖固定导出名会造成 Fast 请求补丁偶发找不到后端 dispatcher。

因此本 PR 只补齐 Codex++ 仍需负责的“模型目录与启动链兼容”，不与官方已经可用的 Max 功能竞争。

实现内容

• 提供 GPT-5.6 Sol / Terra / Luna 的运行时兼容元数据、默认推理档位和当前官方 272K 上下文。
• 保留官方逐模型能力：Sol / Terra 支持至 ultra，Luna 支持至 max。
• 为三款 GPT-5.6 模型声明 Fast / priority service tier 能力。
• renderer 创建或修补模型描述符时使用后端可信元数据，不再回退成固定四档通用描述符。
• 同时兼容 setting-storage-* 与 vscode-api-* 中的 dispatcher，并支持 singleton 和 class 两种导出形态。
• 保护供应商显式配置的外部 model_catalog_json，不会因为检测到 GPT-5.6 就覆盖用户文件。
• 保留无后缀 gpt-5.6 等未知模型名，不擅自猜测为 Sol / Terra / Luna。

原生推理档位说明

当前中文界面存在两个“极高”，内部值并不相同：

• 高 → high
• 第一个 极高 → xhigh
• 最高 → max
• 带“更快消耗使用额度”的第二个 极高 → ultra

Fast 与上述推理档位相互独立，其请求值为 service_tier=priority。

已移除的实验性 Max 补丁

早期版本曾为了绕过 App 隐藏的 Max gate，加入按会话按钮、renderer 状态、helper route、运行时 localhost provider 包装和最终 Responses 改写。官方原生链路经实测可正确发送 max 后，这些代码已全部从本 PR 删除，避免双重入口、状态冲突和不必要的本地代理复杂度。

验证

• node --check assets/inject/renderer-inject.js
• npm run check
• cargo fmt --all -- --check
• Windows watcher 识别正式 OpenAI.ChatGPT-Desktop_* 包；watcher 17/17、core 全套通过。
• Windows 广告 fallback mock 读取完整请求头并显式关闭连接，避免 loopback RST/abort；目标测试连续 10 次通过。
• cargo test -q -p codex-plus-core --test cdp_bridge -j 2：69 passed
• cargo test -q -p codex-plus-core --test model_catalog --test model_suffix --test relay_config -j 2：7 + 14 + 99 passed
• 契约测试明确验证三款 GPT-5.6 的 Fast 白名单、Sol 的 max/ultra 描述符、新旧 dispatcher 导出，以及自定义 Max 控件和设置字段不存在。
• 真人验证：关闭 Codex++ 自定义 Max 覆盖后，选择官方“最高”创建新会话，第一条 API Key / Responses 请求在 NewAPI 后台显示为 max。

English

Summary

This PR independently completes model metadata, reasoning-level, current 272K context-window, and Fast capability compatibility for GPT-5.6 Sol, Terra, and Luna in the Codex++ launch path.

It no longer provides a custom Max control or request override. Codex App now exposes native max through Settings → Configuration → Model features → Available reasoning strengths. Human validation with an API-key/third-party Responses provider confirmed that selecting native Max sends reasoning.effort=max on the first request of a fresh thread.

Why this PR is still needed

Native Max fixes the reasoning request itself, but it does not solve model-catalog compatibility when third-party providers are launched through Codex++:

• When Codex App is launched directly, an existing GPT-5.6 thread may appear as a custom model while retaining the complete native effort list.
• Through Codex++, Sol, Terra, and Luna can be exposed as separate models. A reduced injected catalog can still downgrade them to generic custom-model metadata, reducing visible efforts, losing context information, and incorrectly marking Fast as unsupported.
• Recent Codex builds are integrated into ChatGPT Desktop. Dispatcher exports can move and change shape, so relying on one fixed export causes intermittent Fast request-patch failures.

This PR therefore keeps only the model-catalog and launch-path compatibility that Codex++ still owns, without competing with the now-working native Max feature.

Implementation

• Adds runtime-compatible metadata, default reasoning efforts, and the current official 272K context window for GPT-5.6 Sol, Terra, and Luna.
• Preserves official per-model capabilities: Sol and Terra support through ultra; Luna supports through max.
• Declares Fast / priority service-tier capability for all three models.
• Uses trusted backend metadata when renderer model descriptors are created or repaired instead of falling back to a fixed four-effort generic descriptor.
• Discovers dispatchers from both setting-storage-* and vscode-api-*, supporting singleton and class export shapes.
• Preserves explicitly configured external model_catalog_json files instead of overwriting user-owned catalogs merely because they contain GPT-5.6.
• Preserves unknown names such as unsuffixed gpt-5.6 instead of guessing a Sol/Terra/Luna mapping.

Native reasoning labels

The current Chinese locale uses the same visible label for two different effort values:

• High → high
• first Extra High → xhigh
• Max → max
• final Extra High with the usage warning → ultra

Fast is independent from reasoning effort and uses service_tier=priority.

Retired experimental Max patch

An earlier revision added a per-thread control, renderer state, helper route, runtime localhost provider wrapper, and final Responses rewrite to bypass the App's hidden Max gate. Once the native path was verified to send max correctly, all of that code was removed from this PR to avoid duplicate controls, conflicting state, and unnecessary local-proxy complexity.

Validation

• node --check assets/inject/renderer-inject.js
• npm run check
• cargo fmt --all -- --check
• The Windows watcher recognizes official OpenAI.ChatGPT-Desktop_* packages; watcher passed 17/17 and the full core suite passed.
• The Windows ad-fallback mock reads complete request headers and closes connections explicitly, avoiding loopback RST/abort; the targeted test passed 10 consecutive runs.
• cargo test -q -p codex-plus-core --test cdp_bridge -j 2: 69 passed
• cargo test -q -p codex-plus-core --test model_catalog --test model_suffix --test relay_config -j 2: 7 + 14 + 99 passed
• Contract coverage verifies the GPT-5.6 Fast allowlist, Sol max/ultra descriptors, old and new dispatcher export shapes, and the absence of the custom Max control and setting.
• Human validation: with the Codex++ custom Max override disabled, selecting native Max for a fresh thread produced max in NewAPI on the first API-key/Responses request.

[fanyang12]

大佬，Fast模式支持最新模型修复了吗？

[alfred1994]

求合并, 5.6的fast现在用不上

[Yuimi-chaya]

@BigPizzaV3 打扰提醒一下，这个 PR 当前 Windows、macOS x64、macOS arm64 三平台 CI 已全部通过，分支状态为 CLEAN，但暂时还没有收到维护者 review。

该 PR 补充 GPT-5.6 Sol / Luna / Terra 的完整模型元数据，并修复这些模型在 Codex++ 注入后的 Fast 支持判断。目前评论区也已有用户反馈 GPT-5.6 的 Fast 无法正常使用。

这部分改动是独立的模型元数据与兼容性修复，不依赖其他大型 PR。想请您抽空重点看一下：

• 三个 GPT-5.6 模型的元数据映射；
• 推理档位及模型描述符兼容；
• GPT-5.6 的 Fast 支持判断；
• 新版 ChatGPT / Codex Desktop 下的进程与模型状态兼容。

如果当前上游模型定义已有新的调整，或希望换一种实现方式，也请直接指出，我会按最新主仓结构继续适配。

[ShallowDream724]

建议尽快review，fast真的很重要！！Fast 应该也是大多数用户核心需求之一？

[wanxiaoT]

求合并 求合并