NHacker Next
  • new
  • past
  • show
  • ask
  • show
  • jobs
  • submit
OpenAI reduces Codex Model Context Size from 372k to 272k (github.com)
tekacs 5 hours ago [-]
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%.

voxgen 23 minutes ago [-]
Pay attention to what it forgets, and start telling it to proactively note down those things into nominated files while it works, e.g. indexing topics covered by each chapter/section/page of each paper/material. GPT-5.6 is really good at finding context again, if given the smallest hint where to start looking.

You can also ask it to read your past sessions, find places where it was wrong after compaction, and figure out a strategy to persist the most important summary information.

I have several Hermes threads that have each had >10 compactions with a 200k context limit, and with the right instructions on note-taking, they require at most a "double-check that against our past decision records" to be put back on track after a slip-up.

jubilanti 2 hours ago [-]
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 when it burns tokens on a large codebase, gets to 15%, auto-compacts, and hallucinates so bad it has to read the entire codebase agin, gets to 15%, auto-compacts....
volker48 30 minutes ago [-]
Have you tried using another harness like Pi? You can easily turn off auto compaction and if you leave it on you can use /tree to go back before the compaction if you like.
p1esk 2 hours ago [-]
Maybe instead of screaming at your computer come up with a better context management strategy?
Kye 41 minutes ago [-]
This would have been a great opportunity to suggest one.
rcarmo 25 minutes ago [-]
Depends on what you are using. I have been experimenting with various compaction techniques in piclaw (https://github.com/rcarmo/piclaw/blob/main/docs/pipelined-co...) and Codex has native "opaque" server-side compaction at a dedicated OpenAI endpoint.
skybrian 5 hours ago [-]
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.
jmalicki 9 minutes ago [-]
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 like, the overall testing strategy. This document gets saved, and the AI can reference it for context.

The next level is a very specific implementation plan. Think individual small JIRA tickets in an epic. The AI writes this based on previous context. I make sure each individual step has very explicit instructions about branch names, which branch is branched from where, the testing and documentation that will be done for that step. It should be obvious from the higher level documents, but that helps keep the AI to only worrying about the local document in its context window.

Then have a DAG of stacked pull requests designed for subagents to work through.

All of this keeps the context window down (as well as costs down, and accuracy up) and works super well, and I can get a tremendous amount of code that is easy to review through stacked PRs. Invariably I will want to fix earlier ones then percolate that down the stack, so I have some skills for that.

Sammi 3 hours ago [-]
So far I have three different folders in my project for three different types of md documents that I keep creating and revising together with the agent: reports, plans, and reviews

Every large feature has at least one of each file created for it in that order. I start by analysing stuff and making reports that might also contain design thinking and decisions. Once I'm satisfied we have properly analysed and thought though whatever it is we're working on then I might make a plan or just jump into implementation depending on how complex the issue is. And then I might have zero or multiple reviews of different kinds by different agents depending on how much verification I think the issue warrants.

This is my super simple worse-is-better development process. I make up what is needed on the spot.

tekacs 4 hours ago [-]
I have these plan files as well, but it depends on the scope and scale of the things you're executing on, I think. However much detail gets put into the plan, it still doesn't help if part of what the model needs to understand is the fine-grained / perfect detail of a large surface area.
skybrian 2 hours ago [-]
That sounds more monolithic than modular, but I guess some projects don’t decompose easily? Or maybe they do, but getting there is the goal.
planckscnst 5 hours ago [-]
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

tekacs 5 hours ago [-]
I've implemented a similar approach – although I'm surprised not to see mention of cache prefix busting in there!
planckscnst 2 hours ago [-]
I did calculations on the prefix cache effect on costs of sessions where I used it and found that the removal of tokens from context had a much bigger effect on reducing costs than cache busting had on increasing them. I should re-do that and publish it.
jeremyjh 3 hours ago [-]
Yes the idea is cool but this could really hammer usage, especially just leaving it up to the agent to decide when to do it. I'm not surprised though, considering the github account is named "Vibecodelicious" and became active in December.

Poking around in the repo the whole implementation is an unsupervised LLM fever-dream.

planckscnst 2 hours ago [-]
It depends on what you mean by "unsupervised" - I've been strictly working through the agent, through specs the entire time, but it's been very supervised, I just leave the mistakes in-place and have it work from there.

However at this point it can completely maintain itself. When a new version of Claude or OpenCode is released, it updates itself to work on the latest version. It can also add new implementations for harnesses pretty reliably. It's actually pretty fun to watch it at this point. "Make this work on Hermes agent and message me when you're done" and an hour later or so, I can go play with it in Hermes.

adyavanapalli 4 hours ago [-]
This is actually brilliant. I've seen other approaches where the context is selectively pruned, but never in a recoverable way.

P.S. Love the "bonsai" name btw!

znnajdla 4 hours ago [-]
I have a hunch that OpenAIs proprietary compaction endpoint actually does something similar on the backend.
tekacs 4 hours ago [-]
When I've asked Codex agents about things that were in their context window, they've never – to my experience – been able to actually retrieve something from before compaction when using the proprietary compaction endpoint. Instead, they've had to consult their actual transcript.

So... at least as of a week ago or so, I don't believe so.

ethin 2 hours ago [-]
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 usually gotten better results with it, but it falls a part the moment you try doing something like that that's really complicated and requires a ton of different attempts to get it right.
jmalicki 3 hours ago [-]
Instead of compaction, I very aggressively do everything with teams of subagents. The main agent keeps the high level context, and all of the nitty gritty detail and code details not needed by the main agent never even make it into the context.
thejazzman 3 hours ago [-]
This used to be really effective and cheap, now it lights my quota on fire, even after I fix the config and restore smaller subagents instead of like-agents

Multiple (slow) conversations seems to be the efficient path for me the past week or so

ljm 3 hours ago [-]
How does that work out in terms of usage? I imagine that, unless you're on the highest tier subscription or have a no expense spared approach to agentic coding, then you're going to hit a wall pretty fast.
jmalicki 3 hours ago [-]
It's actually less token usage overall, since the gigantic context that builds up in the main agent is a huge driver of costs.
QuantumGood 1 hours ago [-]
Compaction is a feature like swapping out a car for a tricycle is a feature for greater economy.
azuanrb 3 hours ago [-]
Curious, what kinds of tasks do you do that require such a large context window? Anything specific?
serf 2 hours ago [-]
for me it's often codebase decomposition.

it's hard to modularize a monolith without keeping large chunks in context at first pre-delegation; the orchestrator -- however you implement it -- needs to carry as much of the original thing as possible into context and big monoliths make this task heavier.

so, tl;dr : I use a lot of tokens re-writing legacy codebases that were constructed with very little CS training in some huge spaghetti fashion by random people around the world.

eagerpace 4 hours ago [-]
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.
tekacs 4 hours ago [-]
That isn't really a way around it for the kinds of things I'm talking about. The whole point is that getting all of the relevant context to even orchestrate it takes up most of the model's 272K.
jmalicki 3 hours ago [-]
For those kind of tasks, I do hierarchical planning, and then parts of the plan can focus one agent on keeping a smaller amount of pre-determined context when orchestrating.

Think: A VP of engineering has some super high level goal: "build a new product to beat our competitor in this new market". It then filters down and various levels of reports build more and more detailed yet more narrow pieces of planning/orchestration. They don't make it work by keeping all of the context in their head and micromanaging.

whearyou 4 hours ago [-]
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
thih9 5 hours ago [-]
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?

tekacs 4 hours ago [-]
Yep, Max. I would definitely struggle to code with Anthropic's plans on Pro.
MattRix 1 hours ago [-]
If you want stuff to be referenced regularly, why are you doing it in the conversation instead of just putting the documents in the directory and referring to them in AGENTS.md or whatever?
reinitctxoffset 1 hours ago [-]
You can mad customize it if you're willing to set up like, oh my pi or whatever.

I didn't quite get it tuned up enough to be a daily driver but I'm basically sure it can be hotrodded however you want. It comes out of the box with like four different vendor hostile compact strategies, including compacting into images at the smallest size Claude can read, which the "coding is basically solved" geniuses conveniently leak the resolution heuristic out of their website along with all the other side channels they print for the MSS.

yearolinuxdsktp 3 hours ago [-]
If you’re using the pi.dev harness, I found this tool to be quite good as a compaction alternative: https://pi.dev/packages/pi-blackhole — it keeps a memory so every prior conversation piece is recallable, not lost.
scotty79 2 hours ago [-]
OpenAI compaction is very different than Anthropic compaction, especially in 5.6

I use GLM5.2 and gpt-5.5 and 5.6 and never noticed any quality degradation near the limits of the context or due to compaction.

serf 2 hours ago [-]
>I use GLM5.2 and gpt-5.5 and 5.6 and never noticed any quality degradation near the limits of the context or due to compaction.

that's because you and your workloads probably fall into a bucket of users where compaction is tuned well.

but the reality is that those processes need to pick what to carry over, and that's a tough thing to get right for everyone, so for me compaction is a signal to restart the session or to tell the LLM to reference existing design docs lest we go off the rails.

large context limits is one of the things that make the open model competitors very attractive to me.

nojito 3 hours ago [-]
Why arent you using /goal?
troupo 3 hours ago [-]
> The lack of long context is the main reason that I still end up using Anthropic.

Anthropic's "long context" is mostly marketing bullshit. It semi-reliably holds about the same amount of info, and then starts suffering the same issues.

dannyw 7 hours ago [-]
This was tweeted about when it happened, with some explanation from Tibo here: https://x.com/thsottiaux/status/2076543065045795309
causal 8 minutes ago [-]
Am I dumb or does this chart make no sense? Or why does the line only go up even with compaction? Or maybe "overall trajectory size" is hiding some meaning I don't understand?
imgyuri 2 hours ago [-]
How can the overall trajectory length be the same across reasoning efforts? I don't see how this is possible even if reasoning is not included in the trajectory length calculation.
mkl 6 hours ago [-]
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.

2 hours ago [-]
damsta 5 hours ago [-]
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.
jubilanti 2 hours ago [-]
The fact there is no way to disable auto-compaction like every other coding harness makes me scream. It fires randomly at 10-20%, so really you now only have guaranteed context of 272k * 80%. So many times I've had it work on a large codebase, it is almost done with a task, it needs maybe a 2000 token response, but it drops below 20%, it churns and churns and churns and then I see the dreaded ``Context compacted`` and scream. You can't go back in the history to the state of the conversation before the compaction. So then it has to investigate the codebase again gets to 20% and then auto-compacts. So it then has to read more, and then auto-compacts again, and then I'm out of tokens.
n4te 1 hours ago [-]
Use pi. Can't trust OAI or Anthropic to make good tools.
iugtmkbdfil834 5 hours ago [-]
Full agreement. I sincerely hope that reducing token is mostly a cost saving measure and not some roundabout way to get more token use. It still does not help. In my corp, bean counters rendered initially useful internal llm largely pointless as they severely limited context.

I swear there is a executive convention out there sharing worst practices.

Sammi 3 hours ago [-]
Just use md files for working memory. No need for large context. LLMs get dumber as you put more in context, as it stretches their attention. Keeping context small is better for quality.
throwatdem12311 1 hours ago [-]
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.
davidkuennen 7 hours ago [-]
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.
embedding-shape 6 hours ago [-]
> I never felt that context size was any issue at all in codex.

I'm guessing you just started using codex, it suffered greatly from "model context size exceeded" errors early on, where compaction couldn't even recover from it, these errors just stopped happening maybe some month(s) ago.

Nowadays it's a lot better though and I've don't get stuck in those anymore. Although I don't like the idea that they don't surface what goes into the "concise summary" afterwards, make it really hard to know if it actually got everything important or not.

In general, codex seems to be moving into the way of hiding as much from the user as possible, and it wouldn't surprise me if they eventually start encrypting the entire session logs just like they did with agent>sub-agent prompts recently. Sad though as it's easily the best harness+model combo available today out of the ones I've tried.

cmrdporcupine 5 hours ago [-]
Claude also had issues with this kind of thing for months early on, too, where it simply couldn't compact its own emissions.

But definitely earlier GPT models suffered greatly as context got large, and the compaction itself in Codex was really crappy. That changed around January.

throwuxiytayq 6 hours ago [-]
For me, Codex regularly forgets to complete its last task when compaction occurs, especially when the last message I sent was right before compaction.
dbbk 6 hours ago [-]
It seems odd to me that Codex doesn't carry the plan file through context compaction? Claude does this, it re-reads it in full from disk
efromvt 5 hours ago [-]
I’ve noticed it having weird message dropping and replay in general, but the compaction boundary has been pretty solid.
formerly_proven 3 hours ago [-]
Most problems should be divide-and-conquerable into chunks that 300 vs 400k context is basically never an issue. A coding agent isn't an infinite chat.
KronisLV 2 hours ago [-]
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.

bel8 7 hours ago [-]
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?

SwellJoe 6 hours ago [-]
Nobody does caching as well as DeepSeek, so I guess it's a big enough difference in the implementation to make it difficult.

If you use Reasonix with DeepSeek it gets silly, as it is append-only to work with how caching works. It gets something like 97-98% cached tokens in a long session. It makes an already cheap model even cheaper.

skerit 6 hours ago [-]
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.
brandoncarl 3 hours ago [-]
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]

