维护者确认 · #2912 feat(model-providers): expose max and ultra for custom Codex

[MagicLizi]

确认类别

product

触发原因

为自定义 Codex provider 暴露 max/ultra effort 档位，属产品功能扩展。

需要维护者确认

新增用户可见的模型能力档位，需确认产品定位。

如何放行

在 PR 上 Approve 即可；如需作者修改请 Request Changes。

---

关联 PR:#2912(作者 @xiaojunonode);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断： 自定义 Codex 用户应能使用端点明确支持的 max / ultra，但不建议按 #2912 当前方案对所有未登记或歧义匹配模型统一开放六档。当前真正可直接修复的缺口是：多个 Registry 匹配项对 Codex 声明了完全相同的 effort 能力时，代码仍将其视为歧义并回退到四档。

行动： 建议对 #2912 Request Changes，将实现调整为“能力共识”继承：多个匹配条目的 efforts 与归一化后的 defaultEffort 完全一致时继承；只有能力声明冲突时才保守回退。任意未登记模型的高级档位应通过逐模型显式声明另行设计，不建议通过扩大全局 fallback 完成。

当前源码事实

基于 origin/main@a201619aebe71140d2c3ad40e5b45020553da75e：

1. packages/model-providers/src/user-provider.ts 已包含 fix(pi): 补齐国产模型官方元数据 #2572 合入的 Registry 能力投影：

   • 非 Pi 自定义模型会调用 registryEffortMetadata()；
   • 匹配成功时读取 perAgent[agent].efforts/defaultEffort，否则读取根级声明；
   • 自定义 Provider ID、模型 ID、Base URL 和路由保持不变。

2. 当前匹配条件要求唯一 Registry entry：

   const uniqueEntries = [...new Map(matches.map((entry) => [entry.id, entry])).values()];
   if (uniqueEntries.length !== 1) return undefined;

   因此，只要同一个裸模型路由命中两个不同 entry，即使它们对 Codex 声明的 efforts/defaultEffort 完全一致，也会回退到：

   low / medium / high / xhigh
   

3. 现有测试只覆盖了“多个 entry = 一律回退”，尚未区分：

   • 多个匹配、能力完全一致：可以安全继承；
   • 多个匹配、能力存在冲突：应继续回退。

4. feat(model-providers): expose max and ultra for custom Codex models #2912 当前改动不是修正上述匹配规则，而是把所有自定义 Codex fallback 直接扩大为：

   low / medium / high / xhigh / max / ultra
   

   这也会影响 Registry 未登记的模型以及能力声明冲突的模型。默认档位仍是 high，因此不会自动提高消耗；但用户手动选择端点不支持的档位时，仍可能收到上游原生 4xx。PR 尚未提供真实自定义端点的端到端验证。

产品与实现建议

本次可直接推进：能力共识匹配

建议修改 registryEffortMetadata()：

1. 收集所有匹配 entry 对目标 Agent 的有效 efforts；
2. 按现有规则归一化每项 defaultEffort；
3. 若所有匹配项的档位顺序和默认值均一致，则继承该共同能力；
4. 若任一项缺少声明或彼此冲突，则维持当前保守 fallback；
5. 不改变 Provider、模型 ID、Base URL、鉴权或路由。

至少补充以下回归测试：

• 两个 Registry entry 共享同一 Codex 裸路由，且均声明六档与相同默认值：自定义模型应获得 max/ultra；
• 两个匹配 entry 的档位或默认值不同：继续回退四档；
• 未登记模型：行为保持不变；
• 请求仍使用用户配置的自定义 Provider 路由。

这能解决已有 gpt-5.6-sol / terra 用户问题，同时延续 #2572 已确立的可信能力投影方式。

另行确认：未登记模型的显式声明

对于 glm-5.3 等 Registry 未登记模型，用户或供应商确实可能比 Cindy 更清楚端点能力。更稳妥的增强是允许自定义 Codex 模型显式配置：

• efforts；
• defaultEffort，且必须属于 efforts；
• 用户显式声明与 Registry 元数据发生冲突时的优先级；
• 错误声明可能导致上游拒绝的提示。

Pi 已有 reasoningEfforts/reasoningDefaultEffort 契约，可作为数据校验参考，但是否原样扩展到 Codex 仍是产品决策，不必阻塞上述能力共识修复。

验收建议

1. 使用自定义 OpenAI Responses Provider 配置 gpt-5.6-sol。
2. 在存在多个能力相同 Registry 匹配项时，确认显示 low / medium / high / xhigh / max / ultra。
3. 分别选择 max、ultra 发起真实请求，确认 effort 原样透传。
4. 确认请求仍命中用户配置的 Base URL、鉴权和模型 ID。
5. 覆盖新建会话、已有会话切换及协作 Worker。
6. 使用能力冲突和完全未登记的模型做反向测试，确认不会无依据地继承高级档位。

相关记录

• fix(pi): 补齐国产模型官方元数据 #2572：已合入自定义 Claude Code/Codex 从可信 Registry 继承 effort 的实现，并明确不对无法证明一一对应的端点猜测能力；这是当前应延续的产品与架构方向。
• 自定义 Codex Provider 中 gpt-5.6-sol/terra 被错误限制为四档推理强度 #2584：在 0.1.50 上复测仍只有四档，并进一步定位到多个能力等价 Registry entry 被 uniqueEntries.length !== 1 判为歧义的剩余缺口。
• 中转渠道的 gpt-5.6-sol 在主窗口和协作窗口无法识别 Max/Ultra #1536：同一用户现象的早期报告，覆盖主窗口和协作 Worker，证明该缺口会同时影响展示与发送前能力校验。
• 自定义供应商的 Codex 模型无法使用 max 档 effort（写死到 xhigh） #2964：覆盖 Registry 未登记模型，适合作为逐模型显式声明 efforts/defaultEffort 的独立增强需求。

[zqchris]

关联 PR #2912 已关闭，讨论随之关闭。