Live data from Hacker News

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

github.com

131–140 of 194 posts

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

#131

Earlier quoted context omitted.

That seems quite different from my design process. I write a plan.md that goes through multiple revisions. The plan is the memory. Restarting and reading the plan again to do another review is a good way to get a different perspective.

I like to actually have hierarchical plans. Start with the big idea. Pin down the product manager-level description, and maybe some details about which features are in or out, how the phased design/roadmap will work, maybe what the basic tech stack will be. That document gets saved, and has the big picture context. Next, we go a little deeper, flesh out schemas, APIs, a little more about what the code should look lik…

I try to do similar. I'll even break down parts of the plan into separate docs and have it solely refer to them one by one as needed with /clear between. It's a more manual process but not the worst. I could probably even whip up some kind of skill to automate it somewhat with subagents or similar.

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

#132

Earlier quoted context omitted.

Claude does the same? It asks you to create new chats (Claude Design) and Claude Code nudges you to start over too, I think `/compact` is optional though?

Claude does the same when you hit the context limit, but the difference is that claude's context limit is 1m and Codex's is 272k now. Claude lets you get a lot more done before you have to worry about the start getting compacted away.

Have you observed any decrease in performance at context higher than 200k?

That used to be one of the major issues why clearing or compacting context when the context nears 150 to 170k is usually preferred.

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

#133
post #93

Earlier quoted context omitted.

Use pi. Can't trust OAI or Anthropic to make good tools.

Claude Code is much nicer than Pi, especially for long running autonomous work. Pi might be OSS but it's just not nearly as featureful or agentic as Claude Code.

I agree, but when it comes to the Pi defaults. I’ve spent a good deal of time (admittedly via vibe coding) writing extensions that completely alter the look/feel as well as functionality of Pi.

I view Pi as similar to NeoVim, both programs have kinda crappy defaults that nobody should really use but are incredibly extensible and customizable for power users willing to invest their time into them.

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

#134

Earlier quoted context omitted.

Claude does the same? It asks you to create new chats (Claude Design) and Claude Code nudges you to start over too, I think `/compact` is optional though?

Claude does the same when you hit the context limit, but the difference is that claude's context limit is 1m and Codex's is 272k now. Claude lets you get a lot more done before you have to worry about the start getting compacted away.

Codex context limit is 400k total, including 128,000 reserved output tokens.

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

#135
post #85

Earlier quoted context omitted.

[flagged]

I did find a strategy, thank you very much, and it was easy: npm uninstall -g @openai/codex && curl -fsSL https://claude.ai/install.sh | bash This was the final straw that got me to downgrade my OpenAI subscription and move the bulk of my spending to Anthropic and Claude code. OpenAI devs, if you're reading, this is how you lost a customer.

[flagged]

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

#136
post #132

Earlier quoted context omitted.

Claude does the same when you hit the context limit, but the difference is that claude's context limit is 1m and Codex's is 272k now. Claude lets you get a lot more done before you have to worry about the start getting compacted away.

Have you observed any decrease in performance at context higher than 200k? That used to be one of the major issues why clearing or compacting context when the context nears 150 to 170k is usually preferred.

Not really, on the project I'm working on right now most of my longer prompts seems to consume somewhere between 300k and 400k tokens (input + output) and I find that both Opus 4.8 and Fable 5 don't seem to get lost with that much context. At least the results still look good to me.

I don't think I've ever pushed past 500k though, it may well fall apart at the higher end of what is officially supported.

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

#137
post #9
post #2

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

To see replies: https://xcancel.com/thsottiaux/status/2076543065045795309 The linked tweet is an unofficial reply to Tibo's official info and Tibo makes a correction in a reply.

[flagged]

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

#138

Earlier quoted context omitted.

I like to actually have hierarchical plans. Start with the big idea. Pin down the product manager-level description, and maybe some details about which features are in or out, how the phased design/roadmap will work, maybe what the basic tech stack will be. That document gets saved, and has the big picture context. Next, we go a little deeper, flesh out schemas, APIs, a little more about what the code should look lik…

I try to do similar. I'll even break down parts of the plan into separate docs and have it solely refer to them one by one as needed with /clear between. It's a more manual process but not the worst. I could probably even whip up some kind of skill to automate it somewhat with subagents or similar.

You can just tell your main agents "I have these implementation docs in , please spawn parallel subagents to implement all of them" and I generally find that works, and what's great is it's in parallel too so takes less wall clock time (even if there is slight token duplication from having the main agent and the subagent both read the prompt/doc, but overall I think it is less usage of tokens unless you go crazy with /clear).

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

#139
post #20

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.

Note that GPT-5.6-Sol is ~2x as token efficient as Opus/Fable, so a 258K max is equivalent to ~516K on Claude models. You also may just be fooling yourself, as context rot is still a problem[1][2] and there's evidence compaction can be equivalent or better than longer context windows for agentic tasks[3]. Obviously it would be best if the models could reason over 1M context like they do over 256K context, but they can't yet.

[1] https://arxiv.org/abs/2605.12366 [2] see F1 of GraphWalks 256K vs 1M in Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f... [3] https://context-folding.github.io/

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

#140
post #26

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 whe…

The fact there is no way to disable auto-compaction and no way to go back in the conversation history to before a compact makes codex a no-go for me on any codebase > 5kloc. Even worse it seems to fire randomly at 10-20% of context left. So really you have 80% of 272k as real usable context. Compaction kills my sessions, it hallucinates and is worse than starting fresh. I've had enough times screaming at my computer…

So the practical workaround is to set model_auto_compact_token_limit very near, but still below, the model’s context window. This postpones compaction rather than disabling it.

config.toml

  model_context_window = 27000
  model_auto_compact_token_limit = 17000
  model_auto_compact_token_limit_scope = "total"
Post reply on HN