Live data from Hacker News

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

github.com

191–194 of 194 posts

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

#191
post #24

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

Not much point making it closed source at this point, coding agent harnesses are trivial to reverse-engineer. Being open source was also a useful community lever they could pull when they were trying to catch up with Claude Code.

[flagged]

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

#192
post #84
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…

I suffered this same problem with Anthropic, ironically. Mainly with reverse engineering things. That would usually end up requiring a ton of context it had to remember, and then compaction would kick in and it would just forget half of it (that half being really important too), and even switching to Claude Code and having it document everything wouldn't really fix the problem. It was honestly quite sad because I've…

[flagged]

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

#193

Earlier quoted context omitted.

Not true. Try to increase the context window and you will be greeted with an error when you reach the real limit enforced server-side.

Perhaps not this for this parameter, but for others? Client side.

Apart from the local scaffolding you can configure very few parameters, and the ones you can configure are the ones that don’t matter

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

#194

Earlier quoted context omitted.

Try running your rule files through an LLM for optimization. 60k-80k tokens is massive. Funnily enough, most anti-slop skills I found are both way too verbose and miss some common slop constructs. I also reduced many rules from “When doing X, don’t do Y, but do Z.” Instead, the rule is “When doing X, do Z.” Fewer tokens and often works better. I had one critical rule I was maintaining about searching the codebase usi…

It’s optimized to death. Every word, every comma. I have a rule file for writing rule files. Problem stems from using my own abstractions instead of common frameworks. For a full stack session, backend + front end + docs about the part we are working on adds to that amount. I’ve accepted it because it results in code exactly the style I would’ve written. It’s a good tradeoff to cut off the slop.

Fascinating! I am glad you’re getting good results with that. Maintaining abstractions is critical and it’s very frustrating when the LLM ignores them.
Post reply on HN