Feature: Model selection in skill frontmatter

[jusdespommes]

Allow skills to declare a preferred model via a model field in frontmatter. Claude Code's skill loader would switch the active model for that skill's execution.

---
name: create-feature-branch
description: Create standardised feature branch
model: haiku
---

Why

Many skills are mechanical (git operations, ticket creation, checklist validation) and don't need the most capable model. The only workaround today is dispatching to a subagent via the Task tool — but the orchestration overhead (Opus reading the skill, deciding to dispatch, processing the result) can cost more than just letting Opus do the work directly.

A native model switch at the skill loader level would:

• Reduce cost — simple skills run on Haiku/Sonnet instead of Opus
• Reduce latency — faster models respond faster for mechanical tasks
• Zero orchestration tax — no subagent dispatch overhead

Suggested behaviour

• model field sets the default for that skill's execution
• User settings can override per-skill (e.g. force Opus for everything, or remap specific skills)
• No model field = unchanged behaviour (uses session model)

Real-world assessment

Assessment of ~20 custom skills showed roughly:

• ~5 Haiku — branch creation, tag checkout, ticket creation (mechanical, template-driven)
• ~9 Sonnet — code review checks, test validation, release readiness (pattern matching against rules)
• ~5 Opus — brainstorming, architectural planning, debugging (deep reasoning, creative exploration)

That's significant cost savings for teams using skills heavily.

[sergiojrdotnet]

Ran into this today. I have a /clean-gone skill (prunes local branches marked [gone] plus their worktrees) with model: haiku in the frontmatter. It's purely mechanical git operations, yet it executed on Opus and consumed ~2% of my session limit for a trivial cleanup!!!

The model frontmatter field is already documented in the skill spec but doesn't appear to be respected at the skill-loader level, the skill runs on whatever model the session is using. The only current workaround is dispatching to a subagent via the Task tool, but as the issue author notes, the orchestration overhead can negate the savings.

Native model switching at skill invocation would be a significant cost/latency win for teams with many mechanical skills.

[thomashillman]

This got a massive upvote from me. It would be far more efficient for users to be able to specifically define model usage based on what the task (skill) is doing. Many tasks work perfectly fine with Haiku. It would also be great if you could do this multiple times in a skill when different models would perform better against specific parts of it.

[thomashillman]

Also just to add this would be a win for both users and Anthropic. Yes people would use less of their subscription or API costs would fall but it would also save Anthropic costs on inefficient model usage.

[jimmy-harden]

Looks like this needs to be a bug now rather than a feature - it's apparently already supported according to current documentation:
https://code.claude.com/docs/en/skills#frontmatter-reference

But it's definitely not working as it should