fix(model-providers): 自定义 Codex 模型放开 max 档 effort

[zhanxin-xu]

这次改了什么

摘要

自定义供应商 Codex 模型的 effort 兜底档位从四档(low/medium/high/xhigh)放开到五档(+max),与 claude-code 的自定义档位对齐。此前 CUSTOM_EFFORTS.codex 写死四档,glm-5.3 这类未命中 Registry 的自定义模型在 UI 中选不到 max;协议与引擎层(turn/start 透传 effort)本就支持,只是被目录档位门控。

产品口径:第三方 Responses 兼容端点是否接受 max 只有端点方/用户知道——大多数端点接受,不接受的会明确拒绝,用户改选即可,兼容性由选择者承担。默认档保持 high,存量用户无感。

变更类型

• fix 缺陷修复

范围

• 关联 Issue / 需求:Closes 自定义供应商的 Codex 模型无法使用 max 档 effort（写死到 xhigh） #2964;与 feat(model-providers): expose max and ultra for custom Codex models #2912(同议题的 fallback 扩展 PR,含 ultra、待产品确认)互为替代方案——若维护者采纳逐模型声明或 feat(model-providers): expose max and ultra for custom Codex models #2912 的六档方案,本 PR 可直接关闭
• 本 PR 包含:packages/model-providers 中 CUSTOM_EFFORTS.codex 补 max 档及注释更新、user-provider.test.ts 对应断言更新
• 明确不包含:ultra 档(仍仅限 Registry 已登记模型如 GPT-5.6 Sol)、逐模型声明机制(见 issue 中分析评论的完整方案)、anthropic-responses-bridge 的 effort 收敛(那是 CC 引擎对内置 x.ai/codex 端点的既有行为,与 codex 引擎自定义供应商路径无关)
• 用户可见变化:自定义 Codex 模型的 effort 选择器多出「Max」档;默认档与存量行为不变
• 是否存在 breaking change:无

UI 变化

• 引用的设计规范:不涉及:无 UI 代码改动;效果是选择器档位列表由 catalog efforts 驱动自动多出 max。

怎么验证的

自动验证

pnpm install
结果:通过(5m48s)

pnpm test:unit:related
结果:packages/model-providers PASS(含改动后的 user-provider.test.ts)、apps/mobile PASS;
     apps/desktop 全量 2004 文件 / 26770 用例中 2 个失败,均在
     src/main/cindy-brain/__tests__/ghostInstallReceipt.test.ts —— 已在
     stash 掉本改动后于干净 main 复跑同一文件确认同样失败(2 failed | 9 passed),
     为存量问题、与本次改动无关。首次跑门禁时 desktop 在 maxWorkers=8 下进程
     SIGSEGV(基础设施抖动),降到 4 workers 后完整跑完,仅上述存量失败。

pnpm --filter @cindy/model-providers run --if-present typecheck
结果:该包无 typecheck script(自动跳过);补跑 pnpm --filter @cindy/model-providers run build
     (tsc --noEmit)有 2 个错误,均在未改动的 src/__tests__/catalog.test.ts —— 同样
     在干净 main 上复现(同为 2 个),存量问题、与本次改动无关。

手工验证

不涉及(无运行时行为分支:档位列表由静态表投影,单测已覆盖)。

未执行的验证

• fake OpenAI Responses upstream 的 max 端到端透传断言、GLM Coding Plan 真实端点的 xhigh/max 实测:本机为受限网络环境,未搭起 fake upstream;issue 分析评论中的验收建议 3/8 留给维护者按需复核(引擎透传链路已有内置 GPT-5.6 Sol max/ultra 档位在生产使用佐证)。

风险

风险分类

• 无已知风险
• 其他:第三方端点可能不接受 max,请求会被上游拒绝(明确报错,非静默);用户改选 xhigh 即可,默认档与存量行为不变。

影响与回滚

• 影响范围:仅自定义供应商 Codex 模型的档位列表;Registry 可确认能力的模型仍优先继承目录声明,ultra 不放行。
• 回滚 / 降级方式:单 commit,revert 即完全回到四档。

提交前检查

• 已 review 完整 diff
• 每个 commit 都带 DCO 签名(pnpm check:dco 通过)
• UI 改动已在「UI 变化」注明引用的设计规范章节(不涉及 UI 则跳过)
• 未提交凭证、令牌或授权文件
• 已补充必要文档
• 已确认测试结果或说明未执行原因

[greptile-apps]

Greptile Summary

自定义 Codex 模型的兜底 effort 档位新增 max，默认档仍为 high；相关单元测试断言已同步更新。

• 未命中或无法唯一匹配 Registry 的自定义 Codex 模型现在提供 low/medium/high/xhigh/max
• Registry 中已有明确能力声明的模型仍优先使用其目录档位
• 未加入 ultra，也未改变默认 effort

Confidence Score: 5/5

该 PR 看起来可以安全合并，未发现需要阻止合并的具体问题。

新增的 max 已包含在现有 Effort 与 Codex effort 类型中，并能通过解析及请求链路原样传递；Registry 的明确模型声明仍保持优先。

Important Files Changed

Filename	Overview
packages/model-providers/src/user-provider.ts	将自定义 Codex 模型的 fallback effort 列表扩展至 max；现有类型、解析和 Codex 传递链路均支持该值。
packages/model-providers/src/tests/user-provider.test.ts	更新四类 fallback/未登记模型场景的预期档位，覆盖新增的 max。

_{Reviews (1): Last reviewed commit: "fix(model-providers): 自定义 Codex 模型 effor..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 376a0047b9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[MagicLizi]

@zhanxin-xu 👋 这个 PR 还有 1 条 review conversation 没 resolve(packages/model-providers/src/user-provider.ts),auto-review 因此暂时跳过、没法继续审查 / 合并。

如果你已经按评论改完或回应了,请到对应 thread 上点 Resolve conversation;全部 resolve 后,下一轮 auto-review 会自动重新审查这个 PR。

[MagicLizi]

审查通过:17 行纯功能开放(codex custom efforts 加 max),测试覆盖充分,设计意图已在代码注释文档化,无安全/性能/兼容性问题。

[MagicLizi]

自定义 Codex 模型开到五档 effort 是个贴心的补全——用户连了第三方 Responses 端点,不用再因为选项比官方少而多想。设计决策的注释写得清楚,测试也对齐了。🎯