Increase effective context window 272000 -> 350000
What feature would you like to see?
Codex effective context window is set at 272k (400k-128k). After applying auto-compaction threshold of 0.95, the users are left with 258k usable context window. In my opinion this configuration is too conservative, and in net effect hurts the experience more than it should. I recommend the effective context window be set at a more sensible 350k.
Codex should perform auto-compaction as late as possible, to improve quality of work on large-context codebases. The current configuration prioritizes unlikely scenario of model returning 128k message in a single turn (not whole response). That's about 6500 lines of code. I believe most people would benefit more having 30% more context window and supporting at most 2500 LoC output (50k tokens) per turn, at the edge of the context. I can't imagine that ever being an issue in the context of Codex CLI.
This would trade off supporting 128k edge case support, for legitimate and broad improvement for users in large-context scenarios.
Additional information
I've been running this patch for about a week now, and the improvements are great. I can't go back to a 272k window now.
Context window: 63% left (130K used / 332K)diff --git c/codex-rs/core/models.json i/codex-rs/core/models.json
index 537a42e27..72e08fe20 100644
--- c/codex-rs/core/models.json
+++ i/codex-rs/core/models.json
@@ -10,7 +10,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": true,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5.2-codex",
"display_name": "gpt-5.2-codex",
@@ -53,7 +53,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": true,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "none",
"slug": "gpt-5.2",
"display_name": "gpt-5.2",
@@ -99,7 +99,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5.1-codex-max",
"display_name": "gpt-5.1-codex-max",
@@ -145,7 +145,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5.1-codex",
"display_name": "gpt-5.1-codex",
@@ -187,7 +187,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5.1-codex-mini",
"display_name": "gpt-5.1-codex-mini",
@@ -225,7 +225,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": true,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "none",
"slug": "gpt-5.1",
"display_name": "gpt-5.1",
@@ -267,7 +267,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5-codex",
"display_name": "gpt-5-codex",
@@ -309,7 +309,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "none",
"slug": "gpt-5",
"display_name": "gpt-5",
@@ -355,7 +355,7 @@
"limit": 10000
},
"supports_parallel_tool_calls": false,
- "context_window": 272000,
+ "context_window": 350000,
"reasoning_summary_format": "experimental",
"slug": "gpt-5-codex-mini",
"display_name": "gpt-5-codex-mini",Showing cached comments. Read the full discussion on GitHub ↗
8 Comments
How was the experience?
Zero issues so far, and the extra 30% context really feels better.
BTW, if someone from OpenAI reads this, I do find the concept of "effective_context_window" redundant and confusing. Can't it just be set to a real 400k and the compaction threshold lowered from 0.95 to mostly equivalent 0.85? I think it would function just the same with less internal logic.
@Zaczero, thanks for posting. The current Codex behavior here is very much by design. Current models are limited to 400k total tokens and can output up to 128k output tokens. This allows for up to 272k input tokens before there's a risk of overflowing the context window. When (not if) such an overflow occurs, an error results, and the session is terminated. That's a very bad experience that we try to avoid. If we were to make the change you're suggesting here, many users would experience errors like this. We don't think this would be a good tradeoff.
You mentioned that you're seeing improved behavior when you increase these limits — that it "feels better". Can you say more about this? Is this just a vibe, or do you have you done a deeper quantitative or qualitative analysis? I've talked with my colleagues on the Codex team, and we're somewhat skeptical that this would result in a noticeable behavioral improvement.
@etraut-openai
And that's the root of the problem. The codex lacks a proper way to handle the end of context, and instead it limits the context window to account for the worst-case scenario.
If it were up to me, I would allow full, unlimited 400k context with a compaction threshold of 0.85. If the end of context occurs, it would automatically undo the last turn (it's a logically non-thinking turn, because thinking doesn't reach up to 128k output per turn), and trigger a compaction.
Most of the cases would be auto-compacted during thinking, at slightly past 0.85. Most of the cases would be auto-compacted after response; most people don't use 128k output in Codex. Only a very small margin of responses would be undone 1 turn and auto-compacted. This would benefit the majority of the Codex user base and provide proper handling for the end of context.
It is common knowledge that compaction is unwanted. There is always degradation of the context, and more time needs to be spent rediscovering it. This not only worsens the UX but also increases API/quota usage.
I believe this single improvement would not only improve long context UX but also decrease costs for users.
---
PS. This explains issues with compaction a little bit more https://youtu.be/3-vSnigQL10?si=FizdoSTqdV6415Ek&t=1606
Codex's compression quality is better than CC and similar tools, but occasionally it restarts from the beginning after compression, even after it has finished executing.
Currently, I'm using operation logs to remember what was done last time, even when a new session is opened. This has been running continuously for almost half a month on a complete project without deviating from the topic, only stopping when the AI stopped and only sending a "continue" message.
If possible, perhaps a compression threshold higher than 350KB could be set. Once the threshold is reached, it could automatically regenerate by reading the log files related to that session ID. This would result in a context size of nearly 400KB, far surpassing the likes of Cloud 4.5 Opus.
However, there's another key point: as the context is filled, the AI's intelligence gradually decreases due to interference. This shows that simply increasing the size isn't always better; "effective context" is necessary.
Of course, these are just my personal, somewhat strange thoughts.
I don't think that's the reason for its existence. Given that all the models have the same effective context formula of (context size - max output size), I bet it's a design limitation of Codex. I'm pretty sure it would work just the same without the effective context logic and with a reduced compaction threshold to account for that.
I'm going to close this because it's unlikely we'd make the change as proposed. It would result in a significant increase in error conditions.
You know you can just fix Codex to handle end-of-context conditions gracefully? You are working against self-imposed limitations.