fix(codex-spark): defensive 128k entry in DEFAULT_CONTEXT_LENGTHS + clarify 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.
This commit is contained in:
kshitijk4poor 2026-05-10 11:44:11 +05:30 committed by kshitij
parent 826e7171e9
commit 44cdf555a8
2 changed files with 19 additions and 3 deletions

View file

@ -157,6 +157,13 @@ DEFAULT_CONTEXT_LENGTHS = {
"gpt-5.4-nano": 400000, # 400k (not 1.05M like full 5.4) "gpt-5.4-nano": 400000, # 400k (not 1.05M like full 5.4)
"gpt-5.4-mini": 400000, # 400k (not 1.05M like full 5.4) "gpt-5.4-mini": 400000, # 400k (not 1.05M like full 5.4)
"gpt-5.4": 1050000, # GPT-5.4, GPT-5.4 Pro (1.05M context) "gpt-5.4": 1050000, # GPT-5.4, GPT-5.4 Pro (1.05M context)
# gpt-5.3-codex-spark is Codex-OAuth-only (ChatGPT Pro entitlement) and
# uses a smaller 128k window than other gpt-5.x slugs. Listed here as
# a defensive override so the longest-substring fallback doesn't match
# the generic "gpt-5" entry below (400k) and report the wrong limit if
# Spark's context ever needs to be resolved through this path. Real
# usage flows through _CODEX_OAUTH_CONTEXT_FALLBACK at line ~1113.
"gpt-5.3-codex-spark": 128000,
"gpt-5.1-chat": 128000, # Chat variant has 128k context "gpt-5.1-chat": 128000, # Chat variant has 128k context
"gpt-5": 400000, # GPT-5.x base, mini, codex variants (400k) "gpt-5": 400000, # GPT-5.x base, mini, codex variants (400k)
"gpt-4.1": 1047576, "gpt-4.1": 1047576,

View file

@ -1,9 +1,18 @@
"""Regression tests for OpenAI Codex model validation when the listing lags behind """Regression tests for OpenAI Codex model validation when the listing lags behind
actually usable backend model IDs. actually usable backend model IDs.
The bug: `/model` and `switch_model()` reject `gpt-5.3-codex-spark` because the The bug originally reported in #16172: `/model` and `switch_model()` rejected
OpenAI Codex listing omits it, even though direct runtime calls with `gpt-5.3-codex-spark` because the curated listing omitted it, even though direct
`--provider openai-codex -m gpt-5.3-codex-spark` succeed. runtime calls succeeded. PR #19729 fixed this by soft-accepting unknown-but-
plausible Codex slugs with a warning, and this test pins the soft-accept
behavior so it doesn't regress.
Note: gpt-5.3-codex-spark itself is now in the curated catalog (PR #22991),
so the real-world Spark request takes the `recognized=True` fast path. This
test still uses Spark as the example slug but explicitly mocks
``provider_model_ids`` to omit it, exercising the soft-accept path generically
for any future entitlement-gated Codex slug that ships before Hermes catalogs
it.
""" """
from unittest.mock import patch from unittest.mock import patch