Increase effective context window 272000 -> 350000

[Zaczero]

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",

[812913329]

How was the experience?

[Zaczero]

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.

[etraut-openai]

@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.

[Zaczero]

@etraut-openai

When (not if) such an overflow occurs, an error results, and the session is terminated.

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.

Can you say more about this?

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

[812913329]

@etraut-openai

当（而不是如果）发生这种溢出时，就会产生错误，并且会话将被终止。

这就是问题的根源。法典缺乏处理上下文结束的恰当方法，而是限制了上下文窗口以应对最坏的情况。

如果由我决定，我会允许完全、无限制的 400k 上下文，压缩阈值为 0.85。如果上下文结束，它会自动撤销上一回合（逻辑上来说，这是一个非思考回合，因为思考每回合的输出不会达到 128k），并触发压缩。

大多数情况会在思考过程中自动压缩，压缩率略高于 0.85。大多数情况会在回答后自动压缩；大多数用户在 Codex 中不会使用 128k 的输出。只有极少数的回答会在一轮后被撤销并自动压缩。这将使 Codex 的大多数用户受益，并为上下文结束提供适当的处理。

您能详细说说这方面的情况吗？

众所周知，压缩是不受欢迎的。它总是会导致上下文信息丢失，需要花费更多时间重新获取信息。这不仅会降低用户体验，还会增加 API 和配额的使用。

我认为这一改进不仅可以改善长时间使用时的用户体验，还可以降低用户的成本。

PS：这段视频更详细地解释了压实方面的问题：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.

[Zaczero]

"effective context" is necessary

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.

[etraut-openai]

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.

[Zaczero]

You know you can just fix Codex to handle end-of-context conditions gracefully? You are working against self-imposed limitations.