OpenAI reduces Codex Model Context Size from 372k to 272k

I know a lot of people like to say that compaction makes this moot, but the level of detail you lose across compaction is wildly too much for most things that I do, unfortunately.

Perhaps if your plans don't have as much detail, or if you're not, for example, having a discussion with a lot of nitty-gritty then it's fine?

The lack of long context is the main reason that I still end up using Anthropic.

The worst is when you need it to hold for example a number of papers in its head, or large and complex materials that it needs full resolution on and your context window ends up being perennially at 16%. You have about five minutes of conversation and it compacts and then you have to wait for it to read that again, get to 16%... and repeat.

372 was not perfect, but it was so much better and a godsend. It turned that 12 to 20% into more like 40%.

Big context windows made everyone lazy about deciding what actually deserves to be in there... compaction makes it worse, it's lossy compression applied to everything at once so the details you actually needed probably get lost. I always thought that retransmitting the full chat every turn is a foundamental problem... in my experience with conversational agents I clear the context every turn and reinject all the relevant info with a memory/context plugin I built myself, so small context stopped being a problem cos the model reads a few k of curated state instead of 200k of scrollback. Coding agents are harder and I haven't cracked that part, but in my opinion the real fix to the context problem is in this direction: a policy that keeps what's needed to finish the job or to do the next job and drops the rest. This can be achieved with a separate LLM specialized for exactly that.

I don't know if this is why they did it, but I think it is generally a mistake to go beyond this context size anyway.

I don't think people realize how much dumber the models get at larger contexts and how much more the token cost is. I never let claude get about 300k and in general I don't compact, I just divide up the work in chunks where I can fit it into 300k and I try to keep really clean and slim docs and modular code bases.

It's still kind of annoying, sometimes the larger context is useful for one time tasks, but I think if you are regularly going beyond 300k you are losing a lot and probably have a poorly designed code base.

This was tweeted about when it happened, with some explanation from Tibo here: https://x.com/thsottiaux/status/2076543065045795309

Not a fan of their context compaction and I feel like 1M-token context should minimum today. Each day I see how GPT 5.5 and 5.6 struggle a bit after each compaction before they get to the full speed, sometimes focusing too much on some older steering message that made it into the compacted context.

I primarily use Opus for my day to day and I /clear often. 1M context sound great but it quickly degrades once you start hitting the 50% mark. I usually just /clear once I hit between 30 and 40 percent context and get much better results from the model. Compaction doesn’t really help much in my experience, starting fresh and having the model front load its context from scratch works much better IME. I have multiple skills with a pile of markdown docs organized by feature to assist in that first load by telling it where to find relevant information for the task. Works great.

I never felt that context size was any issue at all in codex. I don't know how their compaction works, but it just keeps on going as if it has no context limit at all. At least in my experience.

I have over the last two months switched to OpenAI from Claude since it’s been vastly better for my cases. Wonder if I see any difference in the quality of the output with this change

No matter how good compaction is, on some big projects it needs to read a lot of files. In my experience the first 200.000 tokens go FAST, but after that it slows down. Most of my Fable sessions don't go over 500.000 tokens, I don't need to compact once. But when I use Codex a single session has to compact over and over again.

That's quite small for my workloads.

I try to keep it under 200k but my DeepSeek and MiMo sessions can sometimes grow to 350k tokens when I try to squeeze one last iteration I compact.

Can't OpenAI copy DeepSeek K/V cache tech (from published papers) to make it super cheap?

I didn't try long coding sessions for a while. I had really noticeable performance degradation with all models above 100-150k and always try to stay below those numbers.

On long sessions even with workflows and sub-agents I typically hit around 500-750k tokens in context (say 4-16 hours of work in a session, across multiple 5-hour limits) with Claude Code.

I was going to explore paying for Codex since OpenAI seems to be a bit more generous with rate limits, but I'm now not sure - for the stuff I do limited context size would be a dealbreaker - basically lots and lots of documentation and guideline references, code review loops, documentation references and web searches, multi-repo exploration, lots of tool calls and so on.

I might just upgrade to Anthropic's more expensive Max subscription or something to get more subsidized tokens. Even with plan files and the plan mode, it's like a slot machine after compacting the context, sometimes steps or other details just evaporate in thin air, the less of that I need to do the better. It's not that it can't work, it just doesn't work reliably enough not to be annoying.

Luckily DeepSeek V4 Pro, GLM 5.2 and Kimi K3 don't seem to have those limits either - though DS is around Sonnet, GLM 5.2 feels a bit above Sonnet and only K3 only really is in the proper Opus ballpark that's good enough for me to work undisturbed, even if it seems to be slower.

This is a shame, and hopefully it reverts soon. I switched from Claude to Codex just before the Fable release because Claude doesn't follow instructions and goes off the ranch too frequently. I really don't want to have to switch back to what I consider to be a fundamentally worse model.

With purely quadratic attention, the cost of the token at 372K is 87% more than the token at 272K.

There are attention mechanisms that help to mitigate this, but you can clearly see in the chart that Tibo posted that the attention mechanisms they are using are still scaling quadratically.

This becomes an optimization problem for token t:

min f[cost, quality loss] = compaction cost[t] + compaction quality loss[t] + token cost[t]

Good move given some experienced issues and compaction across the 5.6 range is closer to 5.4 than 5.5, i.e solid and reliable.

Will say that 5.6-Sol is a minor bump in my benchmarks in most areas vs 5.5 but a severe regression in a few specific task focused on rearranging trees, addressing merge conflicts, etc. where the model to accomplish the task does not properly adhere to prompts in a way GPT-5 originally managed, not retaining parts of history in the way prompted despite specific instructions not to as that made the final completion easier…

I am of the conservative and cautious opinion that no model should be able to run destructive tasks at all, I have seen every model do things that make me concerned enough to maintain that opinion and know my evals can’t catch everything. But for 5.6-Sol specifically, I’d caution everyone to reevaluate how you run the model, maybe take a few more precautions you tend to forgo.

It is extremely capable as a reviewer and for extensive tasks, though for the later, the safety net I feel is required to be comfortable limits the utility. The code 5.6-Sol provides also still is a bit harder to parse in reviews.

Release strategy wise, feel it’s have been smarter to release only Luna and Sol now, then Terra a few weeks of posttraining later, I simply cannot see a purpose for it in the current form given how well both Luna and Sol scale up and down respectively with reasoning. Two models from a lab at a time is also the limit I feel one can properly assess at a time.

The other day I was trying to find out exactly how much context size 5.6 has in codex CLI (via subscription) and I didn’t find that documented in any of the obvious places. Sort of ridiculous that we have to find this out in X or Reddit, e.g:

https://www.reddit.com/r/codex/s/hVv29obfFD

Does the context size really matter that much if a “dumb zone” starts around 120k-150k anyway?

I haven't used Codex in some time, but in Claude Code I force my context size down to 280k on purpose as in my experience your best work is done within the 30-250k~ range regardless of a models maximum context size.

claudes/codex performance suffers after 250k anyway and my workflow reset after every 200 so this is a non-issue

Looks like we will be waiting quite a while to see a 1M context window from OpenAI

This was done because they were charging the 100%/50% premium for long-context over 272k to Codex users, even though they set 372k as the default. It cost people a LOT of money.

HugstonOne increased coding context size, from 1 to 4 Million ctx

I have rule files that guides the agent towards my coding standards, code style, house rules etc. They alone cost 60-80k tokens, and they are the backbone of my system that prevents slop. Pre 1M context, I had to build complicated tooling to re-include the relevant docs to the context upon compaction, which relied on unstable transcription file format, which was a pain to maintain. With 1M context I deleted all of those. Nowadays most of my sessions uses 300-450k context.

Another thing that's preventing me from trying Codex. (the other is @ referencing files not auto including them to the context)

1M should be table stakes for frontier models at this point for programming.

Another interesting change in that commit is the addition of this section to the system prompt:

  Before taking a destructive action:
  
  - Make sure the action is clearly within
    the user's request.
  - Resolve the exact targets with
    read-only checks when necessary.
  - Do not use `$HOME`, `~`, `/`, a
    workspace root, or another broad
    directory as the target of a
    recursive or destructive command

Looks like the fix for this bug where Codex would occasionally accidentally delete your entire home directory: https://twitter.com/thsottiaux/status/2077630111499882637

Codex is open source. You can build it yourself. You don't have to use upstream's parameter choices, compaction strategies, subagent heuristics, or whatever. Strange how people act like tweaks to these parameters are mandates when they're really just suggestions relayed to you via git.

For example: upstream recently changed the effort level hotkeys so M-. would stop at xhigh, not max. If you want max, upstream, you go to the /model menu. I didn't like this change, so I undid it locally. Easy peasy.

I am wondering why the codex repo is open source ? Can they afford it to be open source in the longer run ?

Codex compaction is really quite good. Smaller context doesn't really harm me.

I had a /goal running last night for 9.5 hours straight while I slept. When I woke up in the morning it was fully on task and focused.

Write up a detailed design doc. Build a decent AGENTS.md, and write up a good prompt or /goal.

Long context can be more of a curse than a benefit sometimes anyways.

If ChatGPT 5.6 is so good why do they continue to have the same motherfucking cache and usage issues that they were struggling with when 5.2 is new? Could not pay me to use this shit. Enjoy your reset bingo

"272k ought to be enough for anybody"

[flagged]

[flagged]

[dead]

[flagged]

[dead]

[dead]

Context size cuts like this are usually a cost/latency tradeoff rather than a capability one - serving a smaller window is cheaper and keeps latency in check, and most sessions probably don't need anywhere near 372k tokens anyway. Curious if this affects people who were actually relying on the larger window for big codebases.

5.6 is a mess

You just need good compaction and a memory system with decent project layout and documentation. If you don't have that 1M tokens won't really save you either.