[Bug] v2.1.121: Opus 4.7 (1M context) max-effort window silently self-downgrades to Sonnet 4.6 mid-session AND /compact does not fire at context limit

Resolved 💬 7 comments Opened Apr 28, 2026 by ThatDragonOverThere Closed Jun 11, 2026

[Bug] v2.1.121: Opus 4.7 (1M context) max-effort window silently self-downgrades to Sonnet 4.6 mid-session AND /compact does not fire at context limit

Version: Claude Code 2.1.121 (Node.js path, Windows)

Severity: Critical — compound failure: model-tier integrity broken + the runtime's own documented context-limit recovery primitive (/compact) does not execute. Operator's only recovery path is manual /model re-select + please continue, which is opaque to any agent reading session metadata for tier verification.

---

Repro

  1. Start a Claude Code window with explicit /model opus[1m] + max effort (or set as default).
  2. Run long-form work that approaches the context limit (~250K tokens on 1M-context Opus).
  3. At the context wall, observe Claude Code's prompt:

``
Context limit reached · /compact or /clear to continue · /model sonnet[1m]
``

  1. Run /model to query the active model.
  2. Observe: model has silently downgraded to Sonnet 4.6 without any operator action and without any prior banner/log entry.
  3. Run /compact. Observe: command does not execute / does not produce a compaction.
  4. Recovery: /model opus[1m] (default) with max effort, then please continue.

---

Two distinct failure modes compounding

1. Silent model self-downgrade Opus 4.7 1M max-effort → Sonnet 4.6

The operator-selected tier is not preserved across the session. No log entry, no banner, no in-session acknowledgment that the model has changed. The agent ran on Sonnet for an unknown portion of the session while the operator believed the agent was running on Opus.

This is the second documented self-downgrade observation in 24 hours. First instance: Apr 27 evening, a long-running agent self-downgraded Opus Max → Sonnet at some point during the daytime session before being manually switched back to Opus Max for overnight work. (That instance was not filed standalone at the time because Sonnet behavior happened to be the better outcome on that task — but the downgrade itself is a tier-integrity bug regardless of which direction the quality cuts.)

This second instance — fresh deliberate 1M max-effort selection in a brand-new window, downgrades anyway, discovered only via /model query at the context wall — is a clear regression worth filing.

2. /compact non-execution at context limit

The slash command listed in the context-limit message itself (Context limit reached · /compact or /clear to continue) did not produce a compaction when invoked. The runtime's published recovery path for its own published context-limit message is broken in v2.1.121.

The only path back into the session was:

  1. /model opus[1m] (manual re-selection of the operator-intended tier)
  2. please continue (manual continuation prompt)

---

Why this matters in autonomous / overnight workflows

The two failure modes compose. An operator who sets Opus before bed for autonomous overnight work could wake up to find:

  • a Sonnet-tier agent has been running for most of the night
  • the agent is stranded at the context wall
  • there is no automatic recovery — /compact won't fire
  • the only revival path is manual /model re-select, which an autonomous agent cannot perform on its own session

This is the single-window analogue of the sub-agent integrity inheritance bug (#54393 BUG-10) — operator selects a tier, runtime silently degrades it, no validation surface catches the drift.

---

Hypothesis (not validated, needs Anthropic-side trace)

The /compact failure may be tier-gated and may misfire when the actual-running-tier does not match the operator-selected-tier. The two failure modes may share a single root cause in v2.1.121's model-tier persistence path. Worth checking whether the /compact execution path has any code that conditions on currentModel vs userSelectedModel or equivalent.

---

Ask

  • Stop silent model downgrades. If the runtime needs to change tier mid-session for capacity / load / billing reasons, surface a banner or log entry at the moment of the change so the operator can detect it before walking off a context wall on the wrong tier.
  • Fix /compact execution at the context limit so the runtime's own published recovery path actually works.
  • Surface the active-tier mismatch in /usage, the statusline, or the context-limit message itself so operators can detect the downgrade before it costs a multi-hour session.

---

Cross-references: #54393 (12-bug coordination catalog including BUG-10 sub-agent integrity inheritance), #53610 (architectural gaps for unattended overnight operation including per-session-throttle observability).

View original on GitHub ↗

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