Model Selection in Agent and Skill Definitions
Every agent definition should explicitly set its model. Without it, sub-agents inherit the parent session's model — and 30 Opus sub-agents running simultaneously is an expensive accident.
Quick Reference
- →model field in AGENT.md: sonnet, opus, haiku, or inherit
- →inherit: sub-agent uses parent session's model — dangerous when parent is Opus
- →Skills don't directly set model — they run in main context or fork to an agent
- →Cost impact: 30 Haiku subagents vs 30 Opus subagents = 19x cost difference
- →Decision rule: match model to the hardest sub-problem in the agent's task
- →Exploration agents → haiku, Code reviewers → sonnet, Security analysts → opus
Why Per-Agent Model Selection Matters
When Claude Code spawns sub-agents, each agent runs independently. Without an explicit model field, agents inherit the parent session's model. If you are running Opus as your main session and spawn 30 sub-agents to analyze files in parallel, all 30 run on Opus — whether they needed it or not.
A read-only codebase exploration agent does not need Opus's reasoning depth. A security reviewer analyzing authentication code genuinely does. The model field in AGENT.md is how you encode that distinction into the agent itself, so it is not left to chance.
model: inherit is the default. It means 'use whatever the parent is using.' If a developer starts a session with Opus and forgets that exploration agents inherit, every codebase scan runs on Opus. Be explicit.