Repository navigation
GPT-5.5 context catalog mismatch makes 400K/1M setup unsafe and can bypass auto-compaction #19409
Description
Summary
Codex currently appears to expose inconsistent context metadata for gpt-5.5, and the mismatch can make long-running Desktop/App sessions unsafe: the UI/config can be pointed at 400K or 1M context metadata, while active sessions still report an effective 258400 context window and may run into Codex ran out of room in the model's context window before automatic compaction protects the thread.
This is related to existing context/compaction reports such as #16033, #16140, #14456, #13769, and #17392, but this report is specifically about gpt-5.5 having contradictory catalog/window behavior and no clear path to the same 1M context support that is available for gpt-5.4.
Environment
- Product: Codex Desktop / Codex App on macOS
- Codex App:
26.422.21637(CFBundleVersion = 2056) - Bundled CLI:
codex-cli 0.124.0-alpha.2 - Auth/provider: OpenAI / ChatGPT-backed Codex
- Model:
gpt-5.5 - Platform: macOS / Apple Silicon
- Observed date: 2026-04-24
Local config tested
model_provider = "openai"
model = "gpt-5.5"
profile = "default"
model_catalog_json = "/Users/<redacted>/.codex/model-catalog-400k.json"
model_context_window = 400000
model_auto_compact_token_limit = 220000The explicit model_auto_compact_token_limit = 220000 is a local workaround after seeing overflow/compaction issues. Without an explicit lower threshold, a 400K setup can let compaction trigger too late if the effective runtime window is actually closer to 258K.
Evidence
codex debug models with the configured 400K catalog reports:
{
"slug": "gpt-5.5",
"display_name": "GPT-5.5",
"context_window": 400000,
"max_context_window": 400000,
"effective_context_window_percent": 95
}But the live cache on the same machine contains:
{
"slug": "gpt-5.5",
"display_name": "GPT-5.5",
"context_window": 272000,
"max_context_window": 272000,
"effective_context_window_percent": 95
}A local 1M catalog file can also describe the same model as 1M:
{
"slug": "gpt-5.5",
"display_name": "GPT-5.5",
"context_window": 1000000,
"max_context_window": 1000000,
"effective_context_window_percent": 95
}Recent session events, however, repeatedly reported:
"model_context_window": 258400That equals 272000 * 95%, so the active runtime was still behaving as if gpt-5.5 had the smaller cached/bundled effective window, even though the local config/catalog had been moved to 400K.
I also hit the user-visible failure:
Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.
Why this is confusing
From the user perspective, all of these are hard to reconcile:
gpt-5.4can be represented as 1M in Codex metadata.gpt-5.5appears in different local catalogs as 272K, 400K, and 1M.model_context_window/model_catalog_jsoncan change the displayed/debug catalog, but active sessions may still report258400.- If
model_auto_compact_token_limitis not set conservatively, Codex may try to compact too late or not visibly compact before the turn fails.
If gpt-5.5 is not supposed to support 1M context in Codex, Codex should make that explicit and clamp the effective window/auto-compact threshold accordingly. If it is supposed to support 1M, the model catalog/runtime/session metadata should converge on the same effective limit.
Expected behavior
One of the following should be true:
gpt-5.5supports 1M context in Codex, in which case the official model catalog, sessionmodel_context_window, UI/status, and compaction threshold should all agree.gpt-5.5does not support 1M context in Codex, in which case Codex should reject or warn on incompatiblemodel_context_window/model_catalog_jsonsettings and clampmodel_auto_compact_token_limitsafely below the true model limit.
In either case, changing a model catalog/window should not create a state where the UI/debug view says 400K/1M while auto-compaction behaves as if the actual window were ~258K.
Actual behavior
The effective model context can drift across:
- live
models_cache.json - local
model_catalog_json codex debug models- session
token_count/task_startedevents - auto-compaction behavior
This drift makes long threads fragile and can produce context overflow instead of a reliable automatic compaction path.
Related issues
- Auto-compaction never triggers #16033: 400K config can still fail without auto-compaction firing
- Make context window and auto-compaction settings model-aware #16140: model-aware context/compaction settings are needed
- Support
model_context_window/model_auto_compact_token_limitin profiles #14456: profile-scoped context settings are ignored - Desktop app: context overflow can terminate a turn before any compaction runs, then reset status to '100% left (0 used / 760K)' and finish with no agent message #13769: Desktop can overflow before compaction runs
- Remote compaction intermittently fails with stream disconnected before completion #17392: remote compaction can fail near context limit
Activity
github-actions commentedon Apr 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
violet-go commentedon Apr 24, 2026
Additional related issue: #19208 was closed as
not plannedwith the explanation that the advertised 400K window for GPT-5.5 in Codex is split as272K input + 128K output, and the observed258400value is an effective input budget below 272K to leave space for compaction.That explanation accounts for the 258400 display, but it does not resolve the remaining ambiguity captured here: whether GPT-5.5 should support 1M in Codex at all, why local catalogs can represent GPT-5.5 as 272K / 400K / 1M, and how Codex should prevent unsafe config states where compaction thresholds are set against a larger local catalog than the runtime actually honors.
etraut-openai commentedon Apr 24, 2026
Codex supports a 400K-token context window for gpt-5.5. It does not support a 1M-token context window, at least not at this time.
We recommend using the default context window settings. If you override the default in your config, you may run into compaction issues as you've noted above. The default input context size for gpt-5.5 is 258400 which allows for a safe margin for compaction.
cyruszad commentedon Apr 24, 2026
huge regression.
NZHGREALISH commentedon Apr 24, 2026
It’s really disappointing. The model shows a great improvement with its 1M context window, but we’re already paying for the Pro plan and still can’t use it
Rainnystone commentedon Apr 25, 2026
come on, a auto-compact/context window of 300/400k is no sth aggressive，especially given that gpt 5.4/5.5 has 1M and 5.3 codex has 400k
asaffoox commentedon Apr 25, 2026
I am seeing the same practical failure pattern on Codex CLI under Windows 11 + WSL2.
My case is not only about wanting a larger context window. The problem is that GPT-5.5 in Codex behaves in a way that is inconsistent, unclear, and practically unsafe for long-running sessions.
My environment:
/model:gpt-5.5 (current) — Frontier model for complex coding, research, and real-world workThe exact context report shown by Codex when I exited the session was:
Earlier in the same session, Codex also adjusted its behavior because of the context warning:
This means the live session behaved as if the practical effective limit was much closer to 258,400 tokens, with a warning threshold around 70%. In practice, this creates a working limit around 180,880 tokens before the session starts treating the context as dangerous.
This is a serious usability problem for large-codebase work. My workflow requires Codex to preserve architecture decisions, file relationships, previous edits, logs, implementation reasoning, and validation steps across long sessions. With this effective limit, GPT-5.5 Codex becomes constrained too early.
The confusing part is that OpenAI publicly presents GPT-5.5 in Codex as a long-context coding model, but the actual runtime/session behavior I observed is much smaller and unclear. If 258,400 is the intended operational limit, the product should say that clearly. If it is not intended, then the model catalog, runtime session metadata, UI warnings, and auto-compaction behavior need to be aligned.
Please clarify whether this is:
The practical result is that GPT-5.5 Codex is currently not reliable enough for my large-project workflow, and this directly affects whether I continue paying for OpenAI Codex or return to Claude Code.
etraut-openai commentedon Apr 26, 2026
Let's continue the conversation in #19464.
cyruszad commentedon Apr 26, 2026
rosdi commentedon Apr 29, 2026
Damn… I knew switching to Codex was a bad idea. Wasted $200… back to Claude, lesson learned, I guess.
Jamailar commentedon May 6, 2026
Adding another current data point from Codex Desktop on macOS.
I originally expected
gpt-5.5in Codex App to use the same 1M context advertised for the API model, but the current Codex App/runtime still appears capped around the same effective ~258K input window.Environment/evidence observed on 2026-05-06:
For
gpt-5.5, the livemodels_cache.jsonentry currently contains:{ "slug": "gpt-5.5", "context_window": 272000, "max_context_window": 272000, "effective_context_window_percent": 95 }Recent session telemetry reports:
That exactly matches
272000 * 0.95, so the auto-compact threshold appears to be derived from the Codex model catalog rather than any stale local config.This is confusing because OpenAI's GPT-5.5 announcement distinguishes Codex and API context windows, but in practice users may see "GPT-5.5 supports 1M" and expect Codex App to receive that same window after updating. If the Codex product intentionally uses a smaller window than the API model, it would help if Codex exposed the effective input/output/context/compact numbers directly in the UI or model picker, and documented that Codex App GPT-5.5 is not the same context tier as API GPT-5.5.
Request:
272000catalog window /258400effective threshold.jb510 commentedon May 19, 2026
Writing this as a watch codex run compaction after each step of a short running loop (60 minutes).
I can't comment on #19464, but I find this extremely frustrating. I fully understand 1M can often worsen things due to context rot, but there are also a myriad of cases where a large window is absolutely needed. I have no problem with Codex defaulting something tiny like 256k, although I'd prefer it were 512k as I find that the sweet spot. But FFS let people control it up to 1M if that's what they want. This is ridiculous.
cyruszad commentedon May 19, 2026
ci(codex): switch to gpt-5.5 + wire_api=responses
ci(codex): switch to gpt-5.5 + wire_api=responses
ci(codex): switch to gpt-5.5 + wire_api=responses