claude-code - 💡(How to fix) Fix Agent not notified of mid-session model changes — system prompt becomes stale after /model switch

Summary

When the user switches the active model mid-session with /model, the agent does not receive an updated system prompt. The "You are powered by the model named ..." line retains the value from session start, so the agent has no reliable way to know the model has changed.

Steps to reproduce

1. Start a session (model = Opus 4.7; system prompt says "You are powered by the model named Opus 4.7").
2. Run /model and switch to Sonnet 4.6.
3. Send a message. Observe: the system prompt still says "You are powered by the model named Opus 4.7".

Verified 2026-05-25: after a /model switch from Opus 4.7 → Sonnet 4.6 (1M context), the system prompt did not update. The only signal visible to the agent was the /model command's local-command-stdout block — not a system prompt update.

Why the agent needs to know its current model

Several agent behaviours depend on knowing the running model:

1. Context budget management. Different models have different context window sizes. Opus 4.7 and Sonnet 4.6 both offer 1M-token windows, but a user might switch from a 1M model to a 200k model (or vice versa). An agent that believes it has 1M tokens when it actually has 200k will miscalibrate how aggressively to load files, how many search results to retain, etc. Conversely, an agent that believes it has 200k tokens when it has 1M will be unnecessarily conservative.

2. Correct attribution in commits, PRs, and comments. Some projects have a strict policy that commits and GitHub comments written with AI assistance should name the model that assisted. If the system prompt is stale, the agent writes wrong attribution — e.g. "Co-authored-by: Claude Opus 4.7" when the work was actually done by Sonnet 4.6. This is a reproducible, observable failure on every project that uses Claude Code for attributed contributions that include the model name.

3. Model-specific capability and cost reasoning. Certain agent decisions — whether to use extended thinking, how to estimate token costs, whether a particular skill or feature is available — may legitimately vary across model families. An agent that doesn't know it has been switched cannot make these judgements correctly.

4. Accurately reporting the current state when a user is debugging unexpected-model problems. If the user (who might not know about the /model command) finds or suspects that they are using an unexpected model, it can only confuse debugging if the agent confidently gives them a wrong answer about which model is running.

Expected behaviour

When the model changes mid-session (via /model or any other path), the agent's system prompt should be updated to reflect the new model name and ID. Alternatively, or additionally, a dedicated notification event or injected system message could be used, as long as the agent has a reliable in-context signal.

Workaround

Agents can watch local-command-stdout blocks for /model output as a secondary heuristic, but this is fragile: it relies on the agent recognising a specific block format, breaks if the switch happens via a non-slash-command path, and produces no signal if the agent was not already watching for it.

Related

• #33807 (statusline shows wrong model after /model switch — UI-side symptom of related root cause)
• #33401 (system prompt wrong model in plan mode — narrower, opusplan-specific, closed as not planned)

This is not a duplicate of the many issues referring to the status line. This bug is about the agent's knowledge, not the UI. (Aside: please say "closed as duplicate of #issuenumber", not just "closed as duplicate".)

🤖 Filed with Claude Code (Sonnet 4.6).