Support Optional 1M Context for GPT-5.6 in Codex (Follow-up to #19464)

What variant of Codex are you using?

The latest version of the Codex App through a ChatGPT subscription. Since the same server-side context limits also apply to other Codex clients, this request is also relevant to the CLI and IDE Extension.

What feature would you like to see?

This is a feature-request follow-up to #19464, which I filed in April for GPT-5.5.

The original issue is still open, but the discussion has been locked. On April 27, a Codex maintainer gave a very encouraging response:

"We're working to make the 1M-token context available for gpt-5.5 in Codex."

The maintainer also said that the team was making this a priority, although capacity planning prevented them from committing to a specific timeline.

GPT-5.6 has now been released, but the optional 1M context requested in that issue still has not become available with my Codex subscription.

In my current Codex client, GPT-5.6 provides approximately 353K of effective usable context before compaction. That is only about 95K more than GPT-5.5.

Meanwhile, OpenAI's official API model comparison page states that GPT-5.6 itself has a 1,050,000-token context window and supports up to 128,000 output tokens:
https://developers.openai.com/api/docs/models/compare

I understand that providing the full long-context capability inside a subscription product carries a high serving cost. I also understand why the current smaller window may be a reasonable default for most users.

But this is the central point I was trying to make in April: a reasonable default should not become a hard limit that no user can choose to exceed.

A clean, reproducible scenario that reaches the limit before the real work begins

I am using Codex for a long-running, in-depth study of a very large private codebase under strict instructional requirements.

This is not a normal workflow where I ask one isolated question about one file. Throughout the learning process, the model must maintain a precise knowledge boundary: which concepts have already been taught in full, which terminology has been established, which earlier explanations were corrected by the source code, which invariants have been proven, and which prerequisite knowledge the next source-level explanation is allowed to assume.

Before beginning the next stage, the model needs to load three large prerequisite materials.

A detailed teaching and auditing specification.

Two previously completed execution-chain study documents based entirely on the real source code.

I tested this process in a completely fresh Codex thread.

The only task I gave that thread was to read those prerequisite materials in full. At that point, I had not asked the first real learning question. The model had not started inspecting the next source function, tracing a new call path, or producing the first explanation.

After this loading-only task was complete, Codex showed that approximately 303K of context had already been used.

That is about 86% of the approximately 353K effective context available to GPT-5.6 in Codex. The actual learning work had not begun, yet only about 50K remained before compaction.

This 303K figure is not a static estimate produced by passing the files through an offline tokenizer. It is the end-to-end context usage shown by Codex itself.

Reading these materials is itself an agentic process. The model must decide how to inspect them, issue tool calls, receive tool results, understand the relationships between the documents, and gradually establish the working state required for the next task.

Whatever the exact internal breakdown may be, the final observable result is very clear.

Start a completely fresh Codex thread.

Ask it only to read the prerequisite materials required to continue the work.

Finish loading them with approximately 303K of context already used.

Approach automatic compaction before asking the first real question.

This is the practical bottleneck I am trying to describe.

These materials are not merely "prerequisite knowledge," and they cannot be safely replaced by a compacted summary

These materials are not logs that can be discarded after reading, nor are they optional reference files.

The teaching and auditing specification defines the execution contract for the entire learning process: how detailed the explanations must be, how conclusions must be established from the real source code, how many new concepts may be introduced in each round, how terminology must remain consistent, when the model must continue tracing into child functions, which historical mistakes must not be repeated, and how the model must determine the user's current knowledge boundary.

The completed study documents also do much more than preserve the prerequisite knowledge needed to understand the next stage.

They are a knowledge base, preserving parameter meanings, call relationships, state invariants, cross-file dependencies, and corrected conclusions that were previously established from the source code.

They are a record of the knowledge boundary, explicitly distinguishing concepts that have already been taught in full, concepts that have only been mentioned, and concepts that must still be introduced from the beginning when they appear later.

They are also gold-standard examples that future explanations must follow. They demonstrate the explanation density, organization, source-citation style, concept-introduction method, line-by-line level of detail, state-snapshot format, and teaching rhythm that have already proven effective for navigating complex call chains clearly and naturally.

This distinction is extremely important.

Even if a compacted summary preserves which general subjects were previously studied, it is unlikely to preserve the many concrete presentation patterns, organizational choices, and explanatory details contained in those gold-standard examples. The model not only needs to know what should be explained next; it also needs to see how previous material was explained in a way that the user could genuinely understand.

These documents are therefore prerequisite knowledge, behavioral specifications, and demonstration examples at the same time. Their details are active inputs to the next task, not historical background that can be safely collapsed into a few paragraphs.

A compacted summary may preserve the broad topics, but it cannot fully preserve every source-level fact, correction, relationship, terminology decision, teaching constraint, and gold-standard example detail that remains relevant.

This is the difference between saying "Codex has excellent compaction" and saying "compaction can replace the original context."

Codex's compaction is genuinely very strong, and I appreciate it. Among comparable tools I have used, Codex already does an excellent job of organizing long threads and continuing from them.

But any form of compression that shortens the original information must make tradeoffs. It cannot become a truly lossless replacement for the original context.

In this learning scenario, the details removed during compaction are not obsolete conversation history. They are prerequisite knowledge, behavioral rules, and demonstration examples that the next stage still directly depends on.

If I must ask Codex to reread all prerequisite materials after every compaction, then compaction has not actually solved the context problem. It has interrupted the task and forced the same materials back into the window.

There is an even more immediate problem in this test: as soon as the prerequisite materials finish loading, the thread is already approaching compaction. The model barely has enough space to begin the next source-level lesson before the knowledge it depends on is compressed again.

This problem is not limited to specialized learning workflows

I do not think the statement that the current context window combined with good compaction is usually sufficient for normal coding tasks accurately reflects my real experience.

With GPT-5.5, Codex provided only about 256K of effective usable context. For me, the experience was very poor.

GPT-5.5 triggered compaction extremely frequently during even moderately long coding tasks. Although Codex's compaction is already strong, repeated compaction still caused the working state established earlier in the task to be lost over time.

In real development work, I frequently encountered situations where the model forgot the local development environment and device conditions that had already been confirmed, forgot the project's actual build, packaging, installation, or verification process, forgot approaches that had already failed and repeated the same attempts, forgot constraints or invariants that needed to remain consistent across multi-file changes, or retained the broad direction of the task while losing the critical details required to complete it.

This does not mean that Codex's compaction implementation is poor. On the contrary, the fact that these problems remain even though Codex already handles compaction very well demonstrates the underlying limitation: no matter how strong the compression is, it cannot be truly lossless.

While using GPT-5.5, I had to switch back to GPT-5.4 for almost every moderately heavy task so that I could rely on its previously configurable larger context window to finish the work.

This meant that although I subscribed to and wanted to use the latest frontier model, I could not consistently benefit from its capabilities in genuinely complex tasks. GPT-5.5 was an upgrade in model capability, but its smaller practical context window made it very difficult to replace GPT-5.4 in my core workflows.

GPT-5.6 increases the effective window to approximately 353K, which is an improvement, but it only postpones the same structural problem slightly. It does not actually solve it.

Why this still forces me to use Claude Code

Claude Code handles these workloads relatively comfortably.

With Claude Opus 4.8, I often allow the active context to approach 800K before I compact manually. I do not compact because I can already feel a clear decline in model capability. In my real workloads, its long-context recall remains very strong. I usually compact because I become psychologically cautious about how large the thread has grown.

Even after compaction, I still ask Claude Code to reread all required prerequisite documents because I do not believe that any summary can fully preserve every detail needed for the next stage of source-level study.

I actually do not want to keep comparing Claude Code with Codex, because GPT-5.6 is already the model I prefer and most want to use over the long term. But one point is difficult to ignore: in my Claude Max subscription, the current main models can use 1M context directly. I do not need to buy a separate long-context tier, nor do I need to accept a separate pricing scheme just to open the full window. Different models naturally consume subscription allowance at different rates, but 1M context itself is already treated as a normal part of the model capability.

This has changed what I expect from a frontier coding model. For long-running coding tasks that need to preserve a large amount of working state, 1M context no longer feels like an extravagant experimental feature. It feels more like the room a model needs to complete its work with confidence.

I mention Claude Code not because I want Codex to simply copy another product. On the contrary, it is precisely because I prefer GPT-5.6's capabilities and communication style, and because I am more willing to trust Codex, that this limitation feels especially disappointing. The model I most want to use has to compact earlier, while the tool I would rather reduce my reliance on can keep the full working state.

Even if Codex needs to charge a higher usage multiplier for larger context because of capacity constraints, I am willing to accept that. I simply hope I will not have to keep giving tasks I would rather entrust to Codex to other products because of the context window.

This is why I know the problem is not simply "token anxiety." There are real workflows where preserving the raw prerequisite context directly produces more reliable and continuous results.

At present, this limitation means that I have to choose Claude Code rather than Codex for these tasks.

That is especially unfortunate because I genuinely love GPT-5.6.

Compared with GPT-5.5, GPT-5.6 communicates in a way that feels significantly more natural, easier to understand, and more like speaking with someone who genuinely understands my intent. It is better at understanding what I am actually trying to say and at explaining complicated subjects in a more human and approachable way.

This natural, understandable, genuinely human communication style was one of the reasons I previously liked Claude Opus 4.8 so much. GPT-5.6 has made a very noticeable improvement in exactly this area.

GPT-5.6 is the model I most want to use for these tasks, but the context limit prevents me from truly moving the work back.

I currently maintain two Codex subscriptions at the 20x usage tier and one Claude Max subscription at the 20x usage tier. I am not making this request as a casual user asking for unlimited free compute.

Codex is genuinely my preferred product—one that I use long-term and actively support. Rather than splitting my most important work across multiple tools, I would prefer to entrust complex, long-running, genuinely important tasks to Codex.

That is not only because I like the current model capabilities and product experience. I am also more willing to place my trust in Codex's long-term direction. I believe the Codex team can ultimately make these advanced, long-running, autonomous workflows work extremely well.

If Codex offered a sufficiently large optional context window, I would be much more willing to continue concentrating my heavy workloads, subscription spending, and long-term working habits around Codex.

The current situation is the opposite of what I want: Codex is the product I most want to use, but some of my most important tasks force me to move to other products because of the context limit.

The feature I am specifically requesting

Please allow advanced users to choose a larger context window for GPT-5.6.

One reasonable implementation could be:

Keep the current context window and compaction behavior as the default.

Offer genuinely larger optional context tiers, such as 800K or the full 1.05M.

Allow users to select the tier through Codex settings or a server-authorized model_context_window configuration.

Charge a clearly disclosed higher usage multiplier for larger context windows, similar to the capability-versus-usage tradeoff already offered by Fast mode.

If capacity is limited, initially make the option available only to users who meet specific subscription, usage-tier, or account requirements.

Clearly display the selected total context, effective input budget, output reservation, and corresponding automatic-compaction threshold in the client.

GPT-5.6 already provides approximately 353K of effective input context in Codex. Merely adding a nominal 512K tier would therefore not meaningfully solve the problem described here.

What would genuinely help these workloads is the ability to move into a clearly larger context tier, such as 800K or the full 1.05M, while accepting the corresponding additional usage cost.

I am fully willing to spend more quota for a larger context window.

This is not a request to give every user 1M context by default, nor is it a request for OpenAI to provide unlimited long context for free. The core of this request remains user choice.

Ordinary workloads can continue using the current, more resource-efficient default. Advanced users working with large codebases, long architectural plans, deep debugging sessions, multi-file refactors, or large amounts of prerequisite knowledge should be able to choose to preserve more raw context and accept the higher quota consumption.

The previous maintainer responses also made clear that client-side configuration cannot work around this limit, and incorrect client-side adjustments may produce broken threads that cannot be compacted correctly. This therefore needs to be implemented as an officially supported server-side capability.

An additional thought about capacity and higher-tier subscriptions

If full long-context access is genuinely difficult to provide within the current subscription tiers, I also hope OpenAI will consider offering an optional, higher-end Codex subscription for the small number of extremely heavy professional users.

For example, a significantly more expensive professional tier—even one priced at $500 or $1,000 per month—could still provide real value to users like me if it included a larger configurable context window, higher sustained usage, and capacity guarantees better suited to long-running agentic workflows.

This is not a suggestion to raise the prices of existing plans. Those plans should continue serving the vast majority of users.

I simply hope that when the base plans cannot support these high-cost workloads, OpenAI can offer an additional option genuinely designed for heavy professional users, rather than making "switch to another product" the only available solution.

The exact price and plan structure should, of course, be determined by OpenAI based on real capacity. My point is simply that I am willing to pay more for higher-tier Codex capabilities that genuinely resolve these workflow limitations.

Please reconsider making GPT-5.6's full long-context capability available as an optional feature inside Codex.

GPT-5.6 has become the model I most want to use over the long term. I do not want the context limit to remain the reason I must give my hardest and longest-running tasks to other products.

Additional information

Original feature request: #19464

Maintainer update stating that 1M context was being prioritized:
https://github.com/openai/codex/issues/19464#issuecomment-4329299628

Maintainer clarification that the capability requires server-side implementation:
https://github.com/openai/codex/issues/19464#issuecomment-4364763432

Final maintainer update before the original discussion was locked:
https://github.com/openai/codex/issues/19464#issuecomment-4392401037

Official GPT-5.6 API context specification:
https://developers.openai.com/api/docs/models/compare

I am opening a new GPT-5.6-specific feature request because the previous discussion has been locked and the original issue was scoped to GPT-5.5. I am completely comfortable with the two issues being linked. My goal is to provide up-to-date real-world data following the release of GPT-5.6, along with an end-to-end workload that demonstrates why the original request remains unresolved.