I’m at 272K and I’m hoping there’s some way to increase it. Compaction really confuses the hell out of it sometimes. Thanks!
Yes, you can lose some detail on compaction.
The trick is to maintain state in a file of some kind.
That way even if facts are lost via compaction a persistent file is available to review.
For example I created a temporary md file to track sub features of a larger feature, what was completed and what was left to do.
That’s great advice!
I keep running into this issue myself, so I often spawn new threads from the main thread or use subagents for individual tasks where the entire job is completed. This works well when I know the detailed context won’t be needed later.
It’s another way to work around the current limitation. We can build and maintain a memory and context layer while actively keeping the main thread focused and free of unnecessary noise.
Yeah, I’ve started doing this and having it write readmes or now it just kind of decides to write into .codex/TASK.md for whatever reason and then after compaction it will automatically re-read. It’s great!
Hi PixelGames - I saw your follow-up about using READMEs or .codex/TASK.md so Codex can re-read project state after compaction.
Has that held up reliably in longer projects? I’m curious what still falls through the cracks - for example decisions or constraints that never make it into the task file, or the file itself getting stale.
And do you mostly maintain that state manually, or has Codex become reliable enough at keeping it current for you?
I wouldn’t rely on TASK.md alone for a long project.
It works well for keeping track of what’s done, what’s next, and the current state after compaction, but the things most likely to get lost are usually the reasoning behind decisions, important constraints, and assumptions that seemed obvious at the time.
A setup that seems safer is to separate the state a bit:
TASK.mdfor current work and progressDECISIONS.mdfor important technical decisions and why they were madeCONSTRAINTS.mdfor things Codex should not change or forget
I’d still review those files occasionally rather than trust Codex to maintain them perfectly. Automatic updates are useful, but once a wrong or outdated assumption gets written into the state file, Codex can keep carrying it forward after every compaction.
So for me, the bigger issue isn’t really increasing the context window. It’s making sure the important context survives outside the conversation.
Thanks, this is useful. How often do those files actually need correction in a longer project? I’m especially curious about the last concrete time you found a stale or wrong assumption in them before Codex carried it forward. And roughly how much manual review does keeping TASK.md / DECISIONS.md / CONSTRAINTS.md trustworthy take in a normal week?
Since I see this thread got necro’d I figured I’d add the instructions as it may help someone.
Open ~/.codex/config.toml and add or update these settings before any section headers:
model = “gpt-5.6-sol”
model_context_window = 1000000 <---- choose your context window value up to 1m
model_auto_compact_token_limit = 900000 <---- set this to ~90% of the context_window value
I’m moving this from questions to a small practical test. If you’re comfortable sharing a sanitized or representative TASK.md / DECISIONS.md / CONSTRAINTS.md set from a real longer project, I’d like to audit it for stale assumptions, conflicts and state that is no longer supported by the underlying project. You can strip anything sensitive. I’ll send the findings back rather than pitch you anything.
Larger context is possible with supported models, but the setting must match the model and client. Codex also has an optional experimental context-management feature on eligible Plus/Pro setups: https://learn.chatgpt.com/docs/models. Keeping reviewed task, decision and constraint notes remains useful. We’ll pass along the remaining compaction-reliability feedback; no guaranteed lossless recall.