fix(codex): restore gpt-5.3-codex-spark for ChatGPT Pro (salvage #18286 + #19530, fixes #16172)#22991
Merged
kshitijk4poor merged 8 commits intoMay 10, 2026
Conversation
Maps olegwn@gmail.com → nederev (PR NousResearch#18286) and vesper@askclaw.dev → askclaw-vesper (PR NousResearch#19530) so the contributor attribution check passes when their commits land via this salvage.
PR NousResearch#12994 stripped gpt-5.3-codex-spark on the assumption that it was unsupported. It's actually research-preview, ChatGPT-Pro-only, exposed via the Codex OAuth backend at chatgpt.com/backend-api/codex/models — not via the public OpenAI API. Add explanatory comments in: - DEFAULT_CODEX_MODELS / _FORWARD_COMPAT_TEMPLATE_MODELS (codex_models.py) - _CODEX_OAUTH_CONTEXT_FALLBACK (model_metadata.py) - list_authenticated_providers' live-discovery branch (model_switch.py) so future maintainers don't strip the entry again. Also documents the intentional asymmetry that Spark stays out of the "openai" provider catalog (it isn't on the public API) and why the supported_in_api filter is *not* applied for the openai-codex route.
…ministic Two follow-ups from self-review: 1. Add unit test for _fetch_models_from_api covering the live HTTP path. The salvaged PR NousResearch#19530 dropped the supported_in_api:false filter in both _fetch_models_from_api and _read_cache_models, but only the cache path had a regression test. This adds the symmetric live-fetch test (mocked httpx) so a future drive-by change to the HTTP path can't silently re-introduce the filter. 2. Pin test_codex_picker_uses_live_codex_catalog to the cache fallback. The test wrote a fake JWT and a CODEX_HOME cache, but provider_model_ids ('openai-codex') still issued a real 10s HTTP probe to chatgpt.com/backend-api/codex/models before falling back to the cache. That made the test slow and non-deterministic in restricted/CI networks. Patch _fetch_models_from_api to return [] so we go straight to the cache path the test actually means to exercise.
…larify validation test docstring Two follow-ups from self-review: 1. Add gpt-5.3-codex-spark to DEFAULT_CONTEXT_LENGTHS at 128k. The primary resolution path for Spark goes through provider='openai-codex' → _CODEX_OAUTH_CONTEXT_FALLBACK (already correct). But if any future code path resolves Spark's context with a different provider (custom proxy, generic fallthrough), the longest-substring-first lookup in step 8 would match 'gpt-5' and report 400k, which is wrong by ~3x. Adding the explicit override is a cheap defensive correctness fix matching how gpt-5.4-mini and gpt-5.4-nano already shadow the generic gpt-5 entry. 2. Update test_openai_codex_model_validation_fallback.py docstring. The bug it was originally written for (gpt-5.3-codex-spark missing from listing) is now resolved by this PR's catalog restoration. The test still validly exercises the soft-accept code path for any future entitlement-gated Codex slug that ships before Hermes catalogs it, but the framing was stale — clarified.
33c3cd9 to
470b8e7
Compare
This was referenced May 10, 2026
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Salvages PR #18286 (@nederev) and PR #19530 (@askclaw-vesper) into a unified restoration of
gpt-5.3-codex-sparkfor ChatGPT Pro subscribers, fixes #16172.PR #12994 (April 2026, mine) removed
gpt-5.3-codex-sparkfrom the openai-codex catalog on the assumption that it was unsupported. That was wrong. Per OpenAI's Codex pricing page and Codex developer docs:So it's a real, valid Codex model — just gated to the ChatGPT Pro subscription via the Codex OAuth backend (chatgpt.com/backend-api/codex/models), not the public OpenAI API. Two community PRs fixed pieces of this; neither alone is sufficient. This salvage combines them and adds documentation so it doesn't get stripped again.
What landed (per-commit, original authorship preserved)
feat(codex): add gpt-5.3-codex-spark modelDEFAULT_CODEX_MODELS+ forward-compat templatesfix(model-metadata): restore gpt-5.3-codex-spark fallback context_CODEX_OAUTH_CONTEXT_FALLBACKfix(model-metadata): set codex-spark fallback context to 128kfix: surface Codex CLI-only modelssupported_in_api: falsefilter; wire gateway picker to live discoverychore: add codex-spark salvage contributors to AUTHOR_MAPdocs(codex-spark): document ChatGPT Pro entitlement gatingtest(codex-spark): add live-API regression and make picker test deterministicfix(codex-spark): defensive 128k entry in DEFAULT_CONTEXT_LENGTHS + clarify validation test docstringgpt-5match); docstring cleanupWhy both PRs together
Spark only flows through one path: the Codex OAuth backend. That means three things must all be true:
supported_in_api: falsefilter must be removed. The Codex backend reports this flag on Spark because it's not in the public OpenAI API — but Hermes'openai-codexprovider talks to the same OAuth backend Codex CLI does, so the flag is irrelevant for our route. (PR fix: surface Codex CLI-only models #19530)/modelpicker must use live discovery for openai-codex. Otherwise Telegram/Discord fall through to a static curated list that has no way to reflect ChatGPT-Pro-only entitlements. (PR fix: surface Codex CLI-only models #19530)PR #18286 alone leaves the filter in — Pro users see nothing from live discovery. PR #19530 alone leaves no fallback — offline users see nothing. Both together = correct.
Asymmetry: openai-codex vs openai
Spark stays out of
_PROVIDER_MODELS["openai"](the public API key catalog) on purpose. It isn't on the public OpenAI API. The new docstring onDEFAULT_CODEX_MODELSdocuments this intent so future cleanups don't strip the entry again.Test plan
scripts/run_tests.sh tests/hermes_cli/test_codex_models.py \ tests/hermes_cli/test_codex_cli_model_picker.py \ tests/hermes_cli/test_openai_codex_model_validation_fallback.py \ tests/agent/test_model_metadata.py→ 119 passed locally, against current
origin/mainafter rebase.E2E coverage (verified in an isolated tempdir with mocked httpx):
DEFAULT_CODEX_MODELSreturns Spark when no token + no cachesupported_in_api: falseslugs (Spark survives,visibility: hiddenstill gets filtered)supported_in_api: falseslugsgpt-5.3-codexvia Codex OAuth fallback (longest-key-first match)DEFAULT_CONTEXT_LENGTHSlongest-substring lookup also resolves Spark → 128k (was 400k via the genericgpt-5entry)provider_model_ids("openai-codex")end-to-end returns SparkCloses #16172. Supersedes #18286, #19530.