🚨 [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,400

The 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,400

This 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.3 with 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-sol catalog entry.
Observe context_window: 272000, max_context_window: 272000, and effective_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:

[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec #31860 — GPT-5.6 Sol was already capped at 372K raw / 353.4K effective instead of the published 1.05M.
Context window changes from 1M to 258K mid-thread #29039 — a GPT-5.5 thread changed from 1M to 258K mid-thread.
Reopen #19464 and support 1M context #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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Effective context window shrank down to 250k in win app #32803
[Critical][Codex App] GPT-5.6 Sol is catalog-capped at 372K (353.4K effective) vs the 1.05M model spec #31860

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 care

@Lady-Lin

wuah, 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 window I 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 back

as 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:

The context contains more than just the prompts you input. but code too
The context consists of more than just your inputs. but output too
By attempting to attribute this issue to the "language type," I believe you are unfairly disparaging OpenAI's GPT models.

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.上下文里面不只有你输入的提示词，还有代码
2. 上下文里面不光有输入，还有输出
3. 你试图把这个问题归咎于“语言类型”，我认为你在抹黑OpenAI GPT Sol模型。

你的发言让我感觉你好像特别擅长“提示词工程”，这是好事儿。如果可以，请你分享一下如何在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?

how big are your prompts,

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:

OpenAI does not give users control over their own token usage; particularly with massive tasks, compression can sometimes be triggered by the input alone.
OpenAI reduced the context window from 385K to 258K via a minor update, without notifying users anywhere.

So, do you still think we are discussing software development?

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)
2. I did argue we cant have a too much of a small context window but not too big
3. Im trying to support your argument , with the idea its pointing to other issues

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

fix(context): one GPT-5.6 context window, Anthropic-only 1M detection…

fix: claudex の context window を 872K に引き上げ、feedbackDrafts を off にする (#…

Map all four GPT models across the Claude tier slots

Navigation Menu

Repository navigation

🚨 [SEVERE REGRESSION] GPT-5.6 Sol context cut again: 353K → 258K despite advertised 1.05M #32806

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

Summary

Why this is unacceptable

What steps can reproduce the bug?

What is the expected behavior?

Additional information

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

🚨 [SEVERE REGRESSION] GPT-5.6 Sol context cut again: 353K → 258K despite advertised 1.05M #32806

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

Summary

Why this is unacceptable

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 13, 2026

eah3699 commented on Jul 13, 2026

Mahkhmood9 commented on Jul 13, 2026

Lady-Lin commented on Jul 13, 2026

Lady-Lin commented on Jul 13, 2026

Mahkhmood9 commented on Jul 13, 2026

GiGurra commented on Jul 13, 2026

Mahkhmood9 commented on Jul 13, 2026

Lady-Lin commented on Jul 13, 2026

Mahkhmood9 commented on Jul 13, 2026

Lady-Lin commented on Jul 13, 2026

Lady-Lin commented on Jul 13, 2026

4 remaining items

Mahkhmood9 commented on Jul 13, 2026

Mahkhmood9 commented on Jul 13, 2026

eah3699 commented on Jul 13, 2026

Lady-Lin commented on Jul 14, 2026

Mahkhmood9 commented on Jul 14, 2026

hooyao commented on Jul 14, 2026

Mahkhmood9 commented on Jul 15, 2026

VolkumDev commented on Jul 18, 2026

Mahkhmood9 commented on Jul 18, 2026

Mahkhmood9 commented on Jul 18, 2026

DrBiggusDickus commented on Jul 18, 2026

Mahkhmood9 commented on Jul 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions