Repository navigation
Support 1M token context for GPT-5.5 in Codex #19464
Description
What variant of Codex are you using?
latest
What feature would you like to see?
I want to give feedback on the current GPT-5.5 context limit in Codex.
From the official announcement, I understand that GPT-5.5 in Codex is documented as having a 400K context window, while the API version supports 1M context. So this does not look like an undocumented bug.
My concern is with the product decision itself.
With GPT-5.4, Codex users could configure a much larger context window through model_context_window. For example:
model = "gpt-5.4"
model_context_window = 1000000
model_auto_compact_token_limit = 512000That made GPT-5.4 very useful for large repositories and long-running coding sessions.
But with GPT-5.5, even though the model itself is supposed to be better at long-context reasoning and large coding tasks, Codex subscription users are now capped at 400K context. In practice, that makes GPT-5.5 feel like an upgrade in model quality but a downgrade in long-context usability inside Codex.
I understand that 1M context is expensive. I also understand why 400K might be a reasonable default for most users.
But I do not think it should be the hard limit for everyone.
For advanced Codex users, especially those working on large codebases, the choice between compaction and full context matters a lot. Codex compaction is good, but it is still a tradeoff. During complex debugging, architecture analysis, or multi-file refactors, I would often rather spend more quota and preserve more raw context than compact earlier.
A better approach might be:
- Keep 400K as the default for GPT-5.5 in Codex.
- Allow users to opt into larger windows, such as 512K, 768K, or 1M.
- Charge a higher usage multiplier when larger context is enabled, similar to how Fast mode already uses a higher cost multiplier.
The important point is user control. If a user prefers lower cost and faster compaction, 400K is fine. But if a user is willing to pay more quota for full-context runs, Codex should ideally allow that.
Right now, GPT-5.5 is advertised as stronger for long-context coding work, but Codex subscription users have less access to that long-context capability than they had with GPT-5.4. That feels like a regression in one of the areas where GPT-5.5 should matter most.
Please consider allowing advanced users to opt into 1M context for GPT-5.5 in Codex, even if it comes with a higher consumption rate.
Additional information
No response
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
umikato commentedon Apr 24, 2026
I want to add one more point because I think this is exactly the kind of product decision that creates long-term frustration among power users.
I really like OpenAI and Codex. That is why I care enough to keep pushing on this. But I hope OpenAI does not repeat the same kind of mistake that made many Claude users frustrated before.
Claude also had a period where 1M context was effectively separated from the normal subscription experience and was closer to an API / extra-usage capability. But Anthropic later moved in the other direction: in Claude Code, 1M context is now included with Max, Team, and Enterprise subscriptions for Opus 4.6 / 4.7. In other words, they listened to the pressure from coding users and made the long-context capability part of the subscription product instead of keeping it API-only.
That is why the current GPT-5.5 situation in Codex feels especially disappointing.
OpenAI’s own announcement says GPT-5.5 in Codex is capped at a 400K context window, while the API version supports 1M context. Codex already has the idea of paying a higher consumption rate for a different capability tradeoff.
I am not asking for free unlimited 1M context. I am asking for user choice.
If 1M context is expensive, please keep 400K as the default. But allow advanced users to opt into larger context windows through
model_context_window, with a higher usage multiplier if needed. This would be much better than hard-blocking the model’s full long-context capability inside Codex subscriptions.For large codebases, compaction is not always a substitute for raw context. Codex compaction is useful, but it is still lossy. During long debugging sessions, architectural refactors, or cross-repository reasoning, losing raw context can directly affect quality.
The frustrating part is that GPT-5.5 is clearly a stronger long-context model than GPT-5.4. OpenAI’s own long-context evals show a major improvement at 512K–1M. But in Codex, subscription users are given less practical access to that long-context capability than before.
Please reconsider closing this as not planned.
Mahkhmood9 commentedon Apr 24, 2026
@umikato What kind of tasks you need 1million for ?
I personally dont see it as an issue , no other model out able to compress your chat and then restart the chat again
some how it evens feels better than 5.4 (which blows my mind)
@umikato I dont think you need to be too concern, about your token use.
gpt 5.4 or 5.5 actually able to navigate huge codebases without load too much text
@umikato Do you feel the context window fill up faster?
you expect the model need to consume more and more tokens....
when the model got better and it generalize text better
Maybe you are coming from another ai models you used --- codex is crawling the code base much better than anything I seen atleast
@umikato I recomending doing some code clean up , if you context windows fills up fast, using llm ,,, is a way to fill up a big large code base -- so attempt having more lean codebase --- attempt to modernize maybe
I know its not reddit , but im trying to be helpful ;)
etraut-openai commentedon Apr 24, 2026
Thanks for the feedback. @umikato, I closed the other issues because they were filed as bug reports. This was filed as a feature request, and I'm happy to leave it open as a forum for user feedback and upvotes.
[-]GPT-5.5 in Codex should not regress from GPT-5.4’s 1M context support[/-][+]Support 1M token context for GPT-5.5 in Codex[/+]Mahkhmood9 commentedon Apr 25, 2026
In the end of the day, assume gpt 5.5 is a slightly bigger model, than what we got before ---
or they run
a different expirement that is limiting high context window .... and you are going to get a 60^10 style issue when trying to serve it... its not economical , and its
My argumnt for Smaller context window only == better
I personally really obese the 1m context window is pretty much useless
We are pretty much at the stage , that llm are not expert human , just need for keyword , or use the abstract syntax tree (AST)
No Universal Standard: A "For Loop" in Python looks different from one in C++ or Lisp at the AST level. (or even for example with c++ which has many versions and different syntaxs itself, and unablity of support) (so syntax-tree is not a practical idea for agentic coding)
and how many llm tasks are 0 shot . and a human with no ai (Websearch and a typewrite )
I love AI , and I love how random it use. you can role play the text having it make up a language syntax e.g Kygyz names - or russian/kygyz , while you are doing c++... and codex is able to play along
(I mean a friend of mine claims he speak Kyrgyz to the LLM and then it replies to him in arabic text,.........)
sometimes you use big libraries , and you need to make a heavy use of documention, nothing is really magical, but pretty much when ever I ask it for a niche functionality it scrapes what I need instantly with basic words (both in english and kygyz )
when not using English / spanish / latin languages -- it trips and repeat, it doesnt seems to be to the same level --- I cant imagine how much better the models can be if you are able to extract other languages --- or the very least,,, apply some kind of logic/ technology -- to use small tokens, for big gateways
agentic coding, faces a problem , of having a need to fail, get the error response, and then adjust --- like a human need a visual feedback (and why extremely blind people will always be limited) a human need a keyword of a function and he always a "compact state" --- for the same reason you cant speak 20 lanugages and and computer language/syntax --- then need to some how able to use external libraries / sdk / frameworks,, which is what I consdier good coding is about
So LLM , agentic coding. Not all of the techinics are discovered how to make it better --- we see the birth of amazing technology , and there is still rapid developemnt --- it still feels better every iteration --- its such an amazing tool Im so happy I had to chance to use it my lifespam
umikato commentedon Apr 25, 2026
@Mahkhmood9 Thanks for the input! I actually agree with you on a lot of fronts.
Codex's compression is genuinely great, and it's honestly one of the main reasons I use it. You're right that 5.5 is much smarter at navigating and summarizing big repos without blindly stuffing every file into the context window. For standard coding tasks, 400K + good compression is totally fine.
The bottleneck happens with a different type of workload: long-running, self-directed sessions where the model has to hold onto a massive working state. In these cases, the context isn't just raw source code. It's the accumulated state of the task—keeping track of huge architectural plans (where the plan itself can sometimes eat up 256K+), iterating over dozens of failed attempts, preserving invariants across multi-file refactors, and parsing endless logs and traces.
Compression is useful here, but it's fundamentally lossy. In deep debugging sessions, the exact details that get compressed away early on are usually the ones you desperately need an hour later. I appreciate the tip on code cleanup, but this isn't really about messy code or token anxiety. The need for 1M context is a real, practical bottleneck for power users doing heavy agentic workflows.
I also really want to emphasize how much I appreciate what the OpenAI team has been doing lately. A major reason I shifted my heavy workflows from Claude Code over to Codex was the GPT-5.4 release. Giving us that configurable 1M context was a brilliant move—it felt incredibly generous, extremely developer-friendly, and it provided the raw context needed for those heavy-lifting tasks.
OpenAI has also built a massive amount of goodwill recently by resetting Codex rate limits and clearly making an effort to pass more capacity down to builders. That overall generosity is exactly why hitting a hard 400K wall with 5.5 feels like such a jarring contrast to the direction the product was heading.
I'm not asking for 1M to be the default for everyone, since 5.5 is clearly more token-efficient. I just want the choice.
Please allow advanced users to opt into 512K/768K/1M via model_context_window and charge a higher usage multiplier for it, similar to the existing Fast mode tradeoff. At the end of the day, GPT-5.5 is undeniably a massive leap forward in model capabilities. But by hard-capping the context window in Codex, what should be a pure upgrade ends up feeling like a direct regression for the power users who rely on it the most. We just want the toolset to fully unlock what the model is actually capable of.
117 remaining items
joshua-angulo commentedon May 5, 2026
Had enough computer for x10 rate limits but not for higher context window? 😭
martinezhermes commentedon May 5, 2026
I am looking forward to seeing this implemented wisely, I've read plenty of issues concerning context rot and bugs of misuse of the Codex harness (openai/codex#8648). I feel the right implementation should come from the model side, deep into the attention algorithm... The real optimization on the context scali...
-Automatically compacting context-
-Context automatically compacted-
As I was saying this issue should be addressed soon. More context should be taken into consideration.
ariccio commentedon May 5, 2026
Did y'all just roll something out? My codex just started showing 1m context.
ariccio commentedon May 5, 2026
...weird, nevermind
wjarka commentedon May 5, 2026
It did show 1M for me and then went back to the standard 258K..
ariccio commentedon May 5, 2026
So I wasn't hallucinating
Someone at openAI must've used a Claude model briefly and then gotten a "You're absolutely right! We weren't supposed to actually turn on the 1m context beta for GPT 5.5, we were just planning! I'll go revert that right now."
Manouchehri commentedon May 5, 2026
The ChatGPT backend that codex uses can push model settings remotely (OpenAI API is a different path), so that's why you might be seeing changes.
garyfpga commentedon May 6, 2026
nope
the statusline context number is whatever you said in the config, but after the 1st message it will get the actual context number in the API calls
so the 1M you see might be just something infesible you set in the config
garyfpga commentedon May 6, 2026
I successful changed the output buffer from 128k to smaller value and have a highher context windows
model_context_window = 400000
model_auto_compact_token_limit = 330000
model_catalog_json = "~/.codex/model_catalog.json"
it is patching the offical model def
I have mine here
https://github.com/garyfpga/codex-config/blob/master/model_catalog.json
so I reduced the output buffer from 128k -> 60k, and make the autocompact start at 330k
I tried that, the context windows size showed on statusline is now 323k
I also tried the autocompact is working and this setup is okay even in some big project
it is much better than the original setup
jiangxiaoxu commentedon May 6, 2026
Hi @etraut-openai, I was wondering if there might be any update on this.
It’s been almost two weeks since you mentioned this was high priority, so I’d appreciate any good news or progress you’re able to share.
theanotherwise commentedon May 6, 2026
@garyfpga verify this fix ;) not working i already checked
Apparently it doesn’t matter whether I start a fresh session, restart Codex, use Codex UI or Codex CLI — Codex still ends up changing 400k context back to 272k (258k), exactly the same every time.
etraut-openai commentedon May 6, 2026
Just to repeat, this is not something you can work around by making client-side adjustments or configuration changes. Please do not suggest such changes because you are misleading other Codex users.
I'm going to lock this thread for now. I'll provide updates when available.