🚨 [SEVERE REGRESSION] GPT-5.6 Sol context cut again: 353K → 258K despite advertised 1.05M
What version of Codex CLI is running?
codex-cli 0.144.3
What subscription do you have?
Paid ChatGPT-authenticated Codex subscription. Exact tier is redacted for privacy because the catalog/runtime regression is not account-specific.
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Linux x86_64. Exact host and kernel details are redacted because they are unrelated to server-delivered model metadata.
What terminal emulator and version are you using (if applicable)?
Codex desktop/CLI environment. Local application and project identifiers are redacted.
Codex doctor report
Not included to avoid publishing machine, account, path, repository, and runtime metadata. The relevant sanitized version, model-catalog fields, and runtime values are included below.
What issue are you seeing?
Summary
Codex has silently reduced the usable context window for gpt-5.6-sol again.
The previous server-delivered Codex model catalog exposed:
{
"context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95
}That produced a 353,400-token effective runtime window:
372,000 × 95% = 353,400The current freshly fetched catalog now exposes:
{
"context_window": 272000,
"max_context_window": 272000,
"effective_context_window_percent": 95
}Codex therefore now reports only 258,400 effective tokens:
272,000 × 95% = 258,400This is a further 95,000-token / 26.9% reduction from the already restricted 353.4K Codex window. It is not UI rounding. Sanitized historical runtime records repeatedly report model_context_window: 353400 before the rollout and model_context_window: 258400 afterward. No local model_context_window or auto-compaction override is configured.
Issue #31860 already documented that the earlier 353.4K Codex cap was far below the published GPT-5.6 Sol model specification. This report covers the new and materially worse regression from 353.4K to 258.4K.
The official GPT-5.6 Sol model page still advertises:
- 1,050,000-token context window
- 922,000 maximum input
- 128,000 maximum output
Source: https://developers.openai.com/api/docs/models/gpt-5.6-sol
At the same 95% effective-window policy, the advertised model would provide approximately 997,500 usable tokens. Codex now exposes only 258,400, or 25.9% of that comparable effective capacity.
Why this is unacceptable
This combination is infuriating: OpenAI advertises a 1.05M flagship model, initially restricts it to 353K in Codex, and then silently cuts it again to 258K. Paying users are left with more compactions, lost working context, disrupted long-running tasks, and no advance notice or explanation.
This feels dismissive of paying users and materially undermines trust in Codex as a professional development tool. Repository-scale analysis, long-running implementation work, multi-agent coordination, large specifications, and tool-heavy sessions all depend on stable context capacity. Context size is not a cosmetic setting that can be silently reduced by another 26.9%.
The pricing situation makes this even more frustrating. The same official model page states that requests above 272K input are priced at 2× input and 1.5× output for the full request. Codex now caps the raw window at exactly 272K, so users cannot even choose to access the published long-context tier through Codex.
To be precise: this report concerns the Codex product limit under ChatGPT authentication. The pricing comparison refers to OpenAI's published API long-context policy; it demonstrates that long-context capacity exists and is explicitly priced, while Codex prevents access to it.
Major competing platforms already offer 1M-class context:
- Google documents Gemini models with 1M or larger context windows: https://ai.google.dev/gemini-api/docs/long-context
- xAI documents a 1,000,000-token window for its flagship Grok 4.3: https://docs.x.ai/developers/models/grok-4.3
- Anthropic documents a 1M context option for Claude Sonnet 4: https://docs.anthropic.com/en/docs/about-claude/pricing
A flagship coding product limited to 258K effective context is no longer competitive, especially when its underlying OpenAI model is publicly specified at 1.05M.
What steps can reproduce the bug?
- Run Codex CLI
0.144.3with the official OpenAI provider and ChatGPT authentication. - Select
gpt-5.6-sol. - Ensure there is no local
model_context_window,model_auto_compact_token_limit, provider, or project override. - Fetch or refresh the server-delivered model catalog.
- Inspect the sanitized
gpt-5.6-solcatalog entry. - Observe
context_window: 272000,max_context_window: 272000, andeffective_context_window_percent: 95. - Start or continue a thread and inspect token-usage metadata.
- Observe
model_context_window: 258400. - Compare with earlier sanitized GPT-5.6 Sol thread records, which report
model_context_window: 353400.
The transition was observed on 2026-07-13. Old and new values briefly overlapped across existing and newly started threads, consistent with a phased or cached server-side catalog rollout.
What is the expected behavior?
- Codex should expose the full published 1.05M GPT-5.6 Sol context window, with a clear effective input/output reserve.
- If a product-specific cap is unavoidable, it must be prominently documented before users select the model.
- Context limits must not be silently reduced for existing or new paid-user workflows.
- Active threads should retain the context contract under which they were started.
- Users should be allowed to opt into the published long-context tier when they accept the associated usage or pricing impact.
- As an immediate stopgap, restore the previous 372K raw / 353.4K effective Codex limit while full 1.05M support is implemented.
- OpenAI should explain why the context was reduced, whether the change is temporary, which plans/surfaces are affected, and how usage accounting interacts with this cap.
Additional information
Related reports:
- #31860 — GPT-5.6 Sol was already capped at 372K raw / 353.4K effective instead of the published 1.05M.
- #29039 — a GPT-5.5 thread changed from 1M to 258K mid-thread.
- #30910 — request to restore 1M context support.
Privacy note: this report intentionally excludes account identifiers, thread IDs, repository names, local paths, prompts, transcripts, and exact machine metadata. Only model metadata and aggregate context-window observations required to reproduce the regression are included.
27 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
im furious about this and so sick of OpenAI doing this crap. People were happy and then Boom, back to the same crap that we were struggling with before on 5.5. But now with the 5.6 sub-agent drain and just fast drain in general, we are auto-compacting like freaking crazy and that causes so many issues. Put it back to the 370k at a minimum. It's practically unusable now and just burns tokens having to compact and reanchor constantly. I'm spending all my tokens on resets because OpenAI won't give us a bigger window. Its a waste across the board.
as things go, you cant have 5,000 tokens window, I dont think you need more than 290K-tokens
I assume some can benefit off it - if you are missing 5..5 , it still exist its a very good model --- it actually seems to gotten a lot faster as most users now use 5.6
OpenAI does not treat users as human beings.
The only question is :
why OpenAI didn't issue any notice or explanation when they reduced the context window.The only reason:
I don't carewuah, I dont think anyone could expect a 3x times user increase, I have a lot of heavy usage still and I use the weekly package
but honestly I dont know what to say for people who complain about ratelimits , and context window
as per context window , I dont expect anything to have understand and go for to long from a short prompt
how much context window do you need 10million context window? a 15million context window? 70 million context window?
you are going to hit limits fast and not feel the fruits of higher context window, compacting is just to get to the "core intent of things"
you dont need a lot of words and slop , you just need to be more efficent ---
I personaly like to view your prompts as maybe too short, maybe you need to break it to more prompts with the models
as things stand now maybe we need a 60k tokens window, maybe 250k is too much still --- in what ways we actually benefit from it ---
is it more creative? Is it more truthful to the prompts you gave it?
look there are maybe some other issues you are facing that might be existing -- and maybe the context window is in the wrong direction--- if the context window would have stay 370k --- clearly we are limited by hardware and datacenters --- maybe it save on VRAM or RAM --- or even the transfering of massive amounts of DATA , or coper wire running
as things are now, im surprise openai didnt see a majour outages left and right --- so some how the launch was successful --- despite the 5 hours limit being nerfed
I personally think the smaller models are made for a reason --- you actually need to account to each context token, its not like you saved some 2gb file on your ssd and you access it on demend --- its a very different thing
@Lady-Lin I know the llm can get a bit weird if you talk to it in Chinese or anything that is not English --- so again maybe you are facing another issue
let me ask you it this way... What bloats the context window?
the only argument you can make , is that you need to reload the same context tokens , over and over after you recomacted something
and you know you can easily replace the skill of which can be making code, to hammer the llm with prompts--- I think subagents===could have served another user
but I dont say do not have you should try everything, and give effort for a lot of new ideas --- I just dont see it happening against the biggest issue in computing in 30 years --- I just hope, we see a semiconductor moment like a moorse law moment on the power grid it self....
you know nvidia sell any of those server racks for like 7million dollars after a discount, and you still need to buy real estate --- and even with all of the luqidity and debt in the world -- you are limited by space , and believe me nvidia want to sell as many gpus as they can with or without discounts (also on another note, I dont see why you need more than 4gb on a personal computer ,, part of what make gpus cool , is also vram so you got a debicated chip for computer grapchis , and it also has vram --- so a computer on a pci express --- thats another computer... there is also google which also knew to invest in the TPU, of which can almost equal in preformance, but not in efficency--- I think the strength is what they dont need to support and thats why I think they can even compete --- they are many good people working just on the compilers for tpus for example why it actually able to deliever,,, think how in image editing ,,, how it comes very natrually --- barely 2 years after ,,, ML model are able to take an object and seprate/segment it from the background --- and also label the segmented parts into what they generally mean -- for example the best video generation is still sora2 , in terms of concepting voices objects movements , and we are a 10 months after the sora2 release --- and still nothing competes with it --- sticking a an avarge tts is cheating speaking of investments a lot of what google cant do, seems to be maybe limits of the tpu dspite on papers being a matrix multipcation machine ,, anything google does is a group of models it seems , not a one big thing -- like you assume other labs doing )
so sad. I was really making good use of 353k.. now reduced to 258k :(
you missing the point it doesnt mean a whole lot - the reality is 5.6 is a better model. but you might be dispointed because you can reach limits faster
. . .
I dont think any of the languages able to interpute languge and intent in something that isnt english, what has changed from 5.5? a product we all enjoyd,
if you see a "regression" its with the model not the
context windowI personally its good they limit very slightly - without a serious other regression, because I personally assumed this is the lightest regression you can afford to have, because changing models in the backas things goes , moorse law died with the rtx4090 series , the RTX 5090 , is only a 33% improvement -- which does in fact reflect where the optiomzation in the server hardwares are.
WOW！
Thanks for taking the time to reply; it seems like this really struck a nerve with you.
Let me respond to that as well.
In reply:
Your comments give me the impression that you are particularly skilled at "prompt engineering"—which is a good thing. If possible, please share how you manage to complete massive development tasks effectively within a 258k context window.
Oh，可能我用中文跟你对话会更好。
感谢你花费时间来回复，看来你好像被这个刺激到了。
那我也回你一下。
回复：
1.上下文里面不只有你输入的提示词，还有代码
你的发言让我感觉你好像特别擅长“提示词工程”，这是好事儿。如果可以，请你分享一下如何在258k的上下文里面最大程度的完成巨大开发任务。
Coding agents are not great with anything that isnt english its a fact --- you yourself try to switch to Chinese-toEnglish-Tochinese-toenglish
you assume "CoT" or "Reasoing" bypasses it and make it smooth , because humans dont think in long sentences but reason --- but its not the case
they are bad with forgein languages , do you prompt with anything that isnt english?
I see it the exact opposite way. LLMs operate based on coordinates, yet linguistic semantics often share similarities—and code is a form of language, too. The sad part is that there is no code based on the Chinese language.
### What we are discussing is:
So, do you still think we are discussing software development?
Explained here https://www.reddit.com/r/codex/comments/1uuz4dg/inference_optimizations_have_landed_resulting_in/
Ok i see . let’s look forward to OpenAI making the 1M context window available in the near future.
If you interact with it in chinese, you observe more token use? Until it lands where you want?
I think it has to do with how the models train with english ,
think about it this way , a word/sentence can mean few things. and its very hard tracing chinese world to its mean in english --- and even if the model gets what you want in chinese, it has to the CoT in chinese no?
if you interact with it in chinese or english , you observe it geting longer or not?
I only interact with the models in English.
if people use the model and its good , the only way things going to happen , the people will use it more and more , I am not saying its a language-type/“语言类型” issue
in some way you say chinese is very good, because you compact a lot of meaning in small amount of letters and words -
it does influence what the model think is your intent or not for being truthful to what you ask it -- it does depend in which language you used
even if you use the /plan, its still going to be a mixture of English + Chinese , if you prompt was chinese, because of system card / personality
or whatever
I dont know how to CoT works with the gpt models , but I assumed this does increase the context window ....
COUNTER ARGUMENT
if compacting was so good, we would compact it in each turn... after each message the model sends we compact what it said - but its not the case as its a bad idea.....
all I am saying I think it has to the with the ways models are trained to be good at evals, and for example Github / Code evals a lot of the issues are only in english
if you were to translate the evals prompts to chinese, and run the evals this way
the eval results would be lower on 0-shot
mark my lips
also thanks for responding to my messages, and thank you , you argue with me with this --- because thats how good debate should have with arguments and counter arguments
No we do not discuss software developement , but I discussed with the influence of non english languages (partly due to the way I think they are trained)
what are you talking about? Obviously if people like myself do long horizon heavy semantic cross-synthesis work then context window is a very important part since the auto-compaction eats up a ton of it. So when compaction happens in a 20% window, then after compaction you're back around to already losing at least 10%, then that means 30% is gone right away. That means we only get a 70% usage window. Long horizon heavy semantic work to operate properly requires a certain level of controls to keep in place. These projects require efficient routing and often also require larger agents.md files and re-anchoring. So you can assume at least another 15% of that window is gone just there. That leaves around 55% remaining for actual work. So cutting 120k+ token usage window is a massive hit when you are running sequential tasks that cannot be treated like code revisions. And simply sharding sub-agents still requires a certain level of contextual handoffs depending on the tasks. You must not do long horizon cross synthesis work. And don't forget, every time we have to do an auto-compaction and reanchor. Dude you're obviously a troll just talking crap to argue with people. These are legitimate complaints people have. Nobody is saying we don't like the technology or the software. Obviously we do. But we don't like being given something then randomly stripped of it because it impacts workflows and reconfiguring protocols. Stop trolling and either provide helpful feedback to contribute to solutions or ways to improve on the complaints instead of just arguing to argue with people that are obviously upset.
He didn't provoke me at all my friend :D, ; I was simply curious as to how someone with absolutely no understanding of the underlying operational mechanisms of LLMs could still go on GitHub and lecture others.
That kind of confidence piqued my curiosity about their country and people. .....
Sometimes I think I can accidently reply on a message --- honestly I dont know , I am using Luna-Medium , for a simple message it consume like 1.2million tokens , after checking with the /usage
but granted it did beautifully made what I wanted it to do , and those 1 minute would took me 9 hour to do -- and I fail often on tasks
This discussion eventually turns itself to racism, interesting.
Im korean, its normal between koreans and chinese people
You gotta admire the effort OpenAI puts into making all their products way worse when they could fix it in 10 minutes.
I personally I thikn they should move to a 2d limit -- if you reach a 5d limit (e g you bloated your usage on SOL, next you get a simular usage out of luna-medium)
as per gpt 5.7 maybe we are not going to see a huge improvement , maybe its all they got in 5.6 -- its honestly just the tip of the iceberg in how efficent the models gonna be!
If within the 6months we gonna see 10x improvement,
we are seen the see the next generation of chips which will have 10x infrence like LPX GROQ by NVDIA (which is delayed it seems)
for example tpu aim to solve design flaws , gpus used to have, but now they are on the same level if not better
10x the improve in future hardware
10x the improvement in models
I dont believe in improvements anymore, its gonna be the same as with every product nowadays: cutting cost (-> lower quality) and rising prices. If they get better models, they will make them smaller instead and quantizing it (in marketing speach: "inference Optimization"). Benchmaxxing will still make it look good, so the 95% vibe coders with their generic websites and pointless button apps with oneline prompts are satisfied, thats enough for them, while the 5% of people doing real projects are ignored. How else can you explain 258k context, thats hilarious! With the codex system stuff, MCPs, project rules, overview, and ai agents instructions (even with a good instruction system and splitted tasks in single files for every task/ai working package) it already uses half of the context. Thats a big regression for large projects.
you dont understand, simple task still need 10 tool calling STILL they are not perfect --- for now they reach evals
all of this beautiful hardware in those datacenters , SHALL SERVE 20X the users