Area
Catalog / models
What are you trying to accomplish?
I want a quick, reviewable way to supply known context-window values for an OpenAI-compatible relay whose /v1/models response contains model IDs but no context-window metadata. The goal is to populate the existing modelContextWindows fallback without hand-editing JSON for each provider/model, so Codex shows the operator's documented or tested capacity instead of the conservative default.
What prevents this today?
#1073 and the merged PR #1223 already expose and persist contextWindow and modelContextWindows; that solves the underlying configuration mechanism. The remaining problem is discoverability and bulk entry. When live discovery omits context metadata, a newly added relay is shown with the conservative 128K catalog value (about 122K visible in Codex). The operator must know which field to edit and manually update config or open models one by one. There is no clear "metadata not reported" state, reusable preset, or paste/import path.
providerContextCaps is not a substitute: it is a ceiling, while this request is about a user-supplied fallback when the upstream value is unknown.
What should OpenCodex do?
Keep the current contextWindow/modelContextWindows semantics and let the operator choose the value. When /v1/models has no recognized context metadata for one or more rows, provide a non-guessing convenience workflow, for example:
- show an explicit "context window not reported by provider" status and a quick-fill action in the dashboard (and a comparable CLI/config path);
- accept a validated JSON map or config fragment for
modelContextWindows, matched against discovered model IDs, with a preview before saving;
- allow saving and reusing a local/provider-scoped preset for newly discovered IDs;
- label the source of the effective value as upstream-reported, user-supplied fallback, or conservative default.
A minimum useful version could be a banner listing the affected model IDs with a paste/import action. Unknown IDs should be shown for review rather than silently dropped. Explicit user values must survive refreshes and remain easy to clear.
OpenCodex should not infer a capacity from a model name or claim what the upstream service supports. Presets should be operator-provided and clearly marked as such.
Example usage or interface
A relay returns only IDs:
{
"data": [
{ "id": "gpt-5.6-sol" },
{ "id": "gpt-5.6-terra" }
]
}The dashboard could show:
Context window metadata was not reported for 2 discovered models.
Import a provider preset or enter a fallback map. Values are user-supplied and are not verified against the upstream service.
Pasting the following map would preview and then write the existing configuration field:
{
"providers": {
"BLT": {
"modelContextWindows": {
"gpt-5.6-sol": 350000,
"gpt-5.6-terra": 350000
}
}
}
}The same flow could accept just the map:
{
"gpt-5.6-sol": 350000,
"gpt-5.6-terra": 350000
}The effective catalog would then use those user-supplied fallbacks while preserving the current behavior for models that report authoritative metadata.
Alternatives or workarounds
Additional context
Checks
Area
Catalog / models
What are you trying to accomplish?
I want a quick, reviewable way to supply known context-window values for an OpenAI-compatible relay whose
/v1/modelsresponse contains model IDs but no context-window metadata. The goal is to populate the existingmodelContextWindowsfallback without hand-editing JSON for each provider/model, so Codex shows the operator's documented or tested capacity instead of the conservative default.What prevents this today?
#1073 and the merged PR #1223 already expose and persist
contextWindowandmodelContextWindows; that solves the underlying configuration mechanism. The remaining problem is discoverability and bulk entry. When live discovery omits context metadata, a newly added relay is shown with the conservative 128K catalog value (about 122K visible in Codex). The operator must know which field to edit and manually update config or open models one by one. There is no clear "metadata not reported" state, reusable preset, or paste/import path.providerContextCapsis not a substitute: it is a ceiling, while this request is about a user-supplied fallback when the upstream value is unknown.What should OpenCodex do?
Keep the current
contextWindow/modelContextWindowssemantics and let the operator choose the value. When/v1/modelshas no recognized context metadata for one or more rows, provide a non-guessing convenience workflow, for example:modelContextWindows, matched against discovered model IDs, with a preview before saving;A minimum useful version could be a banner listing the affected model IDs with a paste/import action. Unknown IDs should be shown for review rather than silently dropped. Explicit user values must survive refreshes and remain easy to clear.
OpenCodex should not infer a capacity from a model name or claim what the upstream service supports. Presets should be operator-provided and clearly marked as such.
Example usage or interface
A relay returns only IDs:
{ "data": [ { "id": "gpt-5.6-sol" }, { "id": "gpt-5.6-terra" } ] }The dashboard could show:
Pasting the following map would preview and then write the existing configuration field:
{ "providers": { "BLT": { "modelContextWindows": { "gpt-5.6-sol": 350000, "gpt-5.6-terra": 350000 } } } }The same flow could accept just the map:
{ "gpt-5.6-sol": 350000, "gpt-5.6-terra": 350000 }The effective catalog would then use those user-supplied fallbacks while preserving the current behavior for models that report authoritative metadata.
Alternatives or workarounds
config.jsonunderproviders.<id>.modelContextWindows; this works but is easy to miss and awkward for several models or repeated provider setup.Additional context
/v1/modelsresponse omitted context metadata.Checks