[BUG] Subagent model override is dropped on resume/continuation — resumed turns silently fall back to the session model
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When a subagent is launched via the Task/Agent tool with an explicit model override (e.g. model: "sonnet"), the override is honored for the agent's initial run but is LOST when that same agent is resumed or continued (e.g. via SendMessage to an existing agent, or when the harness continues an agent after a mid-run interruption). The continued turns silently fall back to the parent/session model instead of the model the agent was originally dispatched with.
In my session the main loop was Claude Fable 5 and I dispatched every subagent with model: "sonnet". Fresh dispatches were correct — 60+ agents ran entirely on claude-sonnet-5. But two agents that were continued showed a split: the initial turns ran on claude-sonnet-5 and the resumed tail switched to claude-fable-5 (the session model). This is invisible at runtime — nothing surfaces that the resumed portion changed model — so an agent you believe is running on a cheap model is actually finishing on the expensive session model.
Evidence from the agent transcript JSONL (each assistant record carries its own "model"):
- Agent A (resumed via SendMessage for a follow-up task): 244 turns on claude-sonnet-5, then 15 turns on claude-fable-5.
- Agent B (continued after an interruption): 13 turns on claude-sonnet-5, then 14 turns on claude-fable-5.
Both tails switched to exactly the session/parent model that was active at the time.
What Should Happen?
A subagent's model should be sticky for the life of that agent. When an agent originally dispatched with an explicit model override is resumed or continued, the resumed turns should keep the original override, not inherit the parent/session model. If a fallback ever does occur, it should be surfaced (logged/visible), not silent.
Error Messages/Logs
No error is raised — this is a silent fallback. The only signal is in the agent transcript, where the per-message "model" field changes mid-run:
...,"agentId":"<id>","message":{"model":"claude-sonnet-5", ... // initial dispatch turns
...,"agentId":"<id>","message":{"model":"claude-fable-5", ... // resumed/continued turns (session model)
Count from one affected transcript:
own-turn sonnet records: 244
own-turn fable records: 15 (all at the tail, after the agent was resumed)
Steps to Reproduce
- Start a Claude Code session whose main model is NOT Sonnet (e.g. session model = Fable 5, or Opus).
- Launch a subagent with an explicit model override, e.g. Task/Agent with model: "sonnet". Confirm its turns run on Sonnet (inspect the agent transcript's per-message "model" field).
- Resume/continue that same agent — e.g. send it a follow-up via SendMessage (or trigger a mid-run interruption + continuation).
- Inspect the transcript for the resumed turns.
Expected: resumed turns still show "model":"claude-sonnet-5".
Actual: resumed turns show "model":"<session model>" (e.g. claude-fable-5) — the override was dropped.
Detection one-liner over an agent transcript:
grep -oE '"agentId":"<id>","message":\{"model":"[^"]+"' <id>.jsonl | sort | uniq -c
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.201 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
Impact: cost and predictability. Subagents deliberately dispatched on a cheaper model can silently finish on the (more expensive) session model with no indication, defeating model-tiering. It also makes model choice non-deterministic across a resume boundary.
Workaround: for model-sensitive continuation, avoid resuming an existing agent (SendMessage) — start a FRESH agent and re-pass the model override. After long/resumed runs, spot-check the transcript's per-message "model" field.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