conradkay 1 hours ago [-]
It's not quadratic attention, you get that curve from the input tokens going up linearly, since the graph is measuring cumulative cost at each token count. Basically for y=5 it's 5+4+3+2+1, or f(x) = x(x+1)/2

https://pbs.twimg.com/media/HNFc4Dma8AA76FW.jpg?name=orig

Topfi 6 hours ago [-]
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.

fandorin 4 hours ago [-]
Does the context size really matter that much if a “dumb zone” starts around 120k-150k anyway?
conradkay 1 hours ago [-]
Things change fast! For Fable 5 it definitely feels past at least 272k
fandorin 1 hours ago [-]
hmm, what about other models?
d4rkp4ttern 7 hours ago [-]
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

tekacs 5 hours ago [-]
You can run ’codex debug models' into jq!

I forget whether it's documented or not, and it is kind of annoying that that's how you find it, but it does tell you. Maybe useful for the future if nothing else.

spongebobstoes 5 hours ago [-]
it's in the GitHub repo
weeksie 5 hours ago [-]
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.
miranaproarrow 4 hours ago [-]
claudes/codex performance suffers after 250k anyway and my workflow reset after every 200 so this is a non-issue
Topology1 4 hours ago [-]
Looks like we will be waiting quite a while to see a 1M context window from OpenAI
simonw 6 hours ago [-]
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
tekacs 5 hours ago [-]
https://github.com/tekacs/fast-rm

