GPT-5.5 context catalog mismatch makes 400K/1M setup unsafe and can bypass auto-compaction
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
- #16033: 400K config can still fail without auto-compaction firing
- #16140: model-aware context/compaction settings are needed
- #14456: profile-scoped context settings are ignored
- #13769: Desktop can overflow before compaction runs
- #17392: remote compaction can fail near context limit
13 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.
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.
huge regression.
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
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
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.
Let's continue the conversation in #19464.
Okay, I know that you guys want to continue this conversation on the other
thread, and that's okay, but I honestly think this is probably the only
opportunity I have to respond and give you guys advice. Hopefully someone
from OpenAI can read this.
I have literally looked at my usage with 5.5, and it's using probably twice
or three to four times more tokens in two days, and my usage has not
changed. I'm literally doing the same kind of work day to day, and there is
definitely something wrong. It's either the harness or there's something
else. From my investigation into this, it looks like by you guys limiting
the context window, it is taking up more tokens. I'm not going to actually
go into detail and tell you how to do your job. That's not my job; it is to
be here and give you guys all this valuable advice.
What I can tell you is that with a 1 million context window, you're
actually helping save more in terms of internal costs. I don't know how you
guys measure that, but the cache stays for longer. I don't even think it's
a cache thing; it's probably something else. Let me just tell you in simple
terms: having a 1 million context window is going to probably save you on
costs. I'm not going to get into why; it's kind of hard to explain, but I
can't really say much. What I'm trying to say is that this is the smartest
option from my findings. That's one thing.
The other thing is that it's very unfair that this model has a 1 million
context window and it's only available via the API. I don't understand why
you guys are like. The 1 million context window should be available if the
model is capable of a 1 million context window; it should be available to
your codex users, at least the pro users. If you want to charge additional
usage for that, that's fine; that's fair. If it costs you more money,
that's fine, but to just not include it, you're hurting a lot of your
customers.
Honestly, you guys have to figure out a way to make this work, because I'm
pretty much going back to Anthropic, because at least they're not pulling
these weird moves. You guys are absolutely regressing in terms of context
window; you're regressing. I think you should not be going backwards. We
went from 5.4, which had the 1 million context window, and I feel like you
should be moving forward, meaning that you maintain the 1 million context
window. That's more of a thing; a lot of model providers are doing that
now, so I don't understand what OpenAI is doing. The model is not efficient
at all; it literally is using up so many tokens, so that's also a lie. I
don't understand what you guys are doing, but whatever you're doing is not
working; either your harness, you're still figuring things out, or what?
Obviously I'm not privy to that information, but all I can tell you is
that, based on my usage patterns, it's something's wrong and it's
definitely concerning.
On Sat, Apr 25, 2026 at 7:33 PM Eric Traut @.***> wrote:
Damn… I knew switching to Codex was a bad idea. Wasted $200… back to Claude, lesson learned, I guess.
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: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.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.
I can’t wait for Anthropic’s next model
On Tue, May 19, 2026 at 8:21 AM Jon Brown @.***> wrote: