Subagent model override silently ignored; TUI shows a third, stale model

Summary

Three different answers for "which model is my subagent running?":

1. Requested via the Agent tool's model parameter: fable (3 agents) and sonnet (2 agents)
2. Displayed in the TUI subagent view header: Opus 4.8
3. Actually served, per each agent's task-output transcript: claude-opus-5 — all five

So the model override is silently ignored, and the label shown is a third value that matches neither. Both symptoms appeared immediately after the opus alias was remapped from Opus 4.8 to Opus 5 (2026-07-25), which suggests one incomplete rollout rather than two unrelated bugs.

Environment

• Claude Code 2.1.220
• macOS 26.5.2 (Apple silicon)
• Session model: Fable 5
• Subagents dispatched via the Agent tool with an explicit model parameter, subagent_type: "general-purpose"

Steps to reproduce

1. From a session, dispatch subagents with an explicit model override, e.g. Agent({ subagent_type: "general-purpose", model: "sonnet", prompt: "..." }), and a second one with model: "fable".
2. While they run, open the subagent view in the TUI and read the model shown in the header.
3. After they finish, inspect the model recorded on the agent's own assistant turns:

``
grep -o '"model":"[^"]*"' <task-output-file> | sort -u
``

Expected

• The subagent runs on the requested tier, or the call fails / warns if the override cannot be honored.
• The TUI header shows the model that is actually serving the subagent.

Actual

• Every subagent ran claude-opus-5 regardless of the requested alias — verified across 5 agents; in one sampled transcript the field appeared on 35 of 35 assistant turns, alongside genuine stop_reason and usage data, so it reflects the serving model rather than a display string.
• The TUI subagent view header read Opus 4.8, which matched neither the request nor the transcript.
• No warning, no error, no indication anywhere in the session that the override had been dropped.

Impact

The silent no-op is the costly part. Model selection per subagent is how a session controls both spend and rigor — cheap breadth-first agents for mechanical search, a stronger model for adversarial verification and for security-sensitive diffs. When the parameter is accepted and then ignored:

• Cheap fan-out work silently runs on an expensive tier (unplanned spend).
• Deliberate escalations silently run below the intended tier (weaker review than believed).
• The session plans around a capability it does not have, and has no way to notice — the only route to the truth was grepping raw transcripts, because the one surface that reports a model, the TUI, was showing a stale value.

If an override cannot be applied (deployment policy, agent-type definition, alias remap), surfacing that once at dispatch time would be enough to make the behavior safe.

Suggested fixes

1. Honor the model parameter, or return a visible warning naming the model that will actually run.
2. Update the TUI subagent header to the serving model (the stale "4.8" label looks like a display string not updated with the alias remap).
3. Consider a documented way to read a subagent's actual model without parsing transcript JSONL.