Repository navigation
Feature: suppress synthetic max per model while retaining ultra #2279
Description
Activity
- addedenhancementNew feature or requestNew feature or requestcatalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entries
on Aug 21, 2026 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.
리뷰 · 우선순위 51 / 80
지금
devHEADe3b2136b2가 이슈가 찍은 그대로임.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. 카탈로그 래더 광고임. 사이드카 실행기 아님. #2190x_search넣지 말 것. Grok OAuth Chat 기본(#2255)이랑 GUI 옵트인 Responses(#2266)랑 다른 레인임.types.ts/config.ts스플릿은 진행 중인데 이 이슈 자체는 스키마 PR이 아님. 프리뷰 배포 아님. v2.28.0 이미 태그됨. 핫 크래시 아님. 픽커가 가짜max를 보여서 오퍼레이터가 패치로 버티는 구멍임. 그래서 51.트레이드오프도 코드에 이미 박혀 있음. Codex는 픽커 멤버십이랑
spawn_agenteffort 검증을 같은 래더로 봄.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이 작성했습니다
Shipped on
devby #5036, squashed as5df06bd0962144cc7bfc71f94b8fb1da86f8975b.Synthetic
maxcan now be suppressed per model whileultrais 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
maxkeeps it, and a model wheremaxonly 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
maxrung 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.
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
ultraharness rung.This is the narrowed follow-up to #1870's final maintainer direction: suppress only an OpenCodex-invented missing
maxon selected models. A provider-declaredmaxmust remain visible, andultramust remain available for Codex orchestration.What prevents this today?
applyReasoningLevelsadds a missing syntheticmaxandultrato ordinary reasoning-capable routed rows. Even when a model-specific ladder stops athigh, the final catalog can therefore advertisemax.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:
trueprevents synthesis of a missingmaxfor that upstream model ID;maxis never removed;ultrarung remains;falsekeeps today's synthesis;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_agenteffort validation. Ifmaxis absent, an explicitspawn_agent(..., effort: "max")can fail client-side before proxy clamping runs. Retainingultrapreserves 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 containsmaxkeeps it and gainsultraas before.Alternatives or workarounds
modelReasoningEffortslist exact: silently changes existing providers and conflicts with the opt-in direction in Feature request: per-model option to stop advertising syntheticmax/ultrareasoning rungs on models that don't support them #1870.ultra, contrary to the final owner direction.Additional context
max/ultrareasoning rungs on models that don't support them #1870 established the catalog/spawn-validation tradeoff. Its final owner direction was to consider hiding only syntheticmaxwhile retainingultra.maxandultraand was far behinddev.max.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