Skip to content

Make context window and auto-compaction settings model-aware #16140

Open
Open
Make context window and auto-compaction settings model-aware#16140
Labels
enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@GraviyDev
GraviyDev
opened on Mar 28, 2026

What feature would you like to see?

Model-aware context window and auto-compaction settings.

Problem

Codex currently allows global configuration like:

model_context_window = 1000000
model_auto_compact_token_limit = 500000

This works for a large-context model such as gpt-5.4, but becomes misleading or unsafe when switching to a smaller-context model such as gpt-5.4-mini.

The user can end up in a state where:

  • the UI still appears to reflect the large configured context window
  • the selected model actually has a smaller context limit
  • auto-compaction does not happen soon enough
  • the session fails with a context window exceeded error

Proposal

Please make context handling explicitly model-aware.

Possible approaches:

  • support per-model overrides in config
  • automatically clamp model_context_window to the selected model's true maximum
  • automatically clamp model_auto_compact_token_limit to a safe threshold under the selected model's limit
  • show both:
    • configured context window
    • effective context window for the currently selected model
  • show a warning when the configured values exceed the selected model's actual supported window

Why this matters

This is especially important for users who intentionally use:

  • gpt-5.4 with a very large configured context window
  • gpt-5.4-mini for cheaper or faster work in the same app

Right now the config model and the active UI-selected model can drift apart in a way that is hard to reason about.

Expected outcome

Switching models should never leave the user with stale or unsafe context settings.

The app should either:

  • transparently adapt the effective limits, or
  • explicitly tell the user that the current context settings are incompatible with the newly selected model.

Activity

  1. github-actions commented on Mar 28, 2026

    @github-actions
    github-actionsbot
    on Mar 28, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  2. etraut-openai
    added
    enhancementNew feature or request
    agentIssues related to the core agent loop
    on Mar 28, 2026

  3. GraviyDev commented on Mar 28, 2026

    @GraviyDev
    GraviyDev
    on Mar 28, 2026
    Author

    Related bug report: #16139

  4. etraut-openai
    added
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    and removed
    agentIssues related to the core agent loop
    on Apr 11, 2026

  5. mahdikayvan commented on May 9, 2026

    @mahdikayvan
    mahdikayvan
    on May 9, 2026

    @GraviyDev Hey — I know this kind of issue too well. It is very close to the agent reliability problem I’m working on.

    I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.

    It helps when a coding agent starts to drift, loses important context, or gives you an output you do not fully trust.

    In practice, it works through two habits:

    • tell the agent to remember-progress or remember-this when something important should not be lost
    • use consult-brain when the current task needs more grounded feedback on what to do next

    Over time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.

    If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.

    Cheers,
    Mads.

  6. chigkim commented on May 16, 2026

    @chigkim
    chigkim
    on May 16, 2026

    I'm using local model, and I can only afford 64k context window.
    I set model_context_window inside profile like this:

    [profiles.test]
model_provider = "llamacpp"
model = "Qwen3.6-27B"
model_context_window = 64000

    Then if I run /status, I get this:

    │ Context window: 86% left (45.9K used / 258K) │

    How can I set the context window for the profile properly?
    Thanks!

  7. chigkim commented on May 16, 2026

    @chigkim
    chigkim
    on May 16, 2026

    Nevermind, I asked Codex to look codex repo, and it said model_context_window is top level config.
    It worked if I set it on the top!

  8. kinzirva commented on Jul 28, 2026

    @kinzirva
    kinzirva
    on Jul 28, 2026 – with ChatGPT Codex Connector

    Additional deterministic evidence from macOS / Codex CLI 0.145.0 with gpt-5.6-sol.

    Environment

    • Codex CLI: 0.145.0
    • Surface: local CLI / TUI
    • Model: gpt-5.6-sol
    • Reasoning effort: high
    • Platform: macOS
    • A custom model_catalog_json entry declared:
      • context_window = 1048576
      • max_context_window = 1048576
      • effective_context_window_percent = 95
    • Codex therefore reported an effective window of 996147.
    • The built-in model cache for the same model declared 272000.

    Observed behavior

    Four separate tool-heavy threads failed with context_window_exceeded after the last successful request reached approximately:

    • 364559 input tokens
    • 369007 input tokens
    • 369869 input tokens
    • 371440 input tokens

    The next request failed with:

    Codex ran out of room in the model's context window.
Start a new thread or clear earlier history before retrying.

    The affected rollouts contained no compacted or context_compacted event before failure. The client was waiting for the locally advertised ~996K threshold while the request path rejected the conversation much earlier.

    This made the thread unrecoverable: even a short follow-up asking for a summary failed with the same error.

    Workaround and compact smoke test

    A safe local workaround was:

    model_auto_compact_token_limit = 220000
model_auto_compact_token_limit_scope = "total"

    I also ran a deterministic compact smoke test using the same model and CLI, temporarily overriding the threshold to 32000:

    1. First turn reached 37128 input tokens.
    2. The same thread was resumed with a short second prompt.
    3. The persisted rollout recorded both:
      • compacted
      • context_compacted
    4. The resumed turn completed successfully.

    This confirms the compact machinery itself works when the threshold is below the real request boundary. The failure is the unsafe split between configured/catalog context metadata and the actual accepted context.

    Suggested fix

    1. Treat the server/provider maximum as authoritative and clamp any custom catalog context_window to it.
    2. Compute the effective auto-compact limit as the minimum of:
      • configured compact limit,
      • server-advertised effective context,
      • a safe preflight limit that reserves output/reasoning headroom.
    3. Before sending a request, estimate the normalized prompt and trigger compaction when it cannot fit the active provider limit, even if local metadata says otherwise.
    4. On context_window_exceeded, perform one emergency compact-and-retry before making the thread unrecoverable.
    5. Show configured window, server-effective window, and active compact threshold separately in /status and diagnostics.
    6. Emit a warning when model_catalog_json advertises a window larger than the selected provider accepts.

    This appears to be a concrete GPT-5.6 instance of the model-aware context handling requested in this issue.

  9. SlipstreamAI commented on Sep 5, 2026

    @SlipstreamAI
    SlipstreamAI
    on Sep 5, 2026 – with ChatGPT Codex Connector

    I want to enable Astra’s larger supported context window while leaving other models at their defaults. Please provide per-model context and compaction settings that automatically follow the model selected in the desktop app, without requiring separate launch profiles.

  10. Mrchen116 commented on Sep 7, 2026

    @Mrchen116
    Mrchen116
    on Sep 7, 2026

    Adding another concrete use case for Codex Desktop: I would like to opt into Astra's larger supported context window while keeping Sol, Terra, and Luna at their default window or at a smaller user-selected budget (for example, around 256K).

    The request is for per-model overrides for both model_context_window and model_auto_compact_token_limit that automatically follow the model selected in the app, including when switching models in an existing task. This should not require restarting with a different CLI profile or editing global configuration each time.

    A lower per-model budget should be allowed even when several models advertise the same maximum: users may prefer different context sizes for task quality, latency, and usage. Merely clamping every model to its maximum does not address that preference.

    Expected behavior:

    • Astra can use its larger supported window, within the actual provider limit.
    • Other models retain their own defaults or explicitly configured smaller budgets.
    • Switching models updates the effective window and compaction threshold together, and the UI shows the active values.
    • If existing history exceeds the newly selected model's budget, Codex handles that transition before sending the next request.

    This is a configuration/UX request, not a claim that all non-Astra models have a hard quality boundary at 256K.

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

    enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions