Skip to content

Reopen #19464 and support 1M context #30910

Open
Open
Reopen #19464 and support 1M context#30910
Labels
CLIIssues related to the Codex CLIappIssues related to the Codex desktop appcontextIssues related to context management (including compaction)enhancementNew feature or requestrate-limitsIssues related to rate limits, quotas, and token usage reporting

Description

@reliefeai
reliefeai
opened on Jul 2, 2026

What variant of Codex are you using?

App,CLI

What feature would you like to see?

Ever since GPT-5.5 was released, the context window has been stuck at only 272k. Any related discussion gets immediately closed by staff with the "openai" suffix.

At this point, 272k context is practically unusable in codex. I run into context compression failures more than once a day, and each thread averages five to six context compressions. Every compression noticeably degrades work capability and causes the model to forget things.

Why not give us back the 1M context? Even an option like a [1m] toggle like the one in claude code wouldn't work? Consume more credits if you have to. Why actively downgrade developers' experience?

If you're worried about compute capacity, don't enforce any actual limit on the server side—just let us flip this hidden option through an env variable so that those who need it can enable it. Would that really be so hard?

Additional information

No response

Activity

  1. reliefeai
    added
    enhancementNew feature or request
    on Jul 2, 2026
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    appIssues related to the Codex desktop app
    contextIssues related to context management (including compaction)
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jul 2, 2026

  3. github-actions commented on Jul 2, 2026

    @github-actions
    github-actionsBot
    on Jul 2, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. reliefeai commented on Jul 2, 2026

    @reliefeai
    reliefeai
    on Jul 2, 2026
    Author

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

    no dublicate.

  5. LimLex commented on Jul 2, 2026

    @LimLex
    LimLex
    on Jul 2, 2026

    I don't think this is a technical limitation—it's a cost issue. The actual API cost of Codex subscriptions likely far exceeds the subscription price, and supporting a 1M-token context window would only drive those costs much higher. At least for now, OpenAI probably isn't planning to absorb that expense for developers.
    Right now, Codex is geared more toward localized feature improvements and is still far from being able to replace CC. As long as the context window doesn't grow, it won't be able to handle large-scale architectural tasks.

  6. LimLex commented on Jul 2, 2026

    @LimLex
    LimLex
    on Jul 2, 2026

    I don't think this is a technical limitation—it's a cost issue. The actual API cost of Codex subscriptions likely far exceeds the subscription price, and supporting a 1M-token context window would only drive those costs much higher. At least for now, OpenAI probably isn't planning to absorb that expense for developers. Right now, Codex is geared more toward localized feature improvements and is still far from being able to replace CC. As long as the context window doesn't grow, it won't be able to handle large-scale architectural tasks.

    So I don't think developers need to keep pushing Codex to support a 1M-token context window. Once OpenAI is rich enough, they'll support it naturally.

  7. reliefeai commented on Jul 2, 2026

    @reliefeai
    reliefeai
    on Jul 2, 2026
    Author

    I don't think this is a technical limitation—it's a cost issue. The actual API cost of Codex subscriptions likely far exceeds the subscription price, and supporting a 1M-token context window would only drive those costs much higher. At least for now, OpenAI probably isn't planning to absorb that expense for developers. Right now, Codex is geared more toward localized feature improvements and is still far from being able to replace CC. As long as the context window doesn't grow, it won't be able to handle large-scale architectural tasks.

    They can set a higher price, and I'm willing to pay more for it.

  8. LimLex commented on Jul 2, 2026

    @LimLex
    LimLex
    on Jul 2, 2026

    I don't think this is a technical limitation—it's a cost issue. The actual API cost of Codex subscriptions likely far exceeds the subscription price, and supporting a 1M-token context window would only drive those costs much higher. At least for now, OpenAI probably isn't planning to absorb that expense for developers. Right now, Codex is geared more toward localized feature improvements and is still far from being able to replace CC. As long as the context window doesn't grow, it won't be able to handle large-scale architectural tasks.

    They can set a higher price, and I'm willing to pay more for it.

    The subscription price is already far below the actual API cost. Even charging developers a few hundred dollars more wouldn't be enough to cover the additional cost of supporting a 1M-token context window.

  9. wjarka commented on Jul 7, 2026

    @wjarka
    wjarka
    on Jul 7, 2026

    It was implied in the original issue that this would be implemented. It's honestly the only item stopping me from cancelling my Claude sub and going all in OpenAI.

  10. ai-erp-collab commented on Jul 8, 2026

    @ai-erp-collab
    ai-erp-collab
    on Jul 8, 2026

    Noticed the same drop — went from 1M to 272K mid-sprint.
    Coincidentally, I've been working on a methodology for exactly this scenario: Deterministic Context Routing (DCR) — structured context management designed for short-window agent sessions. Module registry, layered knowledge base, session state with stop markers, confidence labels. The idea is to route only what's needed instead of dumping everything into one window.
    There's a write-up here: https://github.com/ai-erp-collab/deterministic-context-routing
    It helps with large, raw-data-heavy projects — the kind where you'd normally burn through context just navigating the workspace. ERP development, multi-module codebases, that sort of thing.
    Might be useful if the window stays where it is.

  11. wjarka commented on Jul 10, 2026

    @wjarka
    wjarka
    on Jul 10, 2026

    It's not dropping midsprint. It will show 1M before you send the first prompt and then will update right after that or after the first response. Which probably means you configured codex to use 1M, but it can't and only updates the UI when you try.

  12. Ahoo-Wang commented on Jul 20, 2026

    @Ahoo-Wang
    Ahoo-Wang
    on Jul 20, 2026

    Fable 5: 1M. K3: 1M. GLM-5.2: 1M. Grok 4.5: 500K. GPT-5.6 Sol API: 1.05M. In Codex: 272K.

    OpenAI built a frontier brain and locked it in a toy cage. 272K isn’t context.

    It’s a README with delusions of grandeur. Codex didn’t deploy Sol. It imprisoned it.

    Image

  13. otmanm commented on Sep 9, 2026

    @otmanm
    otmanm
    on Sep 9, 2026 – with ChatGPT Codex Connector

    My request is not for a one-million-token context window.

    The current Codex catalog on my machine reports the following for Astra and GPT-5.6:

    • Default raw context: 272,000
    • Maximum raw context: 872,000
    • Effective usable percentage: 95%
    • Default usable context: 258,400
    • Maximum expected usable context: 828,400

    My intended configuration is:

    model_context_window = 872000
