[BUG] fork: true in command frontmatter ignores model override, causes rate limit with Opus 1M default

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 the default model is Opus 1M (claude-opus-4-6 with 1M context) and a slash command specifies model: sonnet with fork: true in its frontmatter, the forked subagent immediately hits a rate limit error. This happens even when the session has just started and context is nearly empty.

What Should Happen?

The forked subagent should use the model specified in the command frontmatter (sonnet), not the parent session's model (opus 1M). The command should execute without rate limit errors.

Error Messages/Logs

Rate limit error immediately after fork spawns

Steps to Reproduce

1. Set default model to Opus 1M (claude-opus-4-6 1M context)
2. Create a command file with this frontmatter:

``yaml
---
model: sonnet
fork: true
---
``

1. Start a new session (minimal/empty context)
2. Run the slash command
3. Result: Rate limit error immediately

What works (no error):

• model: opus + fork: true → ✅ works (same model as parent)
• model: sonnet + fork: false → ✅ works (no forking)
• model: sonnet + fork: true with non-1M default (e.g. regular Opus) → ✅ works

Only the combination of Opus 1M as default + model: sonnet + fork: true triggers the error.

Claude Model

• Other

Default model: Opus 4.6 (1M context). The bug is about model override via command frontmatter being ignored when fork: true.

Is this a regression?

I don't know

Claude Code Version

2.1.77 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Ghostty + tmux

Additional Information

The likely cause is that fork: true spawns the subagent using the parent session's model (Opus 1M) instead of the model specified in the command frontmatter. Evidence:

• Empty context rules out "context too large for Sonnet" as a cause
• model: opus + fork: true works → fork itself is not the problem
• model: sonnet + fork: false works → Sonnet access is not the problem
• model: sonnet + fork: true with regular Opus default works → Sonnet + fork is fine in general
• Only Opus 1M default + model: sonnet + fork: true fails → fork inherits Opus 1M instead of respecting the model override, and Opus 1M has stricter rate limits