Routed metadata augmentation never backfills a context window onto a live row (latent; ruled out as the cause of #4944) #4971

Client or integration

Codex CLI

Area

Catalog / models

Summary

augmentRoutedModelsWithMetadata appends generated-registry rows that the live provider list did
not return, and skips every id the live list did return:

// src/codex/catalog/routed-gather.ts:860-870
  const out = [...models];
  const seen = new Set(out.map(m => `${m.provider}/${m.id}`));
  for (const provider of providerNames) {
    if (!JAWCODE_CATALOG_AUGMENT_PROVIDERS.has(provider)) continue;
    if (providers?.[provider]?.liveModels === false) continue;
    const jawcodeProvider = resolveMetadataProvider(provider);
    if (!jawcodeProvider) continue;
    for (const meta of listModelMetadata(jawcodeProvider)) {
      const key = `${provider}/${meta.id}`;
      if (seen.has(key) ) continue;
      seen.add(key);

So a live row that arrives with no contextWindow keeps none, even when the registry holds a
published window for exactly that provider and id. The skip is append-only by construction: it
has no merge branch at all.

This is not the cause of #4944, and it should not be re-investigated as one. I ruled it out
while working that issue. The serialized catalog entry does not get its window from the
CatalogModel — applyCatalogMetadata (src/codex/catalog/parsing.ts:828-836) writes
context_window, max_context_window and auto_compact_token_limit onto the entry directly
from the generated table, keyed by provider and id, on both derive paths
(src/codex/catalog/derive-entry.ts:171 and :217). A row the registry knows therefore gets its
correct window regardless of this skip, and a row the registry does not know has nothing to merge.
Repairing the skip would have changed no catalog row in that report.

What it does affect is every consumer that reads CatalogModel.contextWindow instead of the
serialized entry. Combo member derivation carries its own 128k fallback at
src/codex/catalog/combo-member.ts:131, and routing capability resolution reads the config maps
at src/routing/capability.ts:174. Those paths see the un-backfilled value.

Filing it separately because "real defect, wrong suspect" is exactly the finding that disappears
when the issue it was found under gets closed.

Reproduction

Static, from source at dev a0f611d4aceb9476d44268e43722273b7b211846:

1. Pick a provider in JAWCODE_CATALOG_AUGMENT_PROVIDERS (src/codex/catalog/parsing.ts:178 —
   opencode-go and deepseek) and an id the generated registry publishes a contextWindow for.
2. Have the live /v1/models response return that id with no context field, which is the normal
   case for OpenCode Go.
3. augmentRoutedModelsWithMetadata reaches if (seen.has(key)) continue; and the CatalogModel
   keeps contextWindow: undefined.
4. Any consumer reading CatalogModel.contextWindow rather than the serialized entry sees the
   fallback instead of the published window.

Version

dev at a0f611d4aceb9476d44268e43722273b7b211846.

Operating system

Platform-independent.

Provider and model

Any provider in JAWCODE_CATALOG_AUGMENT_PROVIDERS; opencode-go is where it is easiest to see.

Logs or error output

No error is produced. The value is silently absent.

Screenshots and supporting files

None. Backend-only.

Redacted configuration

Not configuration-dependent beyond the provider being live-discovered with liveModels enabled.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.