model_auto_compact_token_limit = 580000
model_auto_compact_token_limit_scope = "total"

    The 580,000 value is a deliberate safety threshold. It gives Codex substantial room to compact before the available approximately 828,400-token usable limit. It is not a claim that the model has a one-million-token context window.

    The current behavior is unacceptable from a usability and transparency perspective. Codex silently starts supported models at approximately 258,400 usable tokens even though the same delivered catalog lists an 872,000 raw maximum. Users should not have to inspect model-cache files, source code, configuration fields, and rollout JSONL to understand why a session compacted or how much context it actually has.

    Codex should visibly report:

    • Active raw context window.
    • Effective usable context.
    • Catalog maximum.
    • Configured automatic-compaction threshold.
    • Effective threshold after clamping.
    • Whether the value came from the model catalog, local configuration, or a remote override.
    • Whether compaction created a replacement context window.
    • Whether a resumed or compacted task retained the configured context profile.

    My current task still reports 258,400 usable tokens because the 872,000 override was not active when that task was created. I will verify the result in a freshly started Astra task after applying the configuration.

    If the fresh task reports 828,400, the hidden override works, but the 272K default and absence of visible active/max/compaction telemetry remain serious discoverability problems.

    If the fresh task still reports 258,400, Codex Desktop is not honoring the explicit override or the catalogued 872K maximum.

    AI helped reconstruct the configuration and session evidence. I reviewed and verified the claims before publication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIappIssues related to the Codex desktop appcontextIssues related to context management (including compaction)enhancementNew feature or requestrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions