Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 194 posts

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

#31

Post by planckscnst »

tekacs wrote: 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 agree. Compaction sucks, so I made tools that let the LLM selectively delete (and recall if needed) chunks of its context. You might want to try context bonsai if you're routinely hitting the auto-compaction wall.

https://github.com/Vibecodelicious/context-bonsai-agents

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

#32

Post by spongebobstoes »

d4rkp4ttern wrote: post #6

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

it's in the GitHub repo

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

#33

Post by tekacs »

planckscnst wrote: post #31
tekacs wrote: 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 agree. Compaction sucks, so I made tools that let the LLM selectively delete (and recall if needed) chunks of its context. You might want to try context bonsai if you're routinely hitting the auto-compaction wall. https://github.com/Vibecodelicious/context-bonsai-agents

I've implemented a similar approach – although I'm surprised not to see mention of cache prefix busting in there!

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

#34

Post by thih9 »

tekacs wrote: 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…

What plan are you on?

With Anthropic I run out of quota very fast on a Pro plan with long contexts.

Is long context primarily for Max tier or for API usage? Or are there special ways of working with long context on a Pro plan?

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

#37

Post by skybrian »

tekacs wrote: 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…

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.

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

#38

Post by znnajdla »

planckscnst wrote: post #31
tekacs wrote: 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 agree. Compaction sucks, so I made tools that let the LLM selectively delete (and recall if needed) chunks of its context. You might want to try context bonsai if you're routinely hitting the auto-compaction wall. https://github.com/Vibecodelicious/context-bonsai-agents

I have a hunch that OpenAIs proprietary compaction endpoint actually does something similar on the backend.

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

#39

Post by eagerpace »

tekacs wrote: 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 best way around this for me is planning a project well ahead of time and using subagents to execute individual tasks while the primary agent acts as a PM.

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

#40

Post by whearyou »

eagerpace wrote: post #39
tekacs wrote: 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 best way around this for me is planning a project well ahead of time and using subagents to execute individual tasks while the primary agent acts as a PM.

I haven’t found I need to plan way too far ahead of time as long as I’ve defined the interface between the tasks
Post reply on HN