fix(model_metadata): add gpt-5.x context lengths + guard against poisoned cache

[Prithvi1994]

Fixes #5173 — gpt-5.4 shows 32k context in Hermes instead of 1,050,000

Root Cause

Two independent bugs conspire to produce the wrong context window:

1. Missing DEFAULT_CONTEXT_LENGTHS entries — gpt-5.4 (and other gpt-5.x variants) were absent from the fallback dict. Lookups fell through to the generic "gpt-5": 128000 catch-all, returning 128k instead of 1,050,000.

2. Cache poisoning — When connecting via the Codex endpoint, Hermes probes the API and may receive max_output_tokens (32k) where it expects context_length. That value gets written to context_length_cache.yaml. Since the persistent cache is checked first in the resolution order, the bad 32k value overrides everything permanently.

Fix (two-part)

1. Add specific gpt-5.x entries to DEFAULT_CONTEXT_LENGTHS

New entries added before the generic "gpt-5": 128000 catch-all in agent/model_metadata.py:

Model	Context Length
gpt-5.4	1,050,000
gpt-5.4-mini	1,050,000
gpt-5.4-pro	1,050,000
gpt-5.4-nano	1,050,000
gpt-5.3-codex	1,048,576
gpt-5.2-codex	1,048,576
gpt-5.1-codex-max	1,048,576
gpt-5.1-codex-mini	1,048,576

The existing sorted() in get_model_context_length ensures longest-key-first matching, so specific variants correctly shadow the catch-all.

2. Sanity guard in save_context_length()

Added a pre-write check: if the model name contains "gpt-5" and the value being cached is <= 128,000, the write is rejected and a warning is logged. This stops max_output_tokens (32k) from ever being written into context_length_cache.yaml for gpt-5 family models.

The guard does not affect non-gpt-5 models — e.g. llama-3 can still be cached at 32k normally.

Users who need to force a specific value can always set model.context_length in config.yaml, which is checked before the cache.

Tests

Added TestGpt5ContextLengths in tests/agent/test_model_metadata.py:

• gpt-5.4 -> 1,050,000 via DEFAULT_CONTEXT_LENGTHS
• gpt-5.4-mini -> 1,050,000 via DEFAULT_CONTEXT_LENGTHS
• save_context_length("gpt-5.4", ..., 32000) -> silently rejected
• save_context_length("gpt-5.4", ..., 1_050_000) -> cached successfully
• Sanity guard does NOT block llama-3 at 32k

All 80 tests pass.

[teknium1]

Thanks for isolating the context-cache concern. Current main already separates direct fallback values from Codex OAuth limits, so this needs a narrower salvage.

Problems

• The proposed all-gpt-5 <= 128K write rejection would suppress the valid gpt-5.3-codex-spark 128K window (agent/model_metadata.py:242-248, 1838-1843).
• The proposed guard only blocks new writes; it does not recover an already-stored 32K row. Cache-first resolution still returns eligible cached values before provider lookup (agent/model_metadata.py:2110-2178).
• Codex OAuth has a provider-specific resolver (agent/model_metadata.py:2309-2317) and its verified fallback is 272K for gpt-5.4 and the listed Codex variants (agent/model_metadata.py:1834-1852), not the direct-API values proposed here.

Suggested changes

• Re-scope to a Codex-specific stale-cache invalidation only if a current 32K persisted-cache repro remains.
• Preserve legitimate 128K variants and test a seeded stale cache entry through the current resolver.

Automated hermes-sweeper review.

[teknium1]

Closing as superseded. Both halves of this PR are now covered on main:

• Catalog entries: the full gpt-5.x family is in DEFAULT_CONTEXT_LENGTHS with values verified against current provider data — gpt-5.4 1.05M, but gpt-5.4-mini/-nano at 400K (not 1.05M), and the codex variants resolving through the Codex-OAuth-specific 272K fallback (_CODEX_OAUTH_CONTEXT_FALLBACK) rather than direct-API values, so a straight salvage of this PR's numbers would now be a regression.
• Poisoned-cache guard: the write-time rejection here would also block the legitimate 128K gpt-5.3-codex-spark entry. The poison classes it targeted are handled by narrower guards that landed since: non-positive values are refused at write and dropped at read (fix(agent): guard against non-positive context_length poisoning the cache #85507), pre-catalog stale entries are invalidated by a generic catalog-aware guard (fix(xai): drop stale 256K grok-4.6 context cache + generalize pre-catalog guard #85434), and Codex OAuth has its own provider-specific resolver.

You were early on this class — the 128K-catch-all fallthrough and the cache-poisoning concern were both real when you filed this, and the guards that eventually landed follow the same instinct. Thanks for the contribution.