Support 1M token context for GPT-5.5 in Codex
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_
132 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.
@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 ;)
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.
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
@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.
@tibo-openai Where's 1m context window, Tibo?
@tibo-openai What's with this regression? Rug pull our context? Then say it's a feature request when we want it back. It's clearly not. Please restore this functionality. These types of changes are really not acceptable. I have spent an hour this morning debugging why my context is set back to default. I really did not expect this from the release of a new model.
While it may be nice to have this as a product option for pro users, I don't think some of ya'll fully appreciate how quickly it'll decimate your usage limits. Going by eye test, rapid usage depletion has been one of the most frequent complaints here since
gpt-5.4was released. An opt in to 1M would probably make it worse.Would it be nice to have an opt-in for 1M? Sure. Would everyone who does so have the grace to acknowledge that $200/$100 only goes so far? Probably not.
I truely think openai maybe overconfident with the compaction function. It is good, but not good enough to let the session run consistant enough in long tasks.
Let me give few real examples:
Then, let's talk about business matters:
What I think maybe good to solve this issue:
Thank you and I hope we can make everyone happy, either users and OpenAI fellows.
I fully agree with your perspective. I’m utterly frustrated by the drastic reduction of the context window for GPT-5.5 within Codex.
When working on architecture-level issues in large-scale projects—or problems involving complex coupling across multiple submodules—the planning process can easily trigger automatic context compression. This completely breaks the planning workflow. What makes it worse is that you often don’t notice the compression has happened until your plan has already deviated drastically from the original context and requirements, resulting in massive wasted credits. I’m forced to split my work across separate chat sessions just to lay out project plans step-by-step, which severely hinders development efficiency.
Automatic compression can also kick in mid-execution of complex workflows, drastically undermining execution accuracy and reliability.
I have no issue paying for more credits; I’d even maintain multiple premium accounts just to secure higher usage limits. What I cannot accept is uncontrolled, arbitrary degradation of model performance.
With the current ill-conceived context restrictions imposed on GPT-5.5 in Codex, its overall performance is now inferior to budget-friendly open-source flagship models like Deepseek-V4-Pro.
So honest question to the OpenAI team then, why would i use Codex vs Claude on an enterprise level when Claude defaults to 1M context. My company currently is evaluating both and i have both systems. As an example, our codebase is 20 years old the AI context passed through via either claude.md or agents.md brings the model to 80k context. I ask it to explore 3 files and 1 document and i am at 220k. So Claude can continue, Codex compacts and has lost all the vital information. This is a real scenario with the most optimised of workflows. We will ofc choose Claude. 1M context in the enterprise world is a non-starter. We never get beyond 400-500k but thats the cirtical part. And before you say Codex supports 400k context, no it does not it supports 258k after you take the output tokens.
Then their is the issue where GPT 5.4 would start answering older random messages instead of my question once i reached 220 000 context. On the other hand the people who say gpt 5.5 is better this happened with 3 messages on 5.5, i filled a /feedback on the data.
The current GPT-5.5 model is triggering context limits much faster than before, leading to frequent interruptions during long tasks. When it resumes after automatic compaction, it often suffers from memory gaps, making it unable to complete even medium-difficulty tasks. The overall usability is extremely poor.
I hope the OpenAI team takes this issue seriously. The experience in Codex has significantly degraded, and many tasks that were previously completed normally are now impossible to finish. I have already switched to using Opus 1M. If this issue cannot be resolved, I will consider stopping the purchase of GPT Pro subscriptions for my company's employees.
Yeah, this bit me. I'm used to going all the way up to 970k+ in Claude with compaction off, saw 5.5 and saw that 400k was available in Codex and decided to try it anyway "I can work with 400k". Turns out it's only ~250k in practice. Not a good experience.
Apparently you can't even do 1M with 5.4 anymore either?
The reality is not having 1M context model , Just going to make it better for users
there is an hardware crsis
more users benefit from not having few users , using 5-10x the compute
I am not going to blame anyone pushing massive code bases into the llm,,, because its an artificial side effect of other models
and now newgen models need to fix the damaged already done in thoery
for example the over rated "opus" I used the 1m context windows, what I observe , for the same task it needs to spew 100 words
when gpt5.4 or 5.5 makes it instant with 5 words
antrhopic models just make up stuff, thats it - they need 1m context window for their nonsense
---
understand the increase to 400K is likely a sweetspot , that openai found , so its likely very good -
the product s good , not only on eval codex is really good
I dont want 1m back
In reality, I am unable to complete tasks normally now. Previously, when I used GPT-5.4, I didn't actually adjust it to 1M because the performance was particularly poor, but I didn't encounter the situation of having to compact two or three times in a single session as I do now. In Codex + GPT-5.5, I encounter this situation frequently, so it is impossible to complete tasks at all.
OpenAI should thoroughly investigate the context engineering issue. Is there some garbage being inserted that is causing the context to expand faster than ever before?
Opening up 1M for GPT-5.5 is just the first thing that comes to mind when people encounter context limits and compaction, but based on our current experience, the root cause may not be there. However, as a Pro subscriber, I still hope to have the permission to use 1M; otherwise, for the same subscription, Codex is far worse than Claude Code.
@tibo-openai
Even if 1M is available, you don't have to enable it, but you shouldn't call for the removal of this feature.
The reality is , that a lot more users now use codex - its just not feasible to have 1m context window
I really recomend the Memories option, maybe its what you are looking for
1m tokens (atleast now) is pointless because ai repeats itself , and if you look at a 1m tokens , its just repeated CoT .... Long Long Long sentences,,,, for basic logic
@liuzhiguo630
<img width="812" height="277" alt="Image" src="https://github.com/user-attachments/assets/ce6f6841-9463-4e5b-bc75-48c01944e258" />
Be happy you get to use such an amazing service with 98% SLA
as per said-company , you can see how many issues they are facing --- codex is so well designed , by so many aspect... economical, Architecture , design --- simplicity
I love how so few options you get in codex,,, instead of 200 feature, sub-sub features but ohh no, we are going to neglect the development of this new feature far as I concern none of the features documented in the Codex Documentation is neglected or unmaintained
the codex team, openai --- follow strict standards ---- when they make their products --- codex is literally the definities of field tested
we are literally facing another Bell Labs
Even if this is not the peek of ai , i am so happy with what we get as of now --- all I want is in the future to get maybe cheaper --- AGI has been reached as of today
<img width="882" height="470" alt="Image" src="https://github.com/user-attachments/assets/e4a0d291-0ebb-445a-aaa8-1fbc3107b06b" />
I am sorry but this reply is a joke "Be happy you have this" lol wtf. We are not because we work in enterprise, we are allowed to voice our complains and basically we are not happy. What this means for OpenAI is that we will take our business elsewhere, simple as. You are free to be happy but its not about being happy is about the use case and simply put this is not an enterprise ready model.
Additionally you said use memories, do you even know how that works? That is injected as a prompt at the start of a model. In our case already at 80k context from the project context so your argument is to feed more context and have even less context when working with this model?
@HarryPitsillides
Honestly be happy the gpt 5.5 400k context window , is what you assumed you wanted
unlike "said company" that let you use a 1m context window , but secretally degrade the preformance
@HarryPitsillides But I respect if you disagree with me ? Can you share examples - or prompts , 1million-context window is needed?
So, yes? As i've said we have a codebase of 20 years code. Some modern some not, all split up and optimised. We even used specialized agents. And as i've said we are comparing Opus 4.7 and Codex 5.4 at the time. You say said company is degrading performance but honestly? I have never seen opus answer an older message like GPT 5.4 and 5.5 if that is not a model failure and degradation i do not know what it is. I will obviously not delve into our companies tech stack in a github thread. Each tech stack has its own skills for the agents we have been working with AI for 3 years now, and with Codex for the past 3 months. But its clear which company caters for enterprise vs which one is not. Is Claudes SLA horrible? Absolutely, but i'd rather have a usable model i can use 98.7% of the time vs 99.8% but useless.
I recomend enabling the memories option
https://developers.openai.com/codex/memories
the memory feature is _disabled_ by default maybe for security reasons -- or not too mature reasons
Insanely good
But to be fair, I personally suffered from 10 year old critical code I ow "Technical Debt" / "Spaghetti Code"
and LLM , has a "refusal crsis" when it refuses to change bad-logic-code
with codex , for example I like to say something like first prompt
``
explain the class``or use the "plan-mode" and ask it , add jsdocs and documentation to the classes --- (in your case maybe use the memories option)
Its really lean, for example for Opus, anything that anthropic would do is 300k inmemory text files --- the openai is really lean
Look I maybe not done anything more than game-engine development in my Professinal life, and many many years ago- I am not a developer for over 25 years now
To be honest , I think it comes down to study how your code fail, in what aspects
documentation and specifications are there for a reason
maybe your code is poor documentated , maybe your code has too much false logic
I am not saying rushing to delete
developing is the joy of study , the joy of making things efficient --- thats how I see it atleast
But I respect you 100% , if you think there are things to improve, there is 100% room for improvement in AI
for example the "code review option" can also reason and crawl and understand your large code base
https://developers.openai.com/codex/app/review
I am trying to argue , unerstand how to work with large codebase , is something very new -- and its a skill you need to learn
I generally dont have any issue with the very large code bases I maintain but its just me maybe
@HarryPitsillides I 100% respect you if you disagree with me
@HarryPitsillides you mentioned you mentioned the memory option takes a lot of context window ,, not really it summrizes ,,, it guid the Codex gpt 5.4 ,,, into the correct "classes names " and importent what you want to do , and what the use exceptation is
its very lean, and doesnt eat the context window atleast for me
I am sorry i am replying because i do not want people to feel they are left ignored, but i will be brutally honest with you. You sound like you have a vetted stake in OpenAI we have teams who analyse how to work with AI and best practices we have considered all of this. Simply put for us Gpt 5.5 without 1M is a no-go. That is the end of that discussion. We can chat and talk but that position will not change. And as you can see from the multiple github issues that are now being closed / opened and merged about the same exact problem this is not a personal feeling but a blocker for a lot of people. I will leave this conversation here, and appreciate all the good back and forth we had but this is a thread to request for 1M context. We have made our case and we have our reasons, we do not want it because a competitor has it or because we think its fun. This is a real use case to us.
And just to clarify even it is added, we might still end up choosing a competitor model. We are evaluating competing products.
I really think 1m context window is pointless ... But the enhancement is real in terms of using large code bases...
You know my father was a chemist --- he almost never done anything without his refrence book --- and he was not a genius , in many ways they are many task he never was able to do even in his prime
Need to learn about a chemical specfication , go to the currect class.
I am going to argue, from what I seen the people who use "1m" context window
is a result of a lot of code that piles up -- and people who are too proud of code
you dont need to memorize
I still going to argue even the best developr alive dot memorize 80-000 lines of code --- but he understand which files and functions to access
maybe you using outdated framework,, amybe you use poorly configued setup
2.1 Claude just makeu up stuff when I ask it to explains ,, all tho its sounds beliveable, it just make up stuff --- and generating too much text ,, and Claude is Flibbertigibbeting(lie and make up stuff) with confidenice
I understand every project is different. For some project, 1M is overkill. However, we do need to admit that long context window has its value for many projects. Longer context will causes performance downgrade, because of the attention distribution on long context is not as equal as short context. In some projects, we have to adopt this. It is the tradeoff. If context length shoter than a number, the project will spend exponentially more rounds and time to finish, even not feasible, because of frequent compaction and resume crom previous work. Longer context will have more errors, but the time we spent on these are linear. Not talking GPT-5.5 already have much better proformance on longer context compare with GPT-5.4 and Opus 4.7. Not all projects can be atomize that can handle by 400k window. There are complex projects has long and messy dependent, and sometimes feed the entire repository (at least a module) into the model is the only option.
And just to clarify even it is added, we might still end up choosing a competitor model. We are evaluating competing products.
To be fair the jump from gpt 5.2 to 5.4 was really big, anything bad I had to say about gpt 5.2 or gpt 5.3 is already fixed in my world view
The context window is now insufficient to an extreme degree; I hit the limit after only three rounds of conversation, which was definitely not the case before.
Incidentally, I tried recompiling Codex to bypass the 258k context limit, but it turns out the server-side also enforces context length restrictions.
<img width="1684" height="346" alt="Image" src="https://github.com/user-attachments/assets/d1121c2e-59d3-4003-aeb8-a1f3f4ab2d6e" />
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. it's rational
The dont use a modfied version of Codex , why did you try to patch it ? So you edited the code and settings --- you are using a broken version , you are misleading
I can recomed you to use this option https://developers.openai.com/codex/memories
@Mahkhmood9, please moderate your responses or refrain from participating in this conversation. Others in this thread are providing reasoned feedback. You're dismissing their concerns and pulling the conversation off topic.
I agree with the original uploader of this issue.
At the very least, I believe there should be an option that allows users to configure settings based on their own preferences.
In my case, I couldn’t find any option in the Codex app to adjust the context window for the GPT 5.5 model.
Currently, I’m working with a 258K context window, which forces me to go through frequent compacting during my workflow.
I’d like to share this feedback regarding the issue that has been raised.
<img width="803" height="185" alt="Image" src="https://github.com/user-attachments/assets/9dceb072-d6af-4952-a99b-e93fac9e58b6" />
I strongly agree that a larger usable input window would be valuable, even if most workflows do not need to go all the way to 1M context.
In real coding workloads, the current effective limit often feels like it cuts off just a little too early. Many long-running automated tasks only need another few tens of thousands of input tokens to finish the current task phase. Instead, once the session hits the automatic compaction threshold, the model loses important raw context and then has to re-read many of the same code files before it can continue.
This creates a counterproductive result: the smaller context window does not necessarily save user tokens or server compute. In practice, it can increase both, because the model spends extra input tokens and reasoning tokens rebuilding context that was already available before compaction. I often see cases where, after compaction, the model re-reads a large amount of code, even though only a few files actually remain to be modified. If the available input window had been just 30K-80K tokens larger, the task could likely have completed in one continuous pass, faster and with less wasted work.
For that reason, I think the most useful product control would be per-chat-thread configuration of the usable input window size before automatic compaction is triggered. Most users probably do not need a 1M window all the time, but intermediate options such as 300K, 320K, 350K, or 400K of actually usable input context would be very meaningful in real development workflows.
This distinction matters. These numbers should refer to the real input window available to the model before compaction, not the marketing-level total context size of the underlying model, where input and output are counted together. For example, calling something “400K usable context” while reserving 128K tokens for output, leaving users with far less actual input capacity in practice, would be highly misleading. What matters for Codex workflows is how much raw project, conversation, tool, and code context can actually remain available as input during an active task phase.
For many tasks, accepting a small amount of possible model degradation in exchange for preserving raw context, reusing the input cache, reducing repeated file reads, and finishing the current task phase more quickly would be a very reasonable tradeoff.
It may also be useful to add an additional option for phase-aware compaction. For example, after a clear task phase has completed, Codex could trigger compaction through a hook or built-in mechanism before starting the next phase. That would allow users to use a slightly larger input window only when it helps complete the current phase, then compact at a more natural boundary instead of interrupting the model in the middle of active implementation or debugging.
In short, I do not think the main need is always “give every thread 1M context.” The more practical request is: let users control the automatic compaction threshold per thread, with intermediate sizes above the current effective limit, and make those sizes refer to actually usable input context. That would help Codex avoid wasteful mid-task compaction and complete coherent task phases with lower latency and lower total token waste.
upvoting this
1m context is very useful in some cases. right now i have to still use gpt-5.4 in those since gpt-5.5 doesn't support it.
After many threads and a lot of user feedback, I still don't understand why our efforts are not making a difference. I hope OpenAI will take this seriously.
Many of us have opened numerous issues in the Codex project requesting that the context window be increased — up to one million tokens.
Yet all we receive are excuses and justifications, nothing more.
I genuinely don't understand how many times we need to come back and raise this point. How many times do we have to bring it up? How much reasoning do we have to provide?
Please stop limiting your users and show some respect for their feedback.
At the very least, we deserve to be able to use the full potential of this model when we are paying for it.
If it truly consumes fewer tokens — as you claim — and if it is more accurate than the previous model, then why shouldn't it have a one-million-token context window?
Please take our feedback seriously. With respect, I sincerely hope this request receives the attention it deserves.
yes, 1M might lead to chaos, but reasonable increase the context to 400K should be considered,
no, it is not working. i did the similar thing -- i set compact/context window to be 300/400k and i was using gpt 5.5 high, but it jumped to 100% when context window reached 260K and then saying that the context window was full without triggering any auto compacts.
Codex 1M was amazing. Now it’s completely useless. I witnessed tasks that it couldn’t complete and looping on itself because it lost track of what it did be completely solved first try once 1M context window was added.
I understand that some novice users on this thread who play with small and low-complexity code bases feel like they don’t need it and try to noobsplain basic things like we should “use memory” as if we didn’t already optimize the ѕһіt out of it. I have 15 options in my configuration (things that don’t appear in the GUI) and you can bet I explored every possibility and I know what I am doing.
Stop gaslighting us, power users know what they are doing and unhelpful basic advice that clearly comes from a place of ignorance (thinking for example that memory is magic and doesn’t use context) doesn’t help anyone. If this isn’t solved soon I’m moving off to Claude Max 5x, it’s the same price as ChatGPT Pro 5x but I get a decent context window (3x larger than Codex basically)
To me the 1M context is a must, most of my serious projects are using about 500k context. Right now, even with $200 pro plan the codex subscription for gpt 5.5 can only be for hobby projects. Hope we can have a clear explanation and future map asap for serious users to re-consider continue subscribing or switch to pure API usage.
I strongly agree that the GPT-5.5 subscription should support a 1M context window.
Otherwise, I may have no choice but to cancel my Codex Pro subscription and switch to other AI services, such as Cursor.
It would be valuable to hear from OpenAI why the 1M context window was removed from Codex in the first place.
Right now the only way to access 1M with GPT-5.5 is via the API directly.
The most plausible reason I can see is cost: GPT-5.5 is priced at 2x GPT-5.4, so anything past ~272K input tokens would burn through subscription usage limits almost instantly.
Hi OpenAI team, could you please enable the 1M context window for GPT-5.5?
This larger context window is extremely helpful for working with large codebases, long documents, and multi-file debugging workflows. Thanks!
Do you have any benchmark to support these?
I don't think these things are correct.
According to the public benchmarks from Cline, there's a huge performance regression with 1M context.
凌晨3点，我盯着 Codex 的 400K 上下文窗口发呆。我的代码库有 500K tokens 的上下文。
400K不够用吗？说实话，够了。
但问题是：我们是不是在用"更多上下文"掩盖一个更根本的问题？
上下文膨胀悖论
我在用 AI 编程代理运营 miaoquai.com 的过程中发现了一个规律：上下文越大，AI 越容易迷失。
就像你给人看了一本500页的书，让他帮你找一个错别字。理论上信息都在，但他可能找不到，因为噪音太多了。
1M context 的真正价值不在于"一次塞进去更多信息"，而在于：
但如果你的用法是"把整个 repo 塞进去让它改"——那你可能需要的不只是 1M context，你需要的是一个更好的工作流。
我的经验
我们在妙趣AI使用 sub-agent 分治策略：不是把所有上下文塞给一个 agent，而是让每个 agent 只关注自己的领域。这样即使 400K 的上下文也能干 1M 的活。
参考：https://miaoquai.com/stories/ （踩坑实录，真实运营经验）
I think the important distinction is that configuring a 1M context window does not mean the model has to actually consume the full 1M context all the time. It is just an upper bound.
In practice, you could use 258K, 268K, 278K, or whatever slightly larger window is just enough to finish the task. Once the task is done, compression can happen. That lets us benefit from variable-length context instead of being forced into a fixed cutoff.
Also, I do not think the model becomes unusable simply because the maximum context is configured to 1M. The degradation comes from gradually filling the context with more and more tokens, not from the configuration value itself.
<img width="1492" height="992" alt="Image" src="https://github.com/user-attachments/assets/f06e32ca-0794-4179-b661-ebd7da95855c" />
Due to the so-called "400k" and the shitty server-side limitations, this session is now stuck in an infinite loop of compacting and cannot continue due to server-side errors.
I didn't say we shouldn't have this option. I'm trying to correct his conclusion or get some updates from him.
I've already tried this at the first time. It's just bad on myside.
You are right that GPT-5.4 also scores very poorly on long-context tests, far behind Opus. That is exactly why we had high expectations for GPT-5.5.
But Codex being limited to only 272K input tokens is completely unacceptable.
I would say the discussion here is becoming a little bit deviated from what it should be.
In my opinion the topic here is clear:
such small context sizes are stupid. sure, some vibe coders might say compaction works great, but if you want to use codex in a more serious context, you have a detailed spec and it needs to look through parts of your code to warm-up. now you are left with maybe 40% available context size or sometimes even less. then you run into compaction and it starts to produce shit.
i understand the desire to say "but the model should be able to intelligently fill its context for each request", but we just arent there yet.
we dont have to get the full million, 500k would help already
Here is a summary of the issues encountered:
In summary, this is not just a question of whether to directly enable 1M context, but rather a serious incident caused by recent engineering flaws in Codex combined with the 258K context limit of GPT-5.5.
@etraut-openai I strongly suggest that instead of enabling the 1M option in Codex, you first lift the server-side restrictions to alleviate the series of issues currently being encountered.
I think the issue you are running into should be fixed by this PR: https://github.com/openai/codex/pull/19707
Once it gets merged, it should be fine.
This only addresses the issue of data loss caused by premature compression and delayed tool calls. However, we are actually discussing the 1m contexts problem. For users logging in via OAuth, the number of contexts appears to be a hard limit imposed by the server.
You are absolutely right. I only mentioned that PR because it should fix the compression issue.
The OpenAI OAuth path appears to have a server-side limit that caps GPT-5.5 input context at 272K. And from what I can see, even with API login, the latest Codex repo version should still be limited to 272K by Codex’s own built-in config.
Just to add to the request for 1M context.
Deal breaker for large codebase tasks, after using gpt-5.4 with 1M context window.
Thanks for all the feedback! Quick update... We're working to make the 1M-token context available for gpt-5.5 in Codex. I can't give you a specific timeline yet because we need to do some capacity planning to accommodate this, but we're making this a priority. I'll update this thread once we have more details to share.
wait all the time you need, if it means it doesn't get stuck replying to old messages instead of the current one
W! Now just keep 10x for $100 plans permananet and OpenAI will ascend to S-tier :)
Great news. Thanks for the update.
A side point: given that you’ve already doubled the API pricing with GPT-5.5 compared to GPT-5.4, it would be appreciated and make sense to keep pricing the same across the full context window rather than adding another premium above ~250k.
Model catalog (API)
<img width="1164" height="559" alt="Image" src="https://github.com/user-attachments/assets/2e46bc44-9cb7-44ab-8eb7-f61ffa884758" />
The official OpenAI blog post
<img width="1413" height="513" alt="Image" src="https://github.com/user-attachments/assets/9ae583e2-f897-4363-9149-4d75f0dace70" />
Reality (in codex gui)
<img width="336" height="186" alt="Image" src="https://github.com/user-attachments/assets/3eb82f5e-b472-466a-86f4-3afd3509fdd3" />
This DOES look like a bug @etraut-openai - the lower bound according to the announcement is 400k.
relevant:
<img width="1179" height="681" alt="Image" src="https://github.com/user-attachments/assets/a5b71433-4182-4719-b6fb-85833c3b48f3" />
@Thinkscape model context windows have always referred to input+output. 400k ctx on the broad model release is different from that available in codex. Eric explained it in https://github.com/openai/codex/issues/19185#issuecomment-4316753237 https://github.com/openai/codex/issues/19185#issuecomment-4317217599
Thank goodness they used their brains. fyi it's more expensive to not do 1m due to compaction.
@Thinkscape OpenAI marketing likes to add in the 128k output window to make the number seem larger, despite no-one else doing that including their own tools.
Great news about the upcoming 1M context support—I hope it becomes available soon! I've been struggling with this recently because my codebases are quite large, and debugging a single issue easily consumes the current 258K limit. As much as I appreciate the GPT-5.5 release, frequently having to compress my context length is severely disrupting my workflow. I am used to working with an 800K context (my custom max_window for GPT-5.4). This leaves me with a difficult choice right now: should I prioritize GPT-5.4 for its 1M context, or use GPT-5.5 despite the 258K cap?
I'm also encountering this problem. My project is very large, and when I complete a requirement, context compression is triggered after only two or three rounds. I hope to update the 1MB context as soon as possible.
Just to add in my two cents/$200, I found the sweet spot for me with GPT 5.4 was around 500,000
model_auto_compact_token_limit, below that I was losing too much context in compaction on multi-day sessions, and above that codex started getting a bit schizophrenic (yeah, honestly, it feels hilariously a bit like I'm talking to someone with schizophrenia thought blocking and/or avolition). The extra 100k tokens of GPT 5.5 at 500k+ would save me a lot of tokens and time overall!@etraut-openai
I think if you rolled out something in between, maybe ~628k token context window, and charged 2-3x for it, many power users might be happy with it, without needing the full 1m
@etraut-openai @tibo-openai I’d love to see the context window keep moving toward 1M tokens, but I think it would be totally fine if it happened gradually.
From what I’ve seen in this thread, a lot of people probably do not need the full 1M tokens right away. Even smaller increases would already help a lot for large codebases, debugging longer sessions, and working across multiple files.
Maybe increasing the limit step by step would be a good middle ground. It would let users get the benefits sooner, while still giving the team room to manage performance, latency, and infrastructure costs.
So even if 1M is the long-term goal, I think gradual increases would already be very useful for most users.
No we def need 1M context and OpenAI would be extremely dumb to not do
that. I think 1M is good. OpenAI is listening to feedback. Good!
On Tue, Apr 28, 2026 at 1:22 PM Joshua Angulo González <
@.***> wrote:
I agree that 1M context would be extremely useful, and I definitely want OpenAI to get there.
My point is more about timing. If the full 1M context takes longer to ship reliably, I think it would be better to get smaller increases sooner instead of waiting until the full 1M is ready. For a lot of real use cases, even a jump to something higher than what we have now would already make a big difference.
So I’m not saying we do not need 1M. I’m saying gradual increases could help users much earlier while OpenAI keeps working toward the full 1M context window.
Agreed. I'm fine waiting a bit we just need communication.
Common sense business instincts I'm glad they're listening.
On Tue, Apr 28, 2026 at 2:42 PM Joshua Angulo González <
@.***> wrote:
<img width="1552" height="728" alt="Image" src="https://github.com/user-attachments/assets/6e5f4c24-dfa6-4886-b258-21c74b082454" />
meet this shit issue again
That's great! I can't wait for this feature to be released!
I don't think 1MB of context is always necessary, but users should still have the option to choose it—especially since it's ideal for professional developers working on large-scale projects.
anybody has an ETA on this?
Codex is ignoring model_context_window because it reads the context limit from the model catalog json, so I copied the original ~/.codex/models_cache.json, changed gpt-5.5’s context_window and max_context_window to 1000000, and in config.toml point model_catalog_json = "loc_of_your_copied_cache.json" and restart the app. bingo
why on earth should they charge a higher usage multiplier when we're burning more tokens and credits either way?
Man! thank you for this - it worked !!
it's not working actually, ive tried
It doesn't really work. Shows 1Million but still says "Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying." after the same point as before. Or am I missing something.
Please update ASAP....
Im cerious to know , if any of you doing any work around (prompts, mcp, other tooling)
for those you argue the 1million context is an issue
I seriously thing that large code bases are what "Tool calling is for". but large context window for have their place I guess
Anyone has got used to it ? anything changed in your workflow?
no one will have to worry about context anymore by the time I'm done.
so this will be a none issue soon!
On Wed, Apr 29, 2026 at 12:43 PM Mahkhmood9 @.***>
wrote:
I fixed it by pinning a local model catalog and disabling remote_models refresh.
-In config.toml I added these:
model_catalog_json = "~/.codex/custom_models.json"
model_context_window = 1050000
model_auto_compact_token_limit = 900000
[features]
remote_models = false
then create ~/.codex/custom_models.json from ~/.codex/models_cache.json, add/update the relevant model entry, and set:
"context_window": 1050000,
"effective_context_window_percent": 95,
"auto_compact_token_limit": 900000
Restart Codex and start a new thread and everything should work smoothly
Try run it to 1 million tokens tell me what happens.
On Thu, Apr 30, 2026 at 3:46 PM Gaius KAYIRANGA @.***>
wrote:
I think we need REAL 400k context.
In fact, very few people actually fill up the model's 1-million context window, not only because of attention degradation and performance drops, but also because there are rarely any tasks that actually require filling it. Basically, our point is that 258k is simply too small. I know you guys are facing capacity pressure, but why not try increasing it gradually?
@2-fly-4-ai I did a run with around 800k tokens... succeeded
yeah i bought a claude code ultra max plus super mega for 1M context and only use codex for auditing
I think your formatting may be a bit off or otherwise garbling your message. But I think I agree, mostly. My tasks often see a multi-day session with a total of 1 billion input tokens, and more than a million output which obviously won't fit in a single 1m token context window. These are subagent heavy, and I do presume the statusline is aggregating the main session with the subagent threads.
While the already shipped context window for codex is working well for me for past few days, what I've consistently observed in the past month or two is that there is a marked improvement in codex's ability to orchestrate multi-day subagent-heavy plans once the useful context window passes 400k output tokens (so, ~500k-550k total). Below that, codex's nearly perfect compaction does still forget some steps and neglect some tasks, and also forgets why it does so.
The way I audit this is that I always have codex commit plan files to disk in the repo as soon as I approve them. On its own, this originally is something I started doing (not a unique invention of mine) for Claude code plans, where claude code's useless compaction means durable plan artifacts have been the ONLY way to actually manage long running tasks forever.
Below that 400k-ish threshold codex does still subtly forget things, and I have to repeatedly re-prompt it to cross check its work against the committed plan, then complete the work it notices it's not yet done. (Unlike Claude code, it can then do it correctly, rather than digging a deeper hole). At around 500k+, codex appears able to stay focused, and keep chugging until done or we encounter a file descriptor leak crash (which I see is supposedly fixed in the next release). It seems to me it's some kind of context thrashing that is relieved around 400k.
The reason I'm especially okay with not having the full 1m, beyond just cost, is that the closer I get to 1m, I find the model doesn't get stupider (as so many are wont to do), but it does get much less predictable and much less behaved. Near 1m, gpt 5.4 would start repeating itself and failing to react to prompts, in addition to the "thought blocking" task stoppages.
if you guys stay patient enough, you'll get UNLIMITED context. mark my
words. don't ask me how.
On Wed, Apr 29, 2026 at 11:25 PM Alexander Riccio @.***>
wrote:
@bolinfest @aibrahim-oai @pakrym-oai @etraut-openai fake 1m context. please consider fixing it ASAP.
not working at all
A simple workaround is to write prompts that require Codex to document the rationale behind code snippets, why they need to be written that way, and even its thought process—similar to Linux kernel project. Codex really doesn't like leaving comments when coding, which honestly isn't a good habit. I believe this approach is effective for large codebases, as it forces Codex to be more careful and precise when making tweaks and trade-offs.
Sorry if my earlier points were unclear. My English isn't very good, so I am using AI translation. As for the formatting issue, that happened because I was trying to quote two different conversations.
Okay so your new issues with chewing tokens are all down to these new limitations imposed.
The difference between me setting to 600k is I can work on a task for a few hours and don't hit the cap for compaction.
With current gpt5.5 settings, I can work for about 15 minutes before compaction.
So every 15 minutes it compacts. Then it chews up tokens quickly and hits a similar compaction issue over and over.
I only have like 1 MCP installed but a large code base. I'm not going to refactor it to meet your latest model standards. It works fine with previous versions of codex and previous models.
This new model is useless to me and tons of other people. We are all using 5.4 again. The new benchmarks don't mean anything if we can't use it effectively.
Such a weird move honestly. Gp5.5 wasn't ready for release. Next time bake and actually release with the context promised. We can all hang on the previous model for a while.
We are used to you guys actually having some standards at this point. When new models drop I'm usually confident to load them up and expect them to work.
At this point you are competing against yourselves.
@tibo-openai
codex team, we need 1m context length for gpt 5.5. people have said it above, but im adding to the conversation bc i need this. i cant be using high reasoning on gpt 5.5, have it do its research and dive into the code, then when it's ready to implement already be at the context length and have to compact everything....this is not productive for me.
id almost rather be back on gpt 5.4 using high reasoning and 1m context length...
Now in addition to a complete and utter regression, they just nerfed the
model. I think openai thinks we're stupid. Now imagine the level of
regression. No 1M context and a nerf. But they all made you hop on the
wagon. Time to go local and ditch these companies who think they can
survive without their users.
On Thu, Apr 30, 2026 at 12:53 PM Kylan Tomita @.***>
wrote:
its not nerfed 5.5 has a different vibe other than 5.4
I still use 5.4 because I like it more
5.4 is not removed
Any update @etraut-openai ?
!Alt Text
Workaround skill until the bug is fixed - not works
<img width="202" height="147" alt="Image" src="https://github.com/user-attachments/assets/d2b9f901-e48a-4aa5-9c30-16eda6f118c0" />
do not do this, this will result in codex running out of context window, as 5.5 in plan/subscription mode has a limit of 400k which includes 128k for output tokens so 272k. anything beyond that will just run into context window errors resulting in terminated sessions
do not do this, this will result in codex running out of context window, as 5.5 in plan/subscription mode has a limit of 400k which includes 128k for output tokens so 272k. anything beyond that will just run into context window errors resulting in terminated sessions
Please don't post "workarounds". They will not work and will result in broken threads that cannot be compacted. This feature needs to be implemented server-side.
@etraut-openai
I noticed that even when it shows
1m, it can suddenly drop back to258kany update when will be fixed?as soon as openai support larger context windows for codex in subscription/plan mode. Other than that you can actually use gpt 5.5 with 1 million context (keep in mind you need to substract roughly 128k of output tokens) if you are using API. However for now, it is not possible to extend the context window in plan/subscription mode in codex. I highly suggest implementing harness engineering in your project to keep the context window small and focused only on the context the agent actually needs.
@ChattyGPT-vm
When I set it to 400k, I can see that 400k works normally and nothing breaks. Auto compact also works; it does not suddenly switch back to 258k like it does with 1m.
It also works even when I change it in the same session and run compact. For example, if I start with 258k, change the files to 400k, and then run compact, it switches correctly to 400k and keeps 400k for the rest of the session.
Yes, 5.5-pro generating results slightly worse than 5.3-codex (at least on complex codebase) is not a degradation but different vibe. OK ¯\_(ツ)_/¯ (sarcasm, indeed it _is_ degradation).
They degraded it. Im using 5.4 and soon enough will entirely switch because
they’re playing funny games. Openai will become irrelevant if they continue
this. People don’t wanna be ripped off and if your business model isn’t
profitable because compute costs are too expensive then you’ve essentially
failed. We shouldn’t feel bad they’re subsidizing. You either have the
product or not.
On Sat, May 2, 2026 at 4:26 PM awn @.***> wrote:
Why don't post if workaround works? My personal workaround: downgrade Codex-CLI to 0.116.0 -- it know nothing abour 5.5 generation of models => it do NOT lobotomize them by system prompt and do not apply 275K cap on context window => it works for me. One drawback -- this workaround will stop work May 8 'cos OpenAI cuts it off :-(
(Of course, I need to edit config.toml manually and understand what I'm doing but... In software engineering it's at all is about knowledge and knowledge what you are doing...)
And I can witness -- non-lobotomized 5.5 with 1M context window is pretty good, it indeed works as adverstized. But... But "official" wrap/shell/harness burns it down to pre-5.3-codex levels while charges still as for full-fledged 5.5. Sorry, but it's feels like a some dirty game. :-(
Now even GPT-5.4 no longer provides a 1MB context, and the CodeX experience feels significantly worse than before.
Guys i promise what’s coming will be monumental. Im addicted and i won’t
even need codex anymore. It’s wild. Sorry gotta rave about this.
On Sat, May 2, 2026 at 5:41 PM di wu @.***> wrote:
I’d also like to see optional 1M context support for GPT-5.5 in Codex.
Can you show your config?
I tried in my pro subs, but auto compact is broken
I would highly recommend against this, as when you are going for 400k token limit you are essentially reducing your output token reserved space to the limit you have set your auto compactation to. So if you have set it to 340k that leaves you with 60 k instead of 128 k for possible output tokens + space to handle the auto compaction. So if you have a big output coming in your prompt, then it will run out of context before being able to provide that. So i would strongly advice against it, allthough it might work with 400k - question is how reliable. Main issue here is that you have to keep in mind the output tokens.
Do you have any fixed schedule for 1M context? @etraut-openai 🙏🙏🙏🙏
"I can't give you a specific timeline yet" seems to be to hard to understand? 🥇
👆🤓 The comment from last week?
It’s fine openai has until my next sub expires and im moving back to
anthropic lol
On Mon, May 4, 2026 at 12:06 PM jugol @.***> wrote:
Yeah, man, it's not worth it. They claim that GPT 5.5 uses less context, but it's literally eating tokens as fast as possible. I think even more than 5.4.
And the funniest part is, in the web interface, it's reversed. It doesn't even think. For GPT 5.4 ( before 5.5 released), if you put it on "Extreme" thinking mode, it was really thinking, but now all models do not even think properly...
Everything's messed up and has become trash from OpenAI...
Had enough computer for x10 rate limits but not for higher context window? 😭
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.
Did y'all just roll something out? My codex just started showing 1m context.
...weird, nevermind
It did show 1M for me and then went back to the standard 258K..
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."
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.
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
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
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.
@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.
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.