I ran a skill and got this:
There's an issue with the selected model (claude-haiku-4-5-20251011).
It may not exist or you may not have access to it.
Run /model to pick a different model.It had been working fine the day before. My first thought was that something had changed in the policy. I’d been running my wiki’s index and digest pipelines a lot lately, burning through tokens fast, and I figured I’d hit some kind of limit. Which made it worse that the error showed up right after I’d tried to cut costs.
Why I Started Messing With This
My daily cron jobs keep running on Opus or Sonnet. Index, digest, backup — none of them are heavy tasks individually, but when the session model is expensive and everything funnels through it, the quota drains fast.
Then I noticed something in the docs: you can set a model: field inside a skill file. That means each skill can run on a fixed model, regardless of what’s active in the session. No reason to run rsync through Opus. So I figured I’d set a model per skill and drop the default session from Opus to Sonnet — that should help quite a bit.
I handed it off to Claude. “Go through my skills, pick a reasonable standard, and set the model for each one.” Figured it would sort things out well enough, and forgot about it.
That Decision Came Back as an Error
The next day, a skill failed with that message. When I dug into it, two things had gotten tangled together at once.
One was the credit thing. The 1M context window costs extra — once you go past 200K, Claude Code prompts you to switch to credit-based usage. This was erratic. Sometimes the warning showed up, sometimes it didn’t. Under 200K it stays quiet, and it only triggers when you cross into the longer context window, so it felt like the restriction kept appearing and disappearing.
The other issue was the actual culprit. Because the model config was now inside skill files, I needed to migrate from the old commands/ format to skills/, and the two formats aren’t quite identical.
Here’s what made it harder: asking Claude about it didn’t help. If something changed yesterday or today, it’s past the training cutoff — Claude doesn’t know. What I actually got was confident, wrong information, like “you can’t dynamically change models inside a skill.” The kind of general-knowledge answer that sounds plausible but has nothing to do with what just happened in my environment. Missing a tool update hits the same blind spot.
So I Tried Everything One by One
There were no examples showing what to put in the model: field — whether it should be the full model ID, an alias, and if an alias, what to write exactly.
The full ID gave me that error. Looking closely, I’d put claude-haiku-4-5-20251011, but the real ID is claude-haiku-4-5-20251001. One digit off at the end — 11 vs 01 — and the model doesn’t resolve. Full IDs are fragile that way.
But the typo wasn’t the full picture. Digging into it later, I found the model: field only actually takes effect in exactly two situations: when it’s defined at the moment you call the skill directly, or when you inject a model explicitly through a subagent — Workflow or the Agent tool. Call one skill from inside another, or just leave a model: tag sitting in todo.md, and it does nothing — because what gets inherited is the model at the point of invocation, not the point where the field was written. My error hit at the exact moment I ran /ingest through a workflow, which internally tries to spawn ingest-chats as a haiku subagent. That injection is the moment the model ID actually gets validated, and mine was a typo, so it blocked right there.
Aliases worked. Three of them: opus, sonnet, haiku. Once that was confirmed, the rest came together quickly.
One Criterion for Everything
With aliases sorted, the real question was which skill gets which model. I started trying to judge each task individually, but that got confusing fast. So I boiled it down to one question.
If this skill produces wrong output, how much does it cost to re-run it?
If blog-seed generates a bad template, I fix one line and re-run. A cheap model is fine. If blog-draft turns in a terrible draft, I start over from scratch. That’s not where you cut costs. Easy to fix means cheap model. Expensive to fix means good model. That was the whole framework.
That sorted everything into three tiers.
Haiku for pure I/O with no judgment required. ingest-chats (runs a script), blog-seed (generates a template), backup-global-skill (rsync), blog-fix and blog-update (field edits).
Sonnet for reasoning, classification, and lightweight writing. digest (raw → wiki), blog-mine (search and score), blog-publish (metadata validation, link generation), lint (consistency check).
Opus for creative work and complex design. blog-draft and blog-rewrite (actual writing), plan and plan-steps (dependency-aware planning), docs-spec (product design pipeline).
After the first ten or so, the pattern clicks. The question isn’t “Haiku or Sonnet?” — it’s “creative or not?” I have 39 skills now: Haiku 9 / Sonnet 20 / Opus 10.
How It’s Actually Set Up
Just add a model: field to the skill file’s frontmatter.
---
model: haiku
description: Collect chat session logs and save as markdown
allowed-tools: Bash, Read, Write
---
# /ingest-chats — Ingest Chat Sessions
...Three valid values: haiku, sonnet, opus. Full model IDs have version dates in them — one digit off and you get that error. Aliases are safer.
Once this field is set, that skill ignores the default session model and runs on the one you specified. My setup: default session is Sonnet, then override to Haiku or Opus per skill as needed.
Token Usage Actually Dropped
Before, everything ran on whatever model happened to be active. If I had an Opus session open, file rsync ran on Opus. Template copy ran on Opus. “It worked on Opus” just meant Opus ran it.
Now the default is Sonnet, and each skill has its model locked in. I/O-heavy work like ingest-chats and blog-seed runs on Haiku. Medium-weight tasks like digest and template generation run on Sonnet. My daily cron jobs now cost roughly half what they used to.
One more thing came with the tiers: which work actually matters becomes visible. Start with Haiku, step up to Sonnet if it falls short, reach for Opus when Sonnet isn’t enough. When everything runs on Opus, the important work looks the same as the trivial work.
The real lesson here is separate from all of that. For anything that changed in your own environment recently, don’t ask the AI. Just try the aliases one by one. That’s faster.