Skip to content

Feature: suppress synthetic max per model while retaining ultra #2279

Description

@cristph

Area

Catalog / models

What are you trying to accomplish?

Allow an operator to keep a routed model's provider-native reasoning ladder accurate in the Codex model picker while retaining Codex's ultra harness rung.

This is the narrowed follow-up to #1870's final maintainer direction: suppress only an OpenCodex-invented missing max on selected models. A provider-declared max must remain visible, and ultra must remain available for Codex orchestration.

What prevents this today?

applyReasoningLevels adds a missing synthetic max and ultra to ordinary reasoning-capable routed rows. Even when a model-specific ladder stops at high, the final catalog can therefore advertise max.

The later observed-state merge also repairs a missing max, so changing only intermediate catalog construction is insufficient: a second sync or degraded-discovery preservation can add it back. The current workaround is a local source patch that OpenCodex upgrades overwrite.

What should OpenCodex do?

Add an explicit per-model provider setting with backward-compatible behavior:

  • true prevents synthesis of a missing max for that upstream model ID;
  • a provider-declared max is never removed;
  • Codex's ultra rung remains;
  • missing or false keeps today's synthesis;
  • the policy applies to discovered, cached, custom-only, second-sync, and degraded-discovery catalog paths;
  • model rename migration and Dashboard provider overwrites preserve the setting.

The setting should affect catalog construction only. Existing request mapping, clamping, adapters, routing, and authentication behavior remain unchanged.

The known catalog tradeoff should be documented: Codex uses the same reasoning-level membership for the picker and explicit spawn_agent effort validation. If max is absent, an explicit spawn_agent(..., effort: "max") can fail client-side before proxy clamping runs. Retaining ultra preserves the supported harness path.

Example usage or interface

{
  "providers": {
    "example-provider": {
      "modelReasoningEfforts": {
        "example-model": ["low", "medium", "high"]
      },
      "modelSuppressSyntheticMax": {
        "example-model": true
      }
    }
  }
}

Expected catalog ladder: [low, medium, high, ultra].

An unflagged model with the same configured provider ladder remains [low, medium, high, max, ultra]. A flagged model whose configured provider ladder already contains max keeps it and gains ultra as before.

Alternatives or workarounds

Additional context

