Models GUI cannot define a fallback context window for metadata-poor third-party providers #1073

What are you trying to accomplish?

Configure a correct context window for a routed model from a third-party provider whose /models endpoint exposes only model IDs and no context-window metadata.

For example, provider sub2api routes model gpt-5.6-luna. Its upstream response can be as minimal as:

{
  "data": [
    { "id": "gpt-5.6-luna" }
  ]
}

The user knows this route supports a 350K context window and needs the generated routed catalog entry to reflect that capacity.

What prevents this today?

In v2.10.1, the native-template inheritance fixed by #992 is correctly removed. However, when upstream model metadata is absent, the routed catalog uses the conservative fallback:

{
  "context_window": 128000,
  "max_context_window": 128000,
  "auto_compact_token_limit": 115200
}

Setting the provider limit in the Models GUI, which writes:

{
  "providerContextCaps": {
    "sub2api": 350000
  }
}

does not change this result. providerContextCaps is a ceiling: it can clamp discovered capacity but cannot provide a context window when the provider returns none. Therefore the actual usable context remains 128K.

OpenCodeX already supports the required configuration fields in providers.<provider>:

{
  "providers": {
    "sub2api": {
      "contextWindow": 350000,
      "modelContextWindows": {
        "gpt-5.6-luna": 350000
      }
    }
  }
}

However, there is no corresponding Models GUI control, so users can set a 350K cap in the UI but still receive the 128K fallback for metadata-poor providers.

What should OpenCodex do?

Add GUI controls that write the existing configuration fields:

• Provider default context window → providers.<provider>.contextWindow
• Per-model context window → providers.<provider>.modelContextWindows.<model>
• Keep Maximum context cap → providerContextCaps.<provider> as a ceiling only.

The UI should clearly distinguish the meanings:

• Context window: explicit capacity to use when upstream metadata is absent.
• Context cap: maximum allowed capacity; it must not increase discovered capacity by itself.

Expected result for this example:

sub2api/gpt-5.6-luna
upstream context metadata: absent
modelContextWindows.gpt-5.6-luna: 350000
providerContextCaps.sub2api: 350000

effective context window: 350000
auto_compact_token_limit: 315000

This preserves the conservative 128K default for unknown providers while giving users a supported GUI path to configure providers that intentionally omit context metadata.

Example usage or interface

On the Models page, after selecting a provider or routed model:

Provider: sub2api
Default context window: [350K]
Maximum context cap:   [350K]

Model: gpt-5.6-luna
Context window override: [350K]

With no explicit provider or model window, OpenCodeX should continue to use the safe 128K fallback.

Area

Catalog / Models