Feature request: per-model option to stop advertising synthetic max/ultra reasoning rungs on models that don't support them

What are you trying to accomplish?

I need to route Codex to the Alibaba Token Plan (Qwen) endpoint and have the model picker advertise only the reasoning efforts each Qwen model actually supports. For example, qwen3.8-max should offer low/medium/xhigh and not max/ultra, so the UI reflects the real capability of each model.

What prevents this today?

The catalog row for any reasoning-capable routed model is padded with synthetic top rungs. In src/codex/catalog/effort.ts, applyReasoningLevels appends max and ultra to every reasoning model unless preserveExact is set, and preserveExact only applies to exact-combo models (provider === COMBO_NAMESPACE). As a result, after ocx sync the entry alibaba-token-plan-intl/qwen3.8-max emits supported_reasoning_levels = [low, medium, xhigh, max, ultra] even when modelReasoningEfforts is configured as ["low", "medium", "xhigh"].

What should OpenCodex do?

Add a per-model (or per-provider) config option to suppress the synthetic top rungs so the catalog advertises exactly the provider/registry's supported levels: qwen3.8-max -> [low, medium, xhigh]. Wire clamping via clampToSupportedCodexEffort already keeps requests correct, so this should only affect what the picker shows. Ideally the flag keeps max available for subagent spawn_agent (so that path doesn't hard-fail) while hiding ultra, or gates the mock entirely behind user choice.

Example usage or interface

With a provider configured as:

{
  "providers": {
    "alibaba-token-plan-intl": {
      "adapter": "openai-chat",
      "baseUrl": "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1",
      "apiKey": "${BAILIAN_TOKEN_PLAN_API_KEY}",
      "modelReasoningEfforts": { "qwen3.8-max": ["low", "medium", "xhigh"] }
    }
  }
}

After ocx sync, the catalog entry for alibaba-token-plan-intl/qwen3.8-max should advertise supported_reasoning_levels = [low, medium, xhigh] (no synthetic max/ultra).

Alternatives or workarounds

Today the only workarounds are to define the models as exact combos (whch changes their slug to combo/...) or to use noReasoningModels (which removes the effort control entirely). Neither preserves the model identity while trimming only the unsupported top rungs.

Additional context

Suggested implementation: add e.g. preserveExactReasoningRungs?: boolean on the provider, or reuse modelReasoningEfforts as the authoritative advertised ladder. This request is for per-model control over the advertised effort ladder.

🔗 Related PRs

#763 - fix(catalog): prioritize model names in picker labels [merged]
#853 - feat(server): advertise reasoning-effort ladders on the raw /v1/models list [merged]
#1300 - fix(catalog): preserve nested reasoning efforts [open]
#1669 - feat(catalog): add modelPickerOrder to customize the Codex model-picker order [open]
#1716 - feat(models): per-custom-model reasoning effort in the Models dashboard [merged]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

The report is accurate: current applyReasoningLevels deliberately adds synthetic max and ultra to routed reasoning models unless the row is in the exact-combo path.

One product constraint needs to be resolved before implementation: Codex uses the same supported_reasoning_levels field for both the visible picker and spawn_agent effort validation. There is no separate hidden "spawn-only max" rung in the current catalog schema. Therefore an exact advertised ladder of [low, medium, xhigh] also means a direct spawn_agent(reasoning_effort: "max") can be rejected by the client before OpenCodex gets a chance to clamp it.

A safe option would be an explicit per-model exact-ladder opt-in, with today's synthetic behavior remaining the default. Please confirm that the intended tradeoff is: exact picker truth is preferred even when omitted top-tier sub-agent overrides become invalid for that model. Once confirmed, the config name and tests should make that behavior explicit rather than silently changing existing providers.

I agree that an exact advertised ladder should reflect the model’s actual capabilities. My preference would still be to silently clamp unsupported higher efforts when they reach OpenCodex, since clampToSupportedCodexEffort already provides that fallback.

I understand your point, though, that spawn_agent may reject max client-side if max is absent from supported_reasoning_levels, before OpenCodex can perform the clamp.

Is there any current mechanism to keep max accepted for spawn_agent validation while exposing only [low, medium, xhigh] in the picker? If not, then I’m fine with the exact-ladder opt-in and accept that explicit spawn_agent(..., reasoning_effort: "max") overrides would become invalid for that model.

There is no current catalog mechanism that keeps a hidden max rung valid only for spawn_agent while omitting it from the visible picker; both surfaces consume the same supported_reasoning_levels row.

Your confirmation resolves the product tradeoff. The conservative implementation contract is:

keep today's synthetic max/ultra behavior as the default;
add an explicit per-model exact-ladder opt-in on the provider;
for opted-in models, advertise the sanitized configured modelReasoningEfforts[model] ladder without synthetic top rungs;
retain runtime clamping for requests that do reach OpenCodex, while documenting that the Codex client can reject an omitted explicit sub-agent effort before routing;
regression-test ordinary models, opted-in exact models, catalog sync, and direct spawn_agent validation implications.

