[Bug]: Routed models inherit native template context_window when /models omits context metadata

[ardeyouxipianyi]

Summary

Routed models can inherit the first native Codex catalog entry's context_window when the upstream provider /models response contains only model IDs and no context-window metadata.

This makes a relay model appear as 372000 even though 372000 belongs to the native GPT-5.6 template, not to the relay provider.

Reproduction

Configure an OpenAI-compatible openai-responses provider whose /models response returns rows like:

{"data":[{"id":"<model-id>"}]}

with no context_length, context_size, max_model_len, max_context_length, or nested metadata limits.

Set:

"providerContextCaps": {
  "<provider-name>": 950000
}

After catalog sync, the generated catalog contains:

{
  "slug": "<provider-name>/<model-id>",
  "context_window": 372000,
  "max_context_window": 372000,
  "auto_compact_token_limit": 334800
}

The same behavior occurs for other relay providers that do not return context metadata.

Observed code path

• findNativeTemplate() selects the first bare native entry with base_instructions.
• deriveEntry() deep-clones that template for routed provider/model entries.
• applyProviderConfigHints() applies providerContextCaps only when the CatalogModel already has a valid contextWindow; an unknown window remains undefined.
• applyCatalogModelMetadata() only overwrites the cloned context_window when model.contextWindow exists.
• The cloned native context_window therefore survives into the routed catalog entry.

Relevant files:

• src/codex/catalog/provider-fetch.ts
• src/codex/catalog/sync.ts
• src/codex/catalog/parsing.ts

Related issue: #485 discusses missing relay-provider model capability metadata, but this report focuses on the native-template metadata leakage and the resulting incorrect 372000 value.

Expected behavior

A routed entry should not inherit model-specific context metadata from the native template. When upstream metadata is missing, the implementation should use an explicit provider/model fallback if configured, or a clearly documented conservative default. providerContextCaps should either be applied as the documented fallback for unknown windows or the UI should clearly state that it only caps already-known windows.

Local verification

A local patch that clears context_window, max_context_window, and auto_compact_token_limit from routed template clones, and uses the enabled provider cap as the fallback when discovery has no context metadata, passes the catalog regression tests and TypeScript check.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[lidge-jun]

Fixed on dev in #1028 (merged as 02dbcff9c).

A routed model no longer inherits the native template's context window. All three inherited context fields are cleared before Jawcode, config, and live metadata are applied, so an unknown window stays unknown instead of borrowing a number that describes a different model. Known metadata is still restored exactly.

Not in a release yet. This is on dev, and main is at v2.10.0. It ships in the next release.