Subagents self-delegate to a different model via skill-file prose

Environment

• Claude Code, session model set to Claude Sonnet 5 (via /model and global settings.json "model": "sonnet")
• Multi-agent workflow: an orchestrator dispatches background subagents via the Agent/Task tool
• OS: Windows (client); work executes against a Linux VPS

Summary

Subagents dispatched WITHOUT any model parameter — expected to inherit the parent session's model (Sonnet 5) — autonomously spawned NESTED child subagents running a DIFFERENT model, triggered by reading model-requirement prose inside a skill's SKILL.md file mid-task. The orchestrator passed no model override anywhere in the dispatch chain and had zero visibility into the switch until the subagents self-reported it in their final messages. This defeats model attribution, usage/cost predictability, and any expectation that a "Sonnet session" runs Sonnet.

Reproduction (clean, 3-agent sample, 2 of 3 fired)

1. A skill's SKILL.md contained prose: "MODEL REQUIREMENT: this skill MUST only be run with Opus. Never delegate to Sonnet or Haiku." This is descriptive text in the skill body, NOT enforced config — there is no model pin in any agent config, no .claude/agents/*.md, no model field in the Python tooling, and no model parameter in the dispatch calls.
2. From a Sonnet 5 session, the orchestrator dispatched 3 single-task background subagents to run a verification flow. No model parameter passed to any of them.
3. Result: 1 subagent ran the work itself on its inherited model (Sonnet 5). The other 2 each read the SKILL.md "MUST be Opus" line mid-task and, to comply, spawned a nested Opus child subagent to do the actual work — rather than proceeding as Sonnet or surfacing the conflict.
4. Verbatim subagent self-reports:

• "Run via the required Opus subagent (trivia-verifier skill mandates Opus-only for verification work; I run as Sonnet 5, so this could not be done directly)"
• "the skill hard-requires Opus ... so I delegated execution to an Opus subagent rather than running it myself."

Why it matters

• Silent model switching one layer below the orchestrator, with no visibility until post-hoc self-report.
• Model attribution is unreliable: work in a Sonnet session may execute on Opus (or plausibly Haiku, via the same mechanism if any instruction in the chain named a cheaper model). In a prior run of this same pipeline, ~97 web searches billed to claude-haiku-4-5 under a Sonnet-5 session with no in-repo instruction naming Haiku — unexplained, and this self-delegation mechanism is a candidate explanation, not a confirmed one.
• Invalidates A/B tests that depend on knowing which model produced an output.
• Cost/usage becomes unpredictable: a cheaper session can silently escalate to a pricier model, or vice versa.

What I'd expect instead

• Subagents should not change execution model based on unstructured prose in a skill file.
• Any model switch (self-delegation to a nested child on a different model) should be surfaced to the orchestrator at dispatch time and reflected in usage attribution — not discoverable only via the subagent's closing narration.
• Prose model-preferences in skill files should be advisory to the human, not self-executing instructions that agents satisfy by spawning differently-modelled children.

Severity

High for anyone running multi-agent pipelines where model identity affects correctness, cost, or evaluation validity.