/model mid-session: served model changes but the agent's stated identity does not, and the agent cannot query it

Summary

After changing the model mid-session with /model, the served model changes correctly, but the system-prompt environment block keeps reporting the previous model for the rest of the session. The agent therefore cannot determine which model is actually serving it, and there appears to be no way for it to query this.

This is not cosmetic. In a multi-model workflow where behaviour depends on model identity, the agent makes decisions from the stale value and gets them wrong.

What happened

1. Mid-session, I ran /model claude-opus-5. The command confirmed: Set model to claude-opus-5.
2. The session transcript confirms the switch took effect immediately — the message.model field flips to claude-opus-5 at that timestamp and stays there for every subsequent turn.
3. But the environment block in the system prompt continued to state the old model — You are powered by the model named Fable 5. The exact model ID is claude-fable-5 — on turns the transcript records as served by claude-opus-5.
4. The agent, correctly trusting its own system prompt, announced itself as the old model and behaved accordingly, for roughly seven hours.

Evidence

From the session's own .jsonl transcript, counting main-thread assistant turns only (no subagent/sidechain entries):

MAIN-THREAD turns by model: {'claude-fable-5': 38, 'claude-opus-5': 115}
SUBAGENT turns by model   : {}

Main-thread model changes, chronological (timestamps UTC):
  2026-08-09T18:58:57Z  -> claude-fable-5     (session start)
  2026-08-10T08:17:54Z  -> claude-opus-5      (the /model change)

Every assistant turn after 08:17:54Z is recorded as claude-opus-5. Multiple such turns nonetheless opened with an explicit self-identification as the old model, quoting the environment block verbatim as the source. The two signals disagreed for the remainder of the session.

Verbatim log excerpts

The command, as recorded in the transcript:

ts: 2026-08-10T08:16:25Z   role: user
<command-name>/model</command-name>
<command-message>model</command-message>
<command-args>claude-opus-5</command-args>

It echoed Set model to claude-opus-5. The message.model field flips at 08:17:54Z.

An assistant turn 37 seconds later — recorded as claude-opus-5, asserting it is the other model:

ts: 2026-08-10T08:18:31Z   message.model: claude-opus-5

"Understood, and this is exactly the moment the workflow's own seat check fires.
 Reading it back plainly:

 **I am Fable 5.** You have named Opus 5 as the lead. The Planning Workflow's
 Step 0 says a model that is not the lead must say so and stop rather than plan
 anyway..."

The turn is served by claude-opus-5 and states it is Fable 5, sourcing that claim from the
environment block in its system prompt. Every later turn in the session repeats the same
self-identification, each recorded as claude-opus-5.

This is the whole bug in three lines of log: command at 08:16:25Z, served model changes at
08:17:54Z, agent still asserting the old identity at 08:18:31Z and for the following seven hours.

Environment

• Claude Code 2.1.221
• macOS 26.5.2
• Change made mid-session via /model claude-opus-5, session left running (unattended overnight work)

Impact

The workflow this ran in routes work by model: one model authors a plan, and two different models review it, with a hard rule that no model may review a plan it wrote. The agent read its (stale) identity, concluded it was not the model that had been put in the lead seat, and declined to do the authoring work — while the model actually serving was the one that had been asked to do it.

Cost: an entire unattended overnight session produced none of its intended output. The agent's reasoning was sound; its input was wrong.

Worth noting the failure mode is quiet. Nothing errors. The agent confidently asserts a false fact about itself and acts on it, and the only way to detect it is to read the raw transcript afterwards.

Expected behaviour

Either of these would resolve it:

1. Refresh the environment block when /model takes effect, so the stated model matches the serving model for the rest of the session.
2. Expose the serving model to the agent through something it can call — a tool, or a documented reliable field. Today there appears to be no way for an agent to answer "which model am I?" other than trusting a system-prompt string that can be stale.

Option 2 is the more robust fix, and useful independently: any agent whose behaviour is model-dependent needs a trustworthy answer to that question.

Notes

• Subagents were dispatched during this session with explicit model pins. They are not the cause: the counts above exclude sidechain turns entirely, and the mismatch is on main-thread turns.
• The /model command itself worked. The defect is purely that the agent-visible identity was not updated to match.