The proposed implementation is intentionally limited to one model-keyed boolean, transient catalog propagation, final-merge enforcement, validation/migration safety, focused regression tests, and public configuration documentation. Provider metadata corrections and GUI work are out of scope.

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. added
    enhancementNew feature or request
    catalogModel catalog, slugs, visibility, routed entries
    on Aug 21, 2026
  2. Ingwannu commented on Aug 21, 2026

    @Ingwannu
    Owner

    Confirmed: this is a valid narrow catalog enhancement, and the request correctly preserves the important distinction between an OpenCodex-invented max and a provider-declared real max.\n\nThe linked #2280 is not complete yet. Its current final merge can prevent a new synthetic max from being added, but it cannot remove a synthetic max already preserved from an earlier sync during degraded discovery. Removing every existing max would be unsafe because it would also erase a real provider-declared rung. I left an exact-head change request requiring provenance and regressions for both cases.\n\nKeeping this issue open as the contract. It should close only when fresh, cached, second-sync, and degraded-preservation paths all suppress only synthetic max, preserve real max, retain ultra, and exact-head CI is green.

  3. lidge-jun commented on Aug 21, 2026

    @lidge-jun
    Owner

    리뷰 · 우선순위 51 / 80

    지금 dev HEAD e3b2136b2가 이슈가 찍은 그대로임. applyReasoningLevels (src/codex/catalog/effort.ts:204-244)가 reasoning-capable 라우티드 줄에 합성 max랑 ultra를 같이 넣음. preserveExact일 때만 안 넣음. 그 플래그는 콤보 exact랑 codexForwardNativeCapabilityAlias뿐임 (src/codex/catalog/sync.ts:334-339, 폴백 :388). 프로바이더 사다리가 high에서 끝나도 픽커가 max를 광고함. 로컬 소스 패치로 막는 거 말고는 계약이 없음. ㅋㅋ 업그레이드하면 다시 붙음.

    관측 머지도 한 번 더 고침. mergeCatalogEntriesFromObservedState (sync.ts:1096-1108)가 exact 콤보가 아니면 디스크에 남은 라우티드 줄에 빠진 max를 끼워 넣음. 중간 카탈로그만 손보면 둘째 싱크나 degraded discovery가 되돌림. 이슈 본문 맞음. 덤으로 ensureUltraReasoningLevel (effort.ts:264-278) 이름만 ultra임. wanted = ["max", "ultra"]라 네이티브 보존 줄에도 max를 발명함 (sync.ts:244, :353, :948). 라우티드 플래그 스코프 밖이긴 한데, "ultra 헬퍼"가 max를 안 만든다는 착각은 하지 말 것.

    #2280이 짝임. 같은 피처의 구현 PR임. 랜덤 중복으로 닫지 말 것. #2280이 착지해야 이 이슈가 닫힘. 그 전엔 계약으로 열어 둬라. Ingwannu도 그렇게 박음. #1882/#2124는 프로바이더 와이드/exact-ladder라 ultra까지 지움. #1870 최종 방향이 아님. 그 초안 다시 열어서 덮지 말 것.

    #2188 L1–L9 사이드카는 이미 dev. 카탈로그 래더 광고임. 사이드카 실행기 아님. #2190 x_search 넣지 말 것. Grok OAuth Chat 기본(#2255)이랑 GUI 옵트인 Responses(#2266)랑 다른 레인임. types.ts/config.ts 스플릿은 진행 중인데 이 이슈 자체는 스키마 PR이 아님. 프리뷰 배포 아님. v2.28.0 이미 태그됨. 핫 크래시 아님. 픽커가 가짜 max를 보여서 오퍼레이터가 패치로 버티는 구멍임. 그래서 51.

    트레이드오프도 코드에 이미 박혀 있음. Codex는 픽커 멤버십이랑 spawn_agent effort 검증을 같은 래더로 봄. max를 빼면 명시 spawn_agent(..., effort: "max")가 프록시 클램프 전에 클라에서 죽음. ultra를 남기는 게 하니스 경로임. effort.ts:211-216 주석이 그거임.

    해결방안: 계약은 이 이슈가 소유자임. 구현은 #2280. 모델 키 boolean 하나. 합성 max만 숨기고 프로바이더가 선언한 max는 남기고 ultra는 유지. discovered / cached / custom-only / second-sync / degraded-preservation 전부. 요청 매핑·어댑터·라우팅은 손대지 말 것. #1882/#2124 다시 열지 말 것. #2280이 프로비넌스 구멍 메우고 머지되면 이 이슈가 닫힘. 스플릿이 카탈로그 effort 헬퍼를 다시 옮기면 리베이스하지 말고 닫고 다시 짜라. 지금은 그 정도 아님.

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

  4. lidge-jun commented on Sep 18, 2026

    @lidge-jun
    Owner

    Shipped on dev by #5036, squashed as 5df06bd0962144cc7bfc71f94b8fb1da86f8975b.

    Synthetic max can now be suppressed per model while ultra is retained.

    The scope is deliberately narrower than it might look, and the narrowing is what made this safe to ship. The flag governs synthesis and repair only, never removal: it decides whether a synthetic rung is produced, not whether an existing published one is taken away. That avoids inventing a persisted max-provenance marker, which would have meant a roughly twelve-file catalog change to track where every rung came from — and a marker that has to be right in every future write path is a liability rather than a feature.

    So a model whose vendor genuinely publishes max keeps it, and a model where max only ever existed because we synthesised it can now be configured not to have one.

    Worth noting the sibling decision for context: the repository already records that some vendors publish no max rung at all, and the native effort clamp pins a five-rung contract for those. This setting is for the cases that clamp does not cover, not a second mechanism competing with it.

    Shipping in the next release off dev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    catalogModel catalog, slugs, visibility, routed entriesenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions