Two lines of YAML at the top of a skill file will make Claude Code run that skill on a different model than the rest of your session:

model: fable
effort: xhigh

No JavaScript, no wrapper script, no MCP server. These are documented frontmatter fields, and Claude Code honors them by actually calling a different model — not by asking the current one to try harder.

That’s worth having because planning and executing want different things. Planning wants a model that reads twenty files before it opines and notices the constraint that breaks your approach. Execution wants throughput on work you’ve already specified. Paying execution rates for architecture is the expensive mistake — the kind you find three hours later.

But before you build anything, there’s a built-in that already does most of this.

The secret menu item

/model opusplan

opusplan is a built-in alias. In plan mode it uses opus; when you exit plan mode and start executing, it switches to sonnet. You can set it at launch with claude --model opusplan, or as your model setting so every session starts that way. On tiers where Opus gets the 1M context upgrade, plan mode gets it too; opusplan[1m] forces the big window for both phases.

You have to type it, though. Run /model with no argument and opusplan isn’t in the picker — the list shows individual models, and this is a mode spanning two of them. It’s documented in the aliases table; it just isn’t discoverable anywhere you’d actually look. There’s been an open feature request to add it to the menu since February.

So it’s a secret menu item: fully supported, zero configuration, invisible unless someone tells you the name. Consider this me telling you.

Try it before building anything. It’s one command, it needs no files, and for most work the opus-plans/sonnet-builds split is the right one. Plenty of people who think they need a custom setup need this instead.

Where it stops

The pairing is fixed. Opus plans, Sonnet builds, and neither half is yours to choose. There’s no fableplan — no way to put Claude’s most capable model, the one built for tasks that don’t fit in a single sitting, on the planning half.

It’s also all-or-nothing at the plan-mode boundary, so every trip through plan mode pays for Opus, including the ones where you’re planning a two-file change and already know the answer. And it says nothing about effort: plan mode runs at whatever level your session is set to.

A planning skill gives you all three — which model, how hard it thinks, and when it fires — plus one thing opusplan can’t do at all, which I’ll get to.

Building fableplan

.claude/skills/deep-plan/SKILL.md:

---
description: Investigate the codebase, then produce a detailed implementation plan
disable-model-invocation: true
model: fable
effort: xhigh
---

You are orchestrating. Delegate the reading; keep the judgment.

Spawn subagents for investigation and name a model on each one. They
inherit your model by default, which is not what you want for file
reading:

- `haiku` at `low` effort — mechanical retrieval. Find every caller,
  list the migrations, collect the config values.
- `sonnet` — read a code path and report how it actually works,
  including the tests and what they assume.
- `opus` — a hard sub-question where being wrong is expensive: the
  concurrency story, the ordering constraint, the failure mode nobody
  wrote down.

Run the independent ones in parallel. Then do the part that doesn't
delegate: reconcile what came back, name the constraints and where they
were found, and write the plan — the files that change, in what order,
what each change is for, and what could break.

Flag anything no subagent could verify by reading the code. I'd rather
have an open question than a guess.

Type /deep-plan and the plan gets written in your main session, in the conversation where you’ve been building context all along. It lands where you can argue with it.

Three of the four fields carry the setup; description is just what Claude reads in skill listings. model: fable takes the same values as /model — an alias, a pinned ID like claude-opus-5, or inherit to leave the active model alone. effort: xhigh overrides your session’s level while the skill runs; Fable defaults to high, so this is one deliberate step up, and it’s the right place to spend, since what’s left on Fable after delegation is a handful of judgment-heavy turns. disable-model-invocation: true means only you can fire it. Without that, a skill advertising “a detailed implementation plan” is exactly what an agent decides is relevant, and you find out when the bill arrives.

The override applies for the rest of the current turn and is never saved, so the handoff needs no cleanup: run /deep-plan from a Sonnet session, get a plan from Fable, start executing, and you’re back on Sonnet without touching anything. Doing it by hand doesn’t work this way — /model fable is sticky, saving to your user settings so sessions keep starting on Fable until you change it back. The failure mode isn’t dramatic. You just forget, and a week of small edits runs on a model you picked for one architecture question.

The cascade

Here’s the part opusplan can’t do: the planner can spend other models’ time instead of its own.

The reason to want Fable planning isn’t that it writes better prose. It’s that it investigates before it commits — and investigation is mostly reading, which is the cheapest work in the job. So the shape you want is Fable deciding what needs knowing and holding the plan, with subagents doing the legwork. Fable earns its rate on the part that can’t be parallelized: what the constraints mean and what order the work has to happen in.

The default works against you. A subagent’s model defaults to inherit — the main conversation’s model — and your skill is the main conversation while it runs. So a skill on Fable spawns Fable subagents unless you say otherwise. Fan out five investigators and you’ve paid Fable rates five times over for file reading, which is the exact work you delegated to make cheaper.

That’s why the model names are written into the skill body:

The built-in Explore agent already does some of this for you — it inherits your model but caps at Opus on the Claude API, so Explore under Fable runs Opus. Agents you name yourself get no such cap.

Before you rely on it

• Fable 5 needs Claude Code v2.1.170 or later, and isn’t available under zero data retention, where the picker omits it or shows it disabled.
• An organization allowlist can silently drop the override. If availableModels excludes the model you named, the value isn’t used and the session keeps its current model — the skill still runs, just not where you think it does. Enterprise admins can cap effort levels per model too, and a higher level runs at the cap instead — silently in non-interactive runs, with a warning in interactive ones.
• Environment variables outrank frontmatter. CLAUDE_CODE_SUBAGENT_MODEL beats any model the skill names for a subagent; CLAUDE_CODE_EFFORT_LEVEL beats any effort level. Check both before debugging a cascade that seems to be ignoring you.
• Effort is per model and per agent. The scale is calibrated per model, so xhigh on Fable isn’t xhigh on Sonnet, and subagents carry their own effort field, documented as defaulting to the session level. Whether a skill’s override reaches them isn’t spelled out anywhere, so set it explicitly on the subagent and don’t wonder.
• Don’t reach for context: fork. It runs the whole skill in a subagent, which drops your conversation history — and for planning, the history is the input. Fanning out sends the reading away; forking sends the planner away.

Which one to build

If you want better plans and don’t want to think about it, /model opusplan and move on. It’s a command, not a project.

Build the skill when you want a planner you chose, at an effort you chose, spending cheaper models’ time on the reading. The frontmatter is the smaller half of that file. The instructions underneath — what to investigate, what to delegate, what to refuse to guess at — are the part worth iterating on.

Verified against the skills frontmatter reference, subagent docs, and model configuration docs.