Session left on the compaction model after /compact (Opus -> Haiku 4.5), silently

What happened

After running /compact in a long-running session pinned to Opus, the session was left on
claude-haiku-4-5-20251001. Nothing else changed — no settings file, no --model flag, no
usage-limit fallback. I noticed only because I happened to open /model two minutes later and saw
Haiku selected, and set it back manually.

The concerning part is not the one occurrence but that it is silent: the session keeps
answering, just on a much weaker model, and nothing in the UI or the transcript announces it.

Environment

• Claude Code 2.1.234
• Windows 11 Pro 10.0.26200
• Plan tier: default_claude_max_20x
• Configured model: "model": "opus[1m]" in ~/.claude/settings.json
• Long-running session (very large transcript), previously compacted several times

Timeline (local time, all from on-disk artifacts)

| Time | Event | Where it is recorded |
|---|---|---|
| 07:08:24 | /compact run manually | ~/.claude/history.jsonl; transcript carries compactMetadata:{"trigger":"manual"} |
| 07:09:49–07:10:29 | compaction records written | transcript records in this window carry no model field |
| 07:10:24.309 | /model opened | ~/.claude/history.jsonl |
| 07:10:24.619 | CLI writes a cache slot stamped with its current model | ~/.claude.json → clientDataCacheSlots → "model": "claude-haiku-4-5-20251001" |
| 07:13:41 | model set back to Opus manually | ~/.claude/settings.json mtime |
| 07:13:45 | first assistant message afterwards | transcript, "model":"claude-opus-5" |

The model was Opus before the compact and Haiku 4.5 two minutes after it.

Why the transcript doesn't show it

No assistant message was generated between the compact and the manual fix, so no transcript
record carries "model":"claude-haiku...". The only artifact that captured the state is the
clientDataCacheSlots entry, which the CLI stamps with whatever model is active at the time — it
was written 310 ms after /model was opened.

This means the failure is effectively invisible in the session log. Had a message been sent in
that window it would simply have been answered by Haiku with no indication.

What I ruled out

• No config pins Haiku. ~/.claude/settings.json still reads "model": "opus[1m]" (its mtime is

the manual fix). No model key in user settings.local.json, project .claude/settings.json or
.claude/settings.local.json. No managed-settings.json / policies.json.

• Not an external process. No --model was passed at launch; the string haiku appears nowhere

in the surrounding tooling or configuration.

• Not a usage-limit fallback. A full diff of ~/.claude.json across the window shows only

promptQueueUseCount +1 and the single cache slot above — no fallback-model field, no rate-limit
state change.

Expected vs actual

• Expected: after /compact, the session continues on the model it was using (or the configured

default). If the summarization step uses a different model internally, that should not persist.

• Actual: the session was left on claude-haiku-4-5-20251001, silently.

Impact

On long-running sessions that auto-compact, this can demote the session without any user action
and without any visible signal. The same transcript contains four compact boundaries, three of them
trigger: "auto", so a user need never type /compact to hit it.

Suggested fixes

1. Restore the session's model after compaction (or never mutate the session model for the

summarization step).

1. Record the active model on compaction records so the transition is auditable in the transcript.
2. Surface a visible notice if a session's model changes for any reason other than an explicit user

action.