Skip to content

Auto 1M context mode for supported models to balance speed/cost vs large-context reliability #13913

Description

@zemaj

What variant of Codex are you using?

CLI

What feature would you like to see?

Add a first-class auto 1M context mode for supported models, so Codex can use the larger context window only when it is actually needed.

This is related to #13653.

Problem

Right now, using 1M context is basically all-or-nothing.

If I manually configure a model for a 1M context window, then every turn pays the tradeoff:

  • potentially slower responses
  • higher usage cost
  • more aggressive large-context behavior than many turns actually need

But if I do not configure 1M context, then long-running or context-heavy turns can fail or compact too early.

What I want is not “always 1M” and not “never 1M”.
I want:

  • normal/faster/cheaper behavior most of the time
  • 1M context only when the upcoming turn actually needs it

Proposed UX

Introduce a higher-level config like:

context_mode = "disabled" | "1m" | "auto"

Suggested behavior:

  • disabled
    • use the normal context tier / existing behavior
  • 1m
    • always use the 1M context tier on supported models
  • auto
    • default to normal behavior for most turns
    • evaluate each new idle user turn before sending it
    • if the upcoming turn appears small enough, stay on the normal path
    • if the upcoming turn is large enough, switch into 1M-style behavior and compact only when needed

Why this matters

The main value of auto is balancing:

  • speed
  • token usage cost
  • reliability on long or complex follow-up turns

In other words:

  • most turns should stay fast and cheap
  • only the turns that really need large context should pay for large context

Relation to #13653

I think #13653 is still useful for explicit context-tier selection.

But even with explicit tier selection, there is still a missing UX:

  • users often do not want to choose “always 1M”
  • they want Codex to decide when large context is necessary

So I think these are complementary:

Suggested implementation direction

A reasonable implementation might:

  • only enable 1M behavior on models that actually support it
  • estimate the next-turn in-context size, not lifetime token totals
  • skip any 1M/compaction logic below a safe lower bound
  • compact immediately near the top of the effective 1M window
  • in the middle band, prefer preserving recent context for continuation/follow-up turns
  • keep low-level knobs like model_context_window and model_auto_compact_token_limit as advanced overrides, not the main UX

UI ideas

Surface context mode and status in /context, for example:

  • 1M Context
  • 1M Auto
  • Checking context...
  • Compacting...

Additional information

The main thing I’m trying to solve is the current all-or-nothing tradeoff:

  • use 1M when necessary
  • avoid it most of the time to improve speed and usage cost

Metadata

Metadata

Assignees

No one assigned

    Labels

    contextIssues related to context management (including compaction)enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions