Allow opt-in full 1.05M context and configurable compaction for GPT-5.6 Sol
What variant of Codex are you using?
Codex App and Codex CLI with GPT-5.6 Sol on a ChatGPT Pro subscription.
What feature would you like to see?
Allow advanced users to opt into the full context window supported by GPT-5.6 Sol and configure when automatic compaction occurs.
The current default can remain optimized for cost, latency, and general use. The requested change is an explicit advanced option, not a change to the default behavior.
A suitable implementation could:
- Allow
model_context_windowto be configured up to the maximum supported by the selected model, including the full 1.05M window for GPT-5.6 Sol. - Allow
model_auto_compact_token_limitto be configured independently within that effective window. - Expose equivalent controls in the Codex App for users who do not edit
config.toml. - Clearly display the effective context window and automatic-compaction threshold for the active session.
- Apply a higher usage multiplier, consume additional credits, or permit paid overage when a larger context tier is selected.
- Keep the existing smaller window and current compaction behavior as the default.
This is important because compaction is useful but lossy. During long debugging sessions, architecture analysis, repository-wide refactors, and research-heavy implementations, summaries can omit small decisions, failed approaches, constraints, and relationships between files that remain relevant later.
I recently completed a long, tool-heavy coding task using GPT-5.6 Sol through GitHub Copilot. After many iterations, the session reported roughly 260K tokens used out of the 1.05M context window without requiring compaction. In daily Codex use, comparable workflows commonly trigger one or more compactions much earlier. This creates a material continuity difference even when the underlying model is the same.
I am not requesting free, unlimited 1M context. As a ChatGPT Pro user, I would willingly accept higher quota consumption or additional charges for selected sessions where preserving raw context is more valuable than minimizing usage. The core request is user control over the cost, latency, and context-retention tradeoff.
Additional information
Related issues:
- openai/codex#19464 requested opt-in 1M context for GPT-5.5. That issue remains open but its conversation is locked, so updated GPT-5.6 Sol feedback cannot be added there.
- openai/codex#31860 documents the gap between the GPT-5.6 Sol API context specification and the smaller effective Codex window.
- openai/codex#32806 documents a subsequent reduction in the effective GPT-5.6 Sol context exposed by Codex.
This issue is intentionally filed as a feature request rather than a bug report. It asks for a supported opt-in mechanism, transparent effective limits, and an explicit usage multiplier rather than assuming the full model context must be included in the default subscription behavior.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Other models typically provide 1M of context without any additional subscription fees for window usage. Why should we pay more for 1M of windows with Codex?
You're right, and I agree with you.
The higher usage multiplier or paid-overage option in my proposal is intended as a compromise, not as the preferred outcome or a requirement. Ideally, the full supported context window should be included in the existing subscription, just as competing coding products provide long-context access without introducing a separate surcharge once a session crosses a threshold such as 256K tokens.
Anthropic is a relevant example here: users do not pay a distinct extra fee simply because a supported Claude Code session grows beyond 256K context. The normal plan or usage accounting continues to apply.
My main request is therefore not "let us pay more for 1M context." It is: please stop imposing a substantially smaller hard window and early compaction when the underlying model supports 1.05M, and give users control over that tradeoff. A higher multiplier would only be preferable to having no supported opt-in path at all.
Makes total sense, seems like on the web app it's 1.5M or so and the Codex app where you'll use it against a real project (that's what it's for, isn't it) you have this tiny 258k context. I agree that models start to act differently after certain threshold, but for me 258k is too low. Most of my chat for analyzing/modifying interactive diagrams slightly (.html documents) end up just below 258k after 1 prompt or auto-compact, even with me trying my best to provide as little files to the context as I can.
If 258k or 375k as it was is the optimal value, then the 1M option (or even 500-600k would do) can just be disabled by default and freedom can be given to the user. Another reason for me is also Sol Ultra, how'd you span agents with this tiny context (maybe 375k can be considered tiny too in this situation)?
A smaller compromise would already be materially useful: I do not require the full 1.05M window. Please provide an opt-in tier with at least 500K of effective input context before automatic compaction.
By “500K effective input context”, I mean the usable input budget shown to the user—not a nominal total window from which a large output reservation is subtracted, leaving substantially less than 500K for the active task.
Why this is a reasonable intermediate tier:
If OpenAI has concerns about retrieval quality or positional generalization beyond approximately 300K, an opt-in beta with a clear warning and published long-context evaluation data would be preferable to a hard server-side cap with no user choice.
Serving long context has real prefill, cache, latency, and capacity costs. The request is not to pretend those costs do not exist; it is to expose a paid, explicit tradeoff rather than making early compaction mandatory for every subscription user.