[FEATURE] Auto-upgrade to larger context window model instead of compacting

Resolved 💬 2 comments Opened Feb 7, 2026 by xroche Closed Mar 7, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When a session approaches the context window limit, Claude Code triggers auto-compaction: it summarizes the conversation to free up tokens. This works, but compaction is lossy — nuanced details, exact code snippets, and investigation context accumulated over a long session can be lost in the summary.

Meanwhile, some models have larger-context variants available (e.g., claude-opus-4-6 at 200K vs opus[1m] at 1M tokens). Today, a user who starts a session on the standard model has no way to seamlessly "upgrade" to the larger context window when the session grows long. The only options are:

  1. Let compaction happen and accept the information loss.
  2. Manually switch with /model opus[1m] before compaction fires — but this requires the user to monitor context usage and intervene at the right time.

For complex, long-running sessions (deep debugging, large refactors, multi-file investigations), the accumulated context is the value. Compacting it away defeats the purpose of the work done so far.

Proposed Solution

When auto-compaction is about to trigger, offer the option to switch to a larger-context variant of the current model instead of compacting. This could work in two modes (configurable via settings):

Mode 1 — Ask the user (default):

Context is at 185K/200K tokens. Auto-compaction will run.
A larger context window is available: opus[1m] (1M tokens).
  [1] Switch to opus[1m] and keep full context
  [2] Compact and stay on current model

Mode 2 — Auto-upgrade:
A setting like "contextLimitAction": "upgrade" that automatically switches to the larger-context model variant when compaction would otherwise trigger.

Configuration example (in settings.json):

{
  "contextLimitAction": "ask",
  "contextUpgradeModel": "opus[1m]"
}

Possible values for contextLimitAction:

  • "compact" — current behavior (default)
  • "ask" — prompt the user before compacting
  • "upgrade" — automatically switch to the larger model

Alternative Solutions

  • Start every session on the 1M model: wastes money on short sessions where 200K is plenty.
  • Manually run /model opus[1m]: requires the user to monitor context usage and intervene at exactly the right time. Easy to miss.
  • Use /compact manually at strategic points: still lossy; just shifts the timing.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

  1. I start a session on claude-opus-4-6 (200K) to debug a complex issue
  2. The investigation spans multiple files, logs, and iterative hypotheses — context grows organically
  3. At ~185K tokens, Claude Code is about to auto-compact
  4. Instead of losing the detailed investigation context, Claude Code asks me: "Switch to opus[1m] to keep full context?"
  5. I accept; the session continues seamlessly with all context preserved
  6. I pay the higher per-token cost only for the portion of the session that actually needed it

Additional Context

Related issues:

  • #16065 — Choose a different model for compaction (different angle: cheaper model for compaction)
  • #17772 — Programmatic model switching for agents
  • #23432 — /context reports 200K max for Opus 4.6 instead of 1M

Key difference from existing requests: those issues focus on switching models based on task type (planning vs execution) or cost optimization during compaction. This request is about avoiding compaction entirely by upgrading to a model with a larger context window when the current one fills up.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