Auto-compaction leaves the session on Haiku 4.5 on Linux (`opus[1m]`, Max 20x) — silent, and it degraded real work

What happened

On a long-running session pinned to opus[1m], auto-compaction fired at roughly 90% of the
context window. After it completed, the session continued on claude-haiku-4-5-20251001
instead of returning to Opus.

Nothing announced the change. No banner, no transcript line, no warning. The session kept
answering normally — just on a much weaker model — and I only realised afterwards, from the
quality of the output.

This looks like the same defect as #87523, with two differences that may matter:

• that report is Windows and a manual /compact; this is Linux and auto-compaction
• this occurrence has a documented downstream consequence (below), not just a model mismatch

Environment

• Claude Code 2.1.241
• Linux 7.0.0-30-generic (x86_64)
• Plan tier: default_claude_max_20x
• ~/.claude/settings.json: "model": "opus[1m]", "effortLevel": "max"
• fallbackModel: not set at the time of the incident
• autoCompactWindow: not set (model-tuned default)

Evidence on disk

~/.claude.json → clientDataCacheSlots carries slots stamped with Haiku while the configured
model is opus[1m]:

  bi1-b3776131e5ebf442 -> claude-opus-5
  bi1-fd034ccb41c153b1 -> claude-haiku-4-5-20251001
  bi1-c0f48fa26ff9d0c7 -> claude-haiku-4-5-20251001
  bi1-7c69681c8744c004 -> claude-opus-5
  bi1-259bbe79744daa2f -> claude-fable-5
  bi1-c868b4208f8a1107 -> claude-opus-5
  bi1-edac96dd6163f4fe -> claude-fable-5
  bi1-415e9b851a660841 -> claude-opus-5

Per the docs, the fallback chain "won't fall back to a model with a smaller context window than
the primary's, since summarizing there would cut off part of the conversation first"
(https://code.claude.com/docs/en/model-config). Haiku 4.5 has a 200K window against opus[1m]'s
1M, so on this configuration it should not be reachable for compaction at all.

Why this is worse than a model mismatch

The silent downgrade did not produce obviously broken output. The code it wrote afterwards was
correct and the diagnosis was directionally right. What it lost was verification discipline:

• it shipped a measured statistic that was wrong by ~10x (a "16%" figure that re-measurement

put at 2.0%), into a client-facing draft

• it treated a cached HTTP response as a control measurement — the "control" returned

x-cached: Hit from cache, so it was never a real render, and the cache-buster in use did not
bust that cache

Both were caught later and corrected, but only by accident. This is the failure mode that makes
the silence dangerous: a weaker model on the same task does not fail loudly, it fails
plausibly — and plausible wrong numbers travel further than broken code.

Expected behaviour

1. After compaction, the session returns to the configured model.
2. If compaction has to run on a different model, that is stated — in the UI and in the

transcript — rather than inferred later from output quality.

1. A model with a smaller context window than the primary is never selected for compaction, as

the documentation already specifies.

Workaround

Setting an explicit "fallbackModel": "sonnet" keeps the chain above Haiku. It does not address
the silence, which is the part that caused the damage here.