feat(model): Codex GPT context defaults back to 272K; -900k picker variants opt into the verified large window

[teknium1]

Summary

Codex GPT slugs default back to the advertised 272K window; the verified 900K window is now an explicit opt-in via new -900k picker variants (e.g. gpt-5.6-sol-900k).

Root cause of the change: the Aug 16 auto-raise to 900K made every gpt-5.4/5.6 Codex OAuth session use the large window silently — more input tokens per request, so subscription usage burned through in hours for users who never asked for it (community report from Andy on Discord).

Changes

• agent/model_metadata.py: _verified_codex_ctx_for_slug now fires only for -900k-suffixed slugs; new public helpers strip_codex_context_variant_suffix, is_codex_context_variant, has_codex_context_variant; the Codex resolver strips the suffix for catalog lookups.
• hermes_cli/codex_models.py: _add_context_variants synthesizes <slug>-900k entries directly after each live-verified base slug (live API, cache, and curated fallback paths); no variant for slugs that genuinely enforce 272K (gpt-5.5, gpt-5.4-mini).
• hermes_cli/models.py: curated openai-codex picker list includes the variants.
• agent/transports/codex.py + agent/auxiliary_client.py: the -900k suffix is stripped before the model id hits the wire (main turns and auxiliary calls).
• agent/usage_pricing.py: -900k variants alias onto the base 5.6 pricing entries.
• Docs: new "Codex large-context -900k picker variants (opt-in)" section in context-compression-and-caching.md.

Validation

	Before	After
gpt-5.6-sol on Codex OAuth (advertised 272K)	resolved 900K	resolves 272K
gpt-5.6-sol-900k	n/a	resolves 900K; wire model gpt-5.6-sol
gpt-5.5 / gpt-5.4-mini	272K, no bump	unchanged; no -900k variant offered
Advertised value ≠ 272K	trusted verbatim	unchanged (variant included)

254 targeted tests pass (test_model_metadata.py, test_codex_models.py, test_codex_transport.py, test_codex_cli_model_picker.py, test_openai_codex_model_validation_fallback.py, test_usage_pricing.py), including new tests for base-slug 272K default, variant 900K resolution (live + fallback paths), picker synthesis/ordering, and wire-strip. E2E-verified via real get_codex_model_ids() + real transport build_kwargs() calls.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 9dd7776 — fix(model): single exact eligibility predicate for -900k var}

⚠️ Warnings

OSV vulnerability scan · View job

7 known vulnerabilities found in pinned dependencies.

• CVE-2026-67213 in package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-71554 in uv.lock
• CVE-2026-70608 in package-lock.json
• CVE-2026-56876 in package-lock.json
• CVE-2026-70606 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 3m8s vs 2m42s (+16.0%). 6 job(s) slower, 5 faster, 2 unchanged.

• OS-specific tests / Windows-only tests: -17.0s
• Docs Site / docs-site-checks: -9.0s
• Python tests / Run tests: +8.0s
• OSV scan / Scan lockfiles / osv-scan: +6.0s
• OS-specific tests / macOS-only tests: +5.0s

[100yenadmin]

@teknium1 posting comments in a few

[100yenadmin]

@teknium1 Verified on pinned head 89e1718: this prefix test is broader than the routable variants. _finalize_codex_models(["gpt-5.6-sol-pro"]) produces gpt-5.6-sol-pro-900k, and finalizing an older gpt-5.4 catalog also synthesizes the Sol/Terra/Luna 900K choices through forward compatibility. There is a related manual-path edge: existing hidden-slug validation accepts gpt-5.5-900k, then context resolution stays at 272K and the new wire helper strips it to gpt-5.5. Please use one exact eligibility predicate for picker synthesis, manual validation, context bump, and suffix stripping; exclude known-dead -pro slugs and reject ineligible -900k aliases.

[100yenadmin]

@teknium1 Suggested minimal follow-up patch (this can stay follow-up-safe for the quota rollback): introduce one is_codex_900k_base(slug) predicate backed by the explicit verified-model table plus only the routable gpt-5.6-{sol,terra,luna} bases and date-shaped snapshots. Then reuse it in all four places: picker synthesis, _verified_codex_ctx_for_slug, manual validation, and stripping. In particular, make stripping conditional: base = raw[:-len(CODEX_CONTEXT_VARIANT_SUFFIX)]; return base only when is_codex_900k_base(base), otherwise return the original alias so it fails honestly. In validate_requested_model, reject an ineligible *-900k before the hidden-slug soft-accept branch. A compact table-driven regression should cover eligible base/snapshot aliases plus rejected gpt-5.6-sol-pro-900k, gpt-5.5-900k, and arbitrary family descendants, and should assert both the advertised context and the final wire model.

[100yenadmin]

@teknium1 Verified on 89e1718: gpt-5.6-sol-900k and openai-codex:gpt-5.6-sol-900k resolve to 900,000, but openai/gpt-5.6-sol-900k resolves to 272,000. After stripping -900k, lookup_bare still carries openai/, so the live exact lookup and verified-family prefix check miss. The standard main-agent path calls normalize_model_for_provider() first and removes this namespace, so this is a safe-failure compatibility gap rather than the normal-path quota regression. Normalizing a recognized vendor/model prefix here would make the resolver consistent for direct/display/auxiliary callers.

[100yenadmin]

@teknium1 Suggested minimal follow-up patch: keep this normalization Codex-local rather than broadening the generic provider-prefix helper, because slash-qualified model IDs are meaningful for other providers. Add a small helper that removes only recognized Codex namespaces (openai/ and openai-codex/; preserve the existing colon handling), then normalize once before both decisions: variant_bare = strip_codex_namespace(model_bare), have _apply_verified_bump call _verified_codex_ctx_for_slug(variant_bare), and set lookup_bare = strip_codex_context_variant_suffix(variant_bare). Normalizing only lookup_bare would still leave the verified-bump check using the unnormalized input. A table-driven regression can assert identical 900K resolution for bare, openai-codex:, and openai/ eligible aliases, while an ineligible namespaced alias remains unstripped/rejected. This is also follow-up-safe rather than a blocker for the core rollback.

[teknium1]

@100yenadmin Thanks — all three findings were real and are addressed in 9dd7776:

1. Exact eligibility predicate: is_codex_900k_base() (explicit table: sol/terra/luna, gpt-5.4, daybreak alias, plus date-shaped 5.6 snapshots) now drives all four sites — picker synthesis, context resolution, /model validation, and wire stripping. Family-prefix matching is gone, so gpt-5.6-sol-pro-900k and arbitrary future descendants are never synthesized or accepted.
2. Namespace gap: the resolver drops vendor/ prefixes, so openai/gpt-5.6-sol-900k now resolves to 900K like the bare and openai-codex:-prefixed forms.
3. Conditional stripping + validation gate: ineligible *-900k aliases are returned unchanged by the strip helper (fail honestly at the API) and hard-rejected in validate_requested_model before the hidden-slug soft-accept, with a message pointing at the real variants. Valid variants missing from a stale catalog are accepted via the predicate without the typo auto-corrector eating the suffix.

Table-driven regression added covering eligible bases/snapshots/namespaced ids plus rejected -pro/-mini/5.5/unknown aliases, asserting both resolved context and final wire model.

[100yenadmin]

@teknium1 TL;DR — I am only about 10% confident this is a real issue. The expected behavior is that Hermes automatically compacts affected users and sessions when their effective context moves from the temporary 900K default back to the normal 272K Codex limit. I am testing the actual upgrade/resume path now.

POTENTIAL ISSUE (not merge-blocking): existing-session downgrade behavior. This PR changes the effective window of persisted affected base slugs (gpt-5.6-sol/terra/luna, gpt-5.4) from 900K back to 272K after upgrade/restart without changing the stored model id. Because this is not an explicit /model switch, context_switch_guard will not show the pre-switch shrink warning. On the first ordinary post-upgrade turn, a session above the new trigger should enter automatic preflight compaction.

I do not yet know the Hermes automatic-compaction path well enough to confirm how reliably it handles a session already far above the smaller window. When the same kind of downshift happened in OpenClaw, oversized sessions initially broke. We eventually needed multi-pass chunked compaction: divide the total context into roughly four compactable chunks, compress each in separate calls, and merge the results. That was difficult enough that forced thread rehydration within the new smaller window became the simpler recovery path.

The current Hermes evidence is encouraging: the new resolver and eligibility tests pass, and the generic switch, preflight-compaction, and overflow-recovery paths pass focused tests. The remaining gap is a direct upgrade/resume regression using an existing base-slug session created while that same slug resolved to 900K.

I am not requesting a merge block. If the direct test passes, this likely needs no change beyond preserving that regression test and using a staged rollout. If it fails, one lower-complexity migration option is to swap the aliases: keep the previous base model ids at 900K for existing users and introduce explicit lower-context ids for users to select. That avoids silently shrinking active sessions, but it also preserves the higher quota burn until users switch. Rehydration or multi-pass compaction would be the alternatives if the product must force the downshift.