Feature: Model selection in skill frontmatter
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 11 comments · opened Feb 5, 2026 · closed Aug 17, 2026
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
modelfield 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
modelfield = 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.
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Ran into this today. I have a
/clean-goneskill (prunes local branches marked [gone] plus their worktrees) withmodel: haikuin 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.
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.
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.
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
@jusdespommes — skill frontmatter model selection is limited because the enum only accepts sonnet/opus/haiku. I built claude-alias-patch that extends the enum to accept any custom alias registered via
ANTHROPIC_DEFAULT_*_MODELenv vars in~/.claude/settings.json.After patching, you can declare
model: geminiormodel: gpt(or any alias you define) in your skill frontmatter and it'll resolve correctly. Single install script — auto-patches your Claude instance.Would really like this bug to be closed out.
Is this really not supported?
(Came to post a new feature request and found this is already requested. Great!)
This is very much needed. We will wonder how we ever lived without such a simple choice.
In a different context -- people are doing the same thing: using a faster cheaper model to do the trivial stuff and seeing massive gains in overall efficiency -- https://www.mendral.com/blog/frontier-model-lower-costs
Please fix this, allow in main session for multi-agents on different models, codex is allowing that
Please fix this