I've overridden my rm with this, which I threw together for fast-deletes of things like Rust target/ directories, and after seeing the GPT horror story, I taught it to flatly reject deletions directly under `/` and under home directories, with a message printing the path that it's trying to delete.

Not exactly a perfect mitigation, but given that the stated risk was the model mistakenly using the wrong $HOME, it seems like a reasonable safety. I should probably make it use an even scarier rejection notice, though.

I also... have backups.

Razengan 6 hours ago [-]
That's ok, if AI deletes my home directory I can just ask AI to regenerate my home directory.
AmazingTurtle 6 hours ago [-]
This happened to me one time. On windows though, deleting C:/ lmao. The direction I'm heading now is a better harness, i.e. isolating codex at a container level with dedicated workspaces / mounts etc. I'm building something at the moment that serves my needs.
monster_truck 3 hours ago [-]
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
hakanderyal 3 hours ago [-]
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.

yearolinuxdsktp 3 hours ago [-]
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 using a structural index/graph and not grep. Every time the agent missed it, I asked it how to improve the rules. Eventually, I asked the AI to review that rule file and it rewrote it to be 30% smaller, but, crucially, structured to be more understandable by the LLM.

Another helpful thing was to ask AI to review my rules for things it can load on-demand when it works in that area.

trilogic 7 hours ago [-]
HugstonOne increased coding context size, from 1 to 4 Million ctx
quotemstr 3 hours ago [-]
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.

