[BUG] Agent frontmatter `model: opus` runs the parent session model instead of stepping down to the newest org-allowed Opus (per-invocation `model: opus` param steps down correctly)

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 an agent definition pins model: opus and the alias's newest family member (Opus 5) is restricted for the org, spawning that agent runs the parent/session model (claude-fable-5) instead of stepping down within the family to claude-opus-4-8.

The restriction is enforced by setting the evironment variable $env:ANTHROPIC_DEFAULT_OPUS_MODEL = "claude-opus-4-8[1m]" (PowerShell example before invoking claude.exe). The override is confirmed using /model, Claude Code correctly shows the restricted model version.

The family step-down does work when opus is passed as the Agent tool's per-invocation model parameter — only the frontmatter-pin path falls back to the parent model. This looks like the 2.1.222 changelog fix — "Fixed org-restricted model: opus-style subagent and teammate family aliases dropping to the parent model instead of stepping down to the newest org-allowed model in the family" — not covering frontmatter pins on (at least) plugin agents. 2.1.223 added a warning for the parent-model fallback, but no warning surfaced in our session.

Control observations — same session, so the environment is held constant

| Spawn | Model requested | Model actually run | Verdict |
|---|---|---|---|
| Agent tool, subagent_type: general-purpose, param model: "opus" | opus (param) | claude-opus-4-8 | ✅ family step-down works for params |
| Forked skill → agent pinned model: sonnet (frontmatter) | sonnet | claude-sonnet-5 | ✅ frontmatter pin honored when unrestricted |
| Forked skill → agent pinned model: haiku (frontmatter) ×2 | haiku | claude-haiku-4-5 | ✅ frontmatter pin honored when unrestricted |
| Agent tool, subagent_type: epic-worker:bug-fixer (frontmatter model: opus) ×2 | opus (frontmatter) | claude-fable-5 (parent) | ❌ parent model instead of claude-opus-4-8 |

Impact

Any plugin that pins agents to model: opus silently runs them on the session model for orgs without Opus 5. In our case that is a silent upgrade onto a Mythos-class session model — bypassing the plugin's cost/capability design; with a cheaper session model it would be a silent downgrade of agents pinned up for quality. The substitution is invisible: no warning, no model field in the spawn record.

Evidence (session forensics)

Session c4b4b8e9-da6b-4662-9733-f6d07c98eb25 (project D--DotPipeline), CC 2.1.228.

# the two pinned-agent spawns — meta records type but no model (inherit):
agent-a18f3beebb585b92d.meta.json: "agentType":"epic-worker:bug-fixer" "spawnDepth":1
agent-a0e1d7c9ff1d87257.meta.json: "agentType":"epic-worker:bug-fixer" "spawnDepth":1

# actual models per transcript ("model":"..." on assistant messages):
agent-a18f3beebb585b92d.jsonl : claude-fable-5   (62 messages)   <- pin was model: opus
agent-a0e1d7c9ff1d87257.jsonl : claude-fable-5   (2 messages)    <- pin was model: opus
agent-abed2c5bf611d3b46.jsonl : claude-opus-4-8  (param model: "opus", general-purpose)
agent-a624e7c973fd0aab5.jsonl : claude-sonnet-5  (pin model: sonnet)
agent-a0f238fb191f79671.jsonl : claude-haiku-4-5 (pin model: haiku)

The agent definition (installed cache copy) frontmatter, part of epic-worker plugin:

name: bug-fixer
model: opus
disallowedTools: mcp__plugin_atlassian_atlassian

The skill definition (installed cache copy) frontmatter, part of epic-worker plugin:

name: group-bugfix
context: fork
agent: epic-worker:bug-fixer
allowed-tools: Read, Grep, Glob, Write, Edit, Bash, PowerShell, Agent, Skill

switchModelsOnFlag: false is set in the user's settings; per the docs its scope is content-safety-flag fallback only, and the control rows above show it does not explain the asymmetry.

Additional observation (possibly its own issue)

Invoking a context: fork plugin skill as a slash command did not engage the harness fork at all: the skill body was injected into the main conversation and the main model spawned the target agent manually via the Agent tool (which is where the pin loss above bit). Skill-tool invocations of fork skills in the same session forked properly and wrote agent-<id>.forked-skill.json markers; the slash-command path left no marker. If slash-command invocation is supposed to fork context: fork skills the same way, that dispatch path appears broken too.

What Should Happen?

Frontmatter model: opus should resolve exactly like the per-invocation param: to the newest org-allowed model in the family (claude-opus-4-8), not to the parent model. At minimum, the 2.1.223 warning should fire so the substitution is visible.

Error Messages/Logs

Steps to Reproduce

1. Org without Opus 5 access; start a session on claude-fable-5.
2. Install a plugin whose agent <plugin>:<agent> carries model: opus in frontmatter.
3. Spawn it: Agent tool, subagent_type: "<plugin>:<agent>", no model parameter.
4. Observe: the subagent's transcript records "model":"claude-fable-5" on every assistant message; its agent-<id>.meta.json carries no model field (inherit). Agent type resolution is correct — system prompt and tool limits from the definition are applied; only the model pin is lost.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.228

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Related

• Changelog 2.1.222: the same symptom fixed for "subagent and teammate family aliases" — the fix evidently does not reach frontmatter pins of plugin agents.
• Changelog 2.1.223: warning added when a fork/workflow agent's "requested subagent model is restricted and the parent model runs instead" — did not fire here.
• #83133 (bare agent: refs in fork skills falling back to general-purpose) — distinct issue; agent type resolution was correct in this session (namespaced refs).