[Feature/UX]: streamline context-window presets/import for /models responses without metadata #1760

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

• Hand-edit config.json under providers.<id>.modelContextWindows; this works but is easy to miss and awkward for several models or repeated provider setup.
• Use the context-window fields added by Models GUI cannot define a fallback context window for metadata-poor third-party providers #1073/fix(models): context window controls for metadata-poor providers (#1073) #1223 one model at a time; this is a valid workaround, but does not surface missing metadata or provide bulk import/reuse.
• Add a canonical registry entry; this would be inappropriate for a generic relay unless OpenCodex has primary evidence for the upstream capacity.

Additional context

• Observed with OpenCodex 2.19.0 and a local BLT OpenAI-compatible provider whose /v1/models response omitted context metadata.
• The manual values above are an operator configuration example, not a claim about BLT or any upstream model contract.
• Related work: Models GUI cannot define a fallback context window for metadata-poor third-party providers #1073, fix(models): context window controls for metadata-poor providers (#1073) #1223, and the earlier #485 discussion. This request is intentionally limited to setup/discoverability/import/preset UX; it does not ask to reimplement the existing manual override mechanism or to guess upstream capabilities.
• No credentials, API keys, or other personal data are included.

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.