I am removing needs-info and marking this as an implementation-ready help-wanted enhancement. Please keep any PR narrowly scoped to the catalog/config contract and target dev.

feat(catalog): per-model preserveExactReasoningRungs to stop syntheti…

fix(catalog): clear stale preserveExactReasoningRungs flag on re-hint

feat(catalog): per-model preserveExactReasoningRungs to stop syntheti…

fix(catalog): clear stale preserveExactReasoningRungs flag on re-hint

리뷰 · 우선순위 28 / 80

Qwen 등 라우티드 모델 피커에 실제 없는 max/ultra 가 붙는다. modelReasoningEfforts 를 low/medium/xhigh 로 줘도 sync 후 supported_reasoning_levels 에 max와 ultra가 더해진다. 카탈로그 UX라 28이다. 와이어는 이미 클램프한다.

src/codex/catalog/effort.ts 의 applyReasoningLevels 가 preserveExact 가 아니면 max와 ultra를 붙인다. 주석은 spawn_agent 가 max 를 카탈로그 멤버십으로 검사해서다. preserveExact 는 콤보 네임스페이스에만 켜진다.

클램프는 clampToSupportedCodexEffort 가 요청을 실제 사다리로 접는다. 피커만 거짓이고 와이어는 정직하다. noReasoningModels 는 컨트롤을 통째로 없애고, 콤보로 바꾸면 슬러그가 combo/ 로 바뀐다. 둘 다 원하는 답이 아니다.

max 를 숨기면 spawn_agent effort 오버라이드가 카탈로그에서 거절될 수 있다. 이슈도 그 긴장을 말한다. ultra만 숨기거나, 피커와 spawn 허용 목록을 나누는 선택이 있다.

해결방안

프로바이더/모델 플래그로 applyReasoningLevels 의 합성 윗칸을 끈다. 기본은 지금처럼 max/ultra 추가. 플래그가 켜지면 modelReasoningEfforts 그대로 광고한다. spawn_agent 를 살리려면 max 만 남기고 ultra 만 빼는 옵션이 더 안전하다. 플래그 키 이름은 추측하지 않는다. 클램프 함수는 그대로 둔다.

이 댓글은 grok-bot이 작성했습니다

리뷰 · 우선순위 60 / 80

점수 정정임. 합성 max/ultra를 피커에서 빼자는 이슈인데, ultra는 빼면 안 됨. Codex 하네스가 ultra를 쓰는 길이어서, 울트라 쓰려면 카탈로그에 남아 있어야 함. 그 하네스는 이쪽에서 더 개선할 예정임.

src/codex/catalog/effort.ts applyReasoningLevels가 reasoning 모델에 max/ultra를 붙이는 건 맞음. preserveExact는 combo만. Qwen처럼 modelReasoningEfforts를 줘도 피커에 max/ultra가 보임. 요청 클램프는 clampToSupportedCodexEffort가 이미 함.

메인터 방향: max를 숨기는 방안을 검토함. ultra는 유지. 모델이 max를 실제로 지원 안 하면 피커에서 max만 빼는 쪽. ultra를 통째로 끄거나 Qwen을 combo로 바꾸는 우회는 안 함.

해결방안: 광고 레더에서 synthetic max만 옵션으로 숨기고, ultra는 하네스용으로 남길 것. 요청 클램프는 그대로. 지금 패치는 안 넣음.

이 댓글은 grok-bot이 작성했습니다

Navigation Menu

Repository navigation

Feature request: per-model option to stop advertising synthetic `max`/`ultra` reasoning rungs on models that don't support them #1870

What are you trying to accomplish?

What prevents this today?

What should OpenCodex do?

Example usage or interface

Alternatives or workarounds

Additional context

Issue reopened

리뷰 · 우선순위 28 / 80

해결방안

리뷰 · 우선순위 60 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Feature request: per-model option to stop advertising synthetic max/ultra reasoning rungs on models that don't support them #1870

Description

What are you trying to accomplish?

What prevents this today?

What should OpenCodex do?

Example usage or interface

Alternatives or workarounds

Additional context

Activity

coderabbitai commented on Aug 16, 2026

github-actions commented on Aug 16, 2026

Issue reopened

Ingwannu commented on Aug 16, 2026

marcellmanfrin commented on Aug 17, 2026

Ingwannu commented on Aug 17, 2026

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 28 / 80

해결방안

lidge-jun commented on Aug 19, 2026

리뷰 · 우선순위 60 / 80

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Feature request: per-model option to stop advertising synthetic `max`/`ultra` reasoning rungs on models that don't support them #1870