We want 1M context #28852

Core request

As Codex users, we want GPT-5.5 in Codex to expose 1M effective context.

GPT-5.5 is the flagship model users expect to rely on for complex engineering work in Codex. We choose GPT-5.5 not only for stronger single-turn reasoning, but because we expect it to sustain long-running, multi-file, multi-stage agentic coding workflows.

OpenAI's own GPT-5.5 release post says GPT-5.5 in Codex is available with a 400K context window, while the API path for GPT-5.5 has a 1M context window:

https://openai.com/index/introducing-gpt-5-5/

The GPT-5.5 API model page also lists a 1,050,000 context window:

https://developers.openai.com/api/docs/models/gpt-5.5

So GPT-5.5 has a 1M-context capability path, but Codex currently does not expose that capability fully to users.

That is the core request of this issue: please let GPT-5.5 in Codex expose 1M effective context.

This is not a request for the community to design OpenAI's internal implementation. From the outside, users cannot know whether the current limit comes from the service layer, model routing, account policy, client behavior, model catalog, prompt construction, or the compaction pipeline. That is OpenAI's responsibility to diagnose and solve. Users care about the practical outcome: whether GPT-5.5 in Codex actually provides the long-context capability expected from a flagship model.

Real user experience

GLM-5.2 was released very recently, and I have been deeply testing its 1M-context behavior in complex engineering scenarios.

In the same or very similar complex engineering tasks, my real-world experience is that GPT-5.5 in Codex is far less stable than GLM-5.2. I do not believe the main reason is that GPT-5.5 is inherently weaker as a model. The main reason appears to be Codex's effective context limit and the frequency of context compaction.

The advantage of GLM-5.2 is not that it can simply stuff a little more chat history into the prompt. The advantage is that, in long-running tasks, it can keep carrying forward the engineering context: requirements, constraints, architectural tradeoffs, code evidence, rejected approaches, execution path, and verification results. Once that information is compressed too early, the model starts losing the real shape of the task.

In contrast, Codex GPT-5.5 enters context compaction too often during complex engineering work. The worst case is that even a brainstorming session may need compaction before the discussion is finished. At that point the key context is not yet stable, and compaction directly causes information loss, semantic distortion, or later execution drifting away from the original discussion.

This feels like a self-imposed handicap. GPT-5.5 has a 1M-context capability path, but Codex exposes a smaller effective context and then relies on frequent compaction to keep the session going. The result is that the flagship model cannot fully express its capability in real complex scenarios.

Why 1M context matters for coding agents

For serious agentic coding, context is not ordinary chat history. It is the working memory of the task. It includes:

• requirements and boundaries
• architectural decisions and tradeoffs
• code and documentation already inspected
• approaches already rejected
• tests, logs, and verification evidence
• user preferences and project constraints
• the current reasoning path still being developed

A summary is not a reliable replacement for full context. This is especially true in architecture design, cross-file modification, long-running debugging, performance analysis, migration planning, and multi-stage verification. Many important details cannot be safely preserved by a short summary.

1M context is already a practical capability boundary for long-horizon coding agents, not an unreasonable future wish.

Z.AI's GLM-5.2 documentation positions it as a flagship model for long-horizon tasks, lists a 1M context length, and explicitly connects it to project-scale engineering context and long-task execution:

https://docs.z.ai/guides/llm/glm-5.2

Z.AI's Claude Code integration documentation also shows glm-5.2[1m] and configures:

CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000

https://docs.z.ai/devpack/latest-model

Anthropic's documentation also says Claude Code supports a 1M token context window for certain paid-plan model combinations:

https://support.claude.com/en/articles/8606394-how-large-is-the-context-window-on-paid-claude-plans

These product examples show that 1M context is already part of real coding-agent workflows. GPT-5.5 in Codex, as a flagship model, should expose 1M effective context as well.

DeepSeek cache facts: long context is not always linear cost

Long context should not be reduced to "more input tokens means proportionally higher cost."

DeepSeek is a public and concrete example. DeepSeek's official documentation says Context Caching is enabled by default for all users. If later requests share an overlapping prefix with earlier requests, the overlapping part can be fetched from cache and counted as a cache hit:

https://api-docs.deepseek.com/guides/kv_cache

DeepSeek API responses also expose cache hit accounting directly:

• prompt_cache_hit_tokens
• prompt_cache_miss_tokens

The official docs state:

prompt_tokens = prompt_cache_hit_tokens + prompt_cache_miss_tokens

https://api-docs.deepseek.com/api/create-chat-completion

DeepSeek's pricing page also separates cache-hit and cache-miss input pricing and lists 1M context. In other words, providers are already treating a stable long-context prefix and a full cache miss as different cost structures:

https://api-docs.deepseek.com/quick_start/pricing

This demonstrates an important fact: in modern long-context model serving, a stable large prefix does not necessarily mean every turn is charged as a full linear input miss. Cache hits on stable prefixes can materially change the real cost structure.

Therefore, when Codex frequently compacts, rewrites, or restructures context, it may reduce the visible prompt length while also causing two problems:

• It loses context fidelity, causing GPT-5.5 to drop key state in complex engineering tasks.
• It disrupts stable prefixes, reducing the potential benefit of cache locality.

So forced early compaction should not be treated by default as the best cost or experience tradeoff. For users who are willing to pay more for serious complex engineering work, please return the choice of 1M context to the user.

Request to OpenAI

Please directly address the 1M effective context issue for GPT-5.5 in Codex:

• GPT-5.5 already has a 1M-context capability path. Please expose 1M effective context for GPT-5.5 in Codex.
• If Codex currently applies an effective context cap below 1M for GPT-5.5, please document the actual limit clearly.
• If reliability, latency, capacity, safety, or cost constraints currently prevent Codex from exposing 1M context, please state that explicitly.
• Do not use frequent lossy compaction as a substitute for the long-context capability expected from a flagship model.
• For users willing to pay more in exchange for long-context fidelity, please give that choice back to the user.

The core request is simple:

We want 1M context for GPT-5.5 in Codex.

To other users

If you also rely on Codex for long-running engineering work and want GPT-5.5 in Codex to expose 1M effective context, please add a 👍 reaction or comment with your workflow.