noname120 2 hours ago [-]
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.
quotemstr 1 hours ago [-]
Perhaps not this for this parameter, but for others? Client side.
ashu1461 6 hours ago [-]
I am wondering why the codex repo is open source ? Can they afford it to be open source in the longer run ?
simonw 5 hours ago [-]
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.

Topfi 5 hours ago [-]
What do you mean “afford”?
aurbxyajwur 4 hours ago [-]
5.6 is a mess
amelius 5 hours ago [-]
"272k ought to be enough for anybody"
trilogic 5 hours ago [-]
Thats not even enough to read a simple codebase, how is that enough?
sokoloff 3 hours ago [-]
Almost certainly an homage to “640kB ought to be enough for anybody.”

https://quoteinvestigator.com/2011/09/08/640k-enough/

trilogic 1 hours ago [-]
That is a good point actually (this is how we at Hugston measure tokens, in bytes). 270k tokens should be around ~1100kb or 1 MB, so not really enough for a serious project.
4 hours ago [-]
cmrdporcupine 5 hours ago [-]
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.

rotariuvladimir 18 minutes ago [-]
[dead]
robkam 4 hours ago [-]
[flagged]
greenoracle9 3 hours ago [-]
[dead]
nttylock 6 hours ago [-]
[flagged]
cyb3ralbert 7 hours ago [-]
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.
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact
Rendered at 18:11:13 GMT+0000 (Coordinated Universal Time) with Vercel.