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
What are you trying to accomplish?
Configure a correct context window for a routed model from a third-party provider whose
/modelsendpoint exposes only model IDs and no context-window metadata.For example, provider
sub2apiroutes modelgpt-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.
providerContextCapsis 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:
providers.<provider>.contextWindowproviders.<provider>.modelContextWindows.<model>providerContextCaps.<provider>as a ceiling only.The UI should clearly distinguish the meanings:
Expected result for this example:
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:
With no explicit provider or model window, OpenCodeX should continue to use the safe 128K fallback.
Area
Catalog / Models