[BUG] Skill subagent inherits parent's 1M-context tier but not extra-usage entitlement

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 slash command / skill declares model: "sonnet" (or any non-parent model) in its frontmatter, and the parent session is running on Opus 4.7 with the 1M-context flag (claude-opus-4-7[1m], with /extra-usage already enabled for that SKU), the spawned subagent runs as claude-sonnet-4-6 + 1M context. Sonnet-4-6 + 1M is a separate extra-usage SKU that requires its own /extra-usage opt-in — the gate fires immediately and the subagent dies before producing any output:

API Error: Extra usage is required for 1M context · run /extra-usage to enable, or /model to switch to standard context

This breaks the entire purpose of the model: directive. Pinning a cheaper model (e.g. for typecheck/lint loops) is a token-saving pattern; the silent 1M-context inheritance re-promotes the subagent to a premium tier and renders the directive effectively unusable for any user on a 1M-context parent unless they have separately opted into /extra-usage for every downstream model they might subagent into.

A Stop hook calling such a skill (e.g. quality_gates.py → /typecheck) ends up in a tight Ran 3 stop hooks loop because the gate keeps failing on the API error, not the underlying check.

What Should Happen?

When a subagent declares a different model than the parent, its context tier should not silently inherit the parent's premium tier. Reasonable options (any one would resolve this):

1. Default to standard tier: subagent runs on the new model's default context size (e.g. 200K for Sonnet) unless explicitly overridden.
2. Explicit per-skill context syntax: e.g. model: "sonnet@200k" or a separate context: "standard" | "1m" frontmatter key.
3. Auto-fallback with warning: if the extra-usage gate would block, fall back to standard context with a one-line stderr/log warning instead of failing the subagent.

Today the only workaround is to remove the model: directive entirely (subagent inherits parent + parent's already-paid extra-usage), which defeats the cost-saving intent of declaring a cheaper model in the first place.

Error Messages/Logs

● Ran 3 stop hooks
  ⎿  Stop hook error: Typecheck failed. Run `/typecheck` to see errors and fix them.

● Skill(/typecheck)
  Successfully loaded skill · 5 tools allowed · claude-sonnet-4-6
  API Error: Extra usage is required for 1M context · run /extra-usage to enable, or /model to switch to standard context

Steps to Reproduce

1. Have /extra-usage enabled for claude-opus-4-7 1M-context tier (so the parent session works on 1M).
2. Start a Claude Code session with the 1M-context Opus model: claude --model opus and confirm claude-opus-4-7[1m] in the status.
3. In a project, create ./.claude/commands/typecheck.md with frontmatter:

``yaml
---
allowed-tools: Bash, Read, Edit
model: "sonnet"
description: "Run type checking"
---
# Type Checking Skill
...
``

1. From the Opus 1M session, invoke the skill (e.g. via the Skill tool or /typecheck).
2. Observe the subagent loads with claude-sonnet-4-6 and immediately errors with the extra-usage message — even though /extra-usage is enabled for Opus, it is not enabled for Sonnet-4-6 + 1M.
3. (Bonus repro: wire the same skill into a Stop hook → the session enters the 3-stop-hook loop because the gate can never succeed.)

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

2.1.133 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Workaround applied locally: removed the model: line from the project's typecheck.md so the subagent inherits the parent's Opus 1M tier (already paid via /extra-usage).
• The /extra-usage gate appears to be per-model + tier, not session-wide. That is reasonable from a billing standpoint but not surfaced in the Skills frontmatter contract — there is no visible way for a skill author to say "use Sonnet but at standard context."
• This is more painful for users on 1M-context parent sessions because the inheritance happens silently and the only error surface is at API call time.

<signature>🦀 sent by Claude Code</signature>