OpenAI reduces Codex Model Context Size from 372k to 272k
AmazingTurtle
336 points
156 comments
July 19, 2026
Related Discussions
Found 5 related stories in 313.6ms across 14,104 title embeddings via pgvector HNSW
- Codex for almost everything mikeevans · 786 pts · April 16, 2026 · 62% similar
- OpenAI frontier models and Codex are now available on AWS typpo · 213 pts · June 01, 2026 · 62% similar
- Codex for Open Source EvgeniyZh · 28 pts · June 11, 2026 · 60% similar
- Codex reasoning-token clustering at 516 may be leading to degraded performance 0x_rs · 12 pts · July 01, 2026 · 60% similar
- Codex Plugins epaga · 13 pts · March 27, 2026 · 60% similar
Discussion Highlights (20 comments)
dannyw
This was tweeted about when it happened, with some explanation from Tibo here: https://x.com/thsottiaux/status/2076543065045795309
trilogic
HugstonOne increased coding context size, from 1 to 4 Million ctx
cyb3ralbert
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.
bel8
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?
d4rkp4ttern
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
davidkuennen
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.
simonw
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
skerit
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.
ashu1461
I am wondering why the codex repo is open source ? Can they afford it to be open source in the longer run ?
Topfi
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.
damsta
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.
amelius
"272k ought to be enough for anybody"
tekacs
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%.
cmrdporcupine
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.
weeksie
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.
Topology1
Looks like we will be waiting quite a while to see a 1M context window from OpenAI
miranaproarrow
claudes/codex performance suffers after 250k anyway and my workflow reset after every 200 so this is a non-issue
fandorin
Does the context size really matter that much if a “dumb zone” starts around 120k-150k anyway?
aurbxyajwur
5.6 is a mess
hakanderyal
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.