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
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