[BUG] Claude Code does not respect agent model definition, uses wrong model.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/17562
2. https://github.com/anthropics/claude-code/issues/13434
3. https://github.com/anthropics/claude-code/issues/16594

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

anyone?

Same issue here with team agents (TeamCreate + Task tool). Running Claude Code 2.1.37 on Linux WSL2 with parent model Opus 4.6. When spawning a teammate with model: "sonnet", the agent silently runs under Opus 4.6 instead. No error, no 404 — just silently ignored. See #24429 for full reproduction steps.

I had opposite problem today - Mine agent is defined with sonnet model, but it was executed with opus multiple times.

btw. I had there quite long description text. I made it shorter (2 liner) and I didn't see wrong model used there from that time.

I did some digging into the Task tool, and the main agent can and will override subagent models in tasks unpredictably.

Observed Behaviors:

1. Model parameter exists but undocumented

• Task tool schema includes model parameter
• Official documentation doesn't mention it

1. Inconsistent behavior

• Sometimes parameter works, sometimes ignored
• API 404 errors when short names not resolved to full model IDs

1. Agent definition model: not enforced

• Caller can override with Task tool model parameter
• No mechanism to enforce agent-defined model

Controlled test results confirming team-specific model override bug

Ran three controlled rounds on Claude Code v2.1.37 (macOS, Opus 4.6 parent) to isolate the behavior. Each agent was asked to self-report its model from its system prompt.

Round 1: Team dispatch, NO model parameter

| Agent | Expected | Actual | Match? |
|-------|----------|--------|--------|
| Geth (frontmatter: haiku) | haiku | Opus 4.6 | No |
| EDI (frontmatter: sonnet) | sonnet | Opus 4.6 | No |
| Liara (frontmatter: opus) | opus | Opus 4.6 | Yes (coincidental) |

Round 2: Team dispatch, EXPLICIT model parameter

| Agent | Requested | Actual | Match? |
|-------|-----------|--------|--------|
| Geth | haiku | Opus 4.6 | No |
| EDI | sonnet | Opus 4.6 | No |
| Liara | opus | Opus 4.6 | Yes (coincidental) |

Round 3: Standalone subagent dispatch (no team), EXPLICIT model parameter

| Agent | Requested | Actual | Match? |
|-------|-----------|--------|--------|
| Geth | haiku | Haiku 4.5 (claude-haiku-4-5-20251001) | Yes |
| EDI | sonnet | Sonnet 4.5 (claude-sonnet-4-5-20250929) | Yes |
| Liara | opus | Opus 4.6 (claude-opus-4-6) | Yes |

Conclusion

The model parameter on the Task tool works correctly for standalone subagent dispatches but is silently ignored for team-spawned teammates (via team_name + name parameters). All teammates inherit the parent's model regardless of explicit model param or agent frontmatter model: declaration.

This has direct cost implications — teams designed to use tiered models (haiku for simple tasks, sonnet for standard work) silently run everything at the leader's model cost.

Root cause analysis in #27038 traces it to the handleSpawnInProcess function where the resolved model value is computed but never passed to the runner.

Related: #27038, #24429, #24668

met issue like this.

version:2.1.72 (Claude Code)
sence: Ghostty
model: opusplan
status: in plan mode
issue: Explore subagent use opus but not haiku.
try-fix: Wrote some prompt that tell Claude code when it want to fire Explore subagent then use Haiku, not by inherit.
result: not work. I saw the gray text declare the Explore Agent used Haiku4.5, but actual Opus by capture http.

Hope u guys fix it, save my money!

@cheeselemon — this is a model alias resolution issue. I built claude-alias-patch that fixes the alias resolver so agent model definitions actually work. It also lets you register custom aliases beyond sonnet/opus/haiku via ANTHROPIC_DEFAULT_*_MODEL env vars.

Single install script, auto-patches your Claude instance. Tested and working — agents respect their frontmatter model field after patching.

Related but distinct bug: tmux backend strips [1m] context window from teammates

The tmux split-pane backend strips the \[1m]\ suffix when spawning teammates, giving them 200K context instead of 1M. This is distinct from this issue's model selection bug — here the model is correct but the context window variant is wrong.

Confirmed workaround (credit @Reasonably, confirmed on v2.1.92):

1. Add \"teammateDefaultModel": null\ to \~/.claude.json\
2. Run \/model opus[1m]\ in the lead session (NOT "Default (recommended)")
3. Don't pass \model\ when spawning teammates

Bug is tmux-specific — in-process mode and non-tmux terminals give teammates 1M without any workaround.

Canonical issue: #34421. Full details and before/after screenshots there.

Confirming this issue on CLI v2.1.114. Subagent model frontmatter and the Agent tool model parameter are both ignored for Opus specifically, while sonnet and haiku values still route correctly.

Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code CLI: v2.1.114
• Lead model: claude-opus-4-7 (direct Anthropic API, Max plan auth)
• 6 subagents defined under .claude/agents/*.md

Reproduction

1. In .claude/agents/{name}.md frontmatter, set the model using the full ID:

---
name: infra-manager
model: claude-opus-4-7
---

1. Invoke the subagent via the Agent tool with an explicit override:

Agent(subagent_type="infra-manager", model="opus", ...)

1. Ask the subagent to self-report its model (it reads the injected system prompt line The exact model ID is ...).

1. Observed: subagent reports claude-sonnet-4-6 regardless of frontmatter or Agent-tool argument.

Variations tested (all produce the same Sonnet result for Opus)

| Config | Result |
|---|---|
| frontmatter model: claude-opus-4-7 | Sonnet 4.6 (ignored) |
| frontmatter model: opus (alias) | Sonnet 4.6 (ignored) |
| Agent tool model: "opus" | Sonnet 4.6 (ignored) |
| Agent tool model: "sonnet" | Sonnet 4.6 (as expected) |
| Agent tool model: "haiku" | Haiku (as expected) |

So the bug is Opus-specific: sonnet and haiku routing paths are honored; only opus silently falls back to the default Sonnet.

Evidence (subagent self-report excerpt)
You are powered by the model named Opus 4.
The exact model ID is claude-sonnet-4-6.

The "Opus 4" display name is injected from the frontmatter, but the actual exact model ID line — which reflects the real runtime binding — shows claude-sonnet-4-6. This mismatch is the clearest signal that the frontmatter is cosmetic and the routing layer is not applying the Opus binding.

Workaround that works

Adding the following to settings.json restores Opus 4.7 for all subagents:

{
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-opus-4-7"
  }
}

After restart, every subagent self-reports claude-opus-4-7 and behaves accordingly.

Caveats for others hitting this:

• This env var forces a single model for every subagent — per-agent routing (e.g., Opus for infra-manager, Sonnet for strategy-advisor, Haiku for verifier) is lost.
• Dated suffix IDs such as claude-opus-4-7-20260416 return 404 model_not_found from the API; the undated claude-opus-4-7 is the only value that works here.

Questions for maintainers

1. Is the frontmatter/Agent-tool model application path implemented separately from the CLAUDE_CODE_SUBAGENT_MODEL env path? The asymmetry (env works, frontmatter silently ignored, Sonnet/Haiku aliases work, Opus alias does not) suggests the Opus alias is missing from the per-agent resolver table while present in the env resolver.

1. Any ETA for a fix that restores per-subagent Opus routing via frontmatter? Losing per-agent model differentiation is a meaningful regression for multi-agent setups that mix precision-critical (Opus) and lightweight (Haiku) roles.

Happy to provide full claude --debug logs or a minimal repro repo if useful.

Confirming this issue on CLI v2.1.114. Subagent model frontmatter and the Agent tool model parameter are both ignored for Opus specifically, while sonnet and haiku values still route correctly.
Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code CLI: v2.1.114
• Lead model: claude-opus-4-7 (direct Anthropic API, Max plan auth)
• 6 subagents defined under .claude/agents/*.md

Reproduction

1. In .claude/agents/{name}.md frontmatter, set the model using the full ID:

---
name: infra-manager
model: claude-opus-4-7
---

1. Invoke the subagent via the Agent tool with an explicit override:

Agent(subagent_type="infra-manager", model="opus", ...)

1. Ask the subagent to self-report its model (it reads the injected system prompt line The exact model ID is ...).
2. Observed: subagent reports claude-sonnet-4-6 regardless of frontmatter or Agent-tool argument.

Variations tested (all produce the same Sonnet result for Opus)
| Config | Result |
|---|---|
| frontmatter model: claude-opus-4-7 | Sonnet 4.6 (ignored) |
| frontmatter model: opus (alias) | Sonnet 4.6 (ignored) |
| Agent tool model: "opus" | Sonnet 4.6 (ignored) |
| Agent tool model: "sonnet" | Sonnet 4.6 (as expected) |
| Agent tool model: "haiku" | Haiku (as expected) |
So the bug is Opus-specific: sonnet and haiku routing paths are honored; only opus silently falls back to the default Sonnet.
Evidence (subagent self-report excerpt)
You are powered by the model named Opus 4.
The exact model ID is claude-sonnet-4-6.
The "Opus 4" display name is injected from the frontmatter, but the actual exact model ID line — which reflects the real runtime binding — shows claude-sonnet-4-6. This mismatch is the clearest signal that the frontmatter is cosmetic and the routing layer is not applying the Opus binding.
Workaround that works
Adding the following to settings.json restores Opus 4.7 for all subagents:

{
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-opus-4-7"
  }
}

After restart, every subagent self-reports claude-opus-4-7 and behaves accordingly.
Caveats for others hitting this:

• This env var forces a single model for every subagent — per-agent routing (e.g., Opus for infra-manager, Sonnet for strategy-advisor, Haiku for verifier) is lost.
• Dated suffix IDs such as claude-opus-4-7-20260416 return 404 model_not_found from the API; the undated claude-opus-4-7 is the only value that works here.

Questions for maintainers

1. Is the frontmatter/Agent-tool model application path implemented separately from the CLAUDE_CODE_SUBAGENT_MODEL env path? The asymmetry (env works, frontmatter silently ignored, Sonnet/Haiku aliases work, Opus alias does not) suggests the Opus alias is missing from the per-agent resolver table while present in the env resolver.
2. Any ETA for a fix that restores per-subagent Opus routing via frontmatter? Losing per-agent model differentiation is a meaningful regression for multi-agent setups that mix precision-critical (Opus) and lightweight (Haiku) roles.

Happy to provide full claude --debug logs or a minimal repro repo if useful.

Reporting the inverse direction on v2.1.139 Windows. Your issue: configured-Opus runs Sonnet. Mine: model picker shows Sonnet on first step, continues to reveal Opus on second step — every single agent-mode window, despite Sonnet being set in the agent configuration files. Billing ran Opus for 11 hours overnight. Filed as #58450 with screenshots. The model tier tracking between display and billing is unreliable in both directions.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.