Chapter 17: Orchestrating Models: Cost Without Compromise#

Everything in this part has been about capability — what Claude Code can do once you push it. This last chapter is about doing it economically, because capability you cannot afford to run is capability you will not use. Most people pick one model and run everything through it, and that is the expensive mistake in both directions: run everything on the cheap model and the hard calls come out mediocre; run everything on the frontier model and you burn your usage window on work a lighter model would have nailed.

Chapter 15 introduced the lineup; this chapter conducts it. You already know the four tiers and that /model switches between them. Here I want to hand you two named plays — escalate up when a decision is expensive, push down when the work is mechanical — so that a single session spends its expensive thinking only where it earns its keep.

Know your lineup#

Here is how I rank the four models on the three things that actually decide which one to reach for. Rankings: higher is better; a higher cost score means better value (cheaper).

In short: Haiku is fast and cheap, built for mechanical grunt work. Sonnet is the capable everyday default — it is what the Pro plan gives you, and it clears most of this book without complaint. Opus is the smart tier, for hard reasoning and taste-sensitive work. Fable is the frontier, for the hardest calls and the final review.

Treat those numbers as my personal judgment, not a spec sheet. They are subjective, and they will drift as the models change — the shape of the trade-off is what matters, not the exact digits. Switching between them is one command, mid-session, exactly as Chapter 15 covered:

Inside Claude Code:

/model opus

Play one: the Advisor (escalate up)#

The first play is how you run cheap without being cheap on the calls that matter. The advisor pairs your main model with a stronger one that Claude consults at the moments that decide quality — before it commits to an approach, when the same error keeps recurring, and before it declares a task done. The advisor sees the full conversation and hands back guidance the main model then applies.

You set it three ways. In a session:

Inside Claude Code:

/advisor opus

That saves Opus as your advisor. Prefer to set it once and forget it? Put it in settings:

In your settings.json:

{
  "advisorModel": "opus"
}

Or set it at launch with claude --advisor opus. To turn it back off, run /advisor off.

One nuance worth internalizing: the command only sets the advisor. Claude decides when to actually consult it, so you are not paying for a second opinion on every turn. If you want one at a specific point, just ask for it:

Say to Claude:

Consult the advisor before you continue.

The advisor must be at least as capable as your main model. Sonnet main with an Opus advisor is the sweet spot; Sonnet with Fable, or Haiku main with an Opus advisor, both work too. Opus can advise Opus, and Fable only accepts Fable as its advisor. This is why the pairing costs less than simply running the stronger model throughout — a fast main model with a strong advisor pays the advisor’s rate only at decision points, not on every token.

One honest caveat: the advisor is currently experimental, so expect it to change. It works on your normal Pro or Max subscription out of the box — you do not need pay-per-token API access for it. The only place it is not offered is if you reach Claude through a cloud reseller like Amazon Bedrock, Google Cloud, or Microsoft Foundry, which most people never touch.

Play two: delegation (push down)#

The second play runs the other direction. You keep a frontier model in the driver’s seat and let it hand the mechanical work down to right-sized subagents. There are two payoffs. The obvious one is cost — cheap models do the grunt work at a fraction of the price. The quieter one is context: a subagent’s work never enters your main window, so the main context fills more slowly, which means longer sessions before you have to compact, which is savings again. And frontier models are the ones that write the crisp, unambiguous briefs a subagent needs to succeed on the first try.

So who decides which model does what? There are two schools, and I teach both because they suit different temperaments.

Prescriptive routing — you write the rules into your CLAUDE.md and Claude follows them. This is the framework I adapted from the developer Theo (t3.gg). Here is the core of it:

In your CLAUDE.md:

## Model routing
- These defaults are not limits: escalate to a smarter model
  whenever the work needs it, without asking me first.
- For anything that ships, intelligence beats taste beats cost —
  cost is only the tie-breaker. Judge the output, not the price tag.
- Bulk and mechanical work (clear-spec implementation, data
  analysis, migrations) → the cheapest capable model.
- Anything user-facing (UI, copy) → a high-taste model.
- Reviews of plans and implementations → Opus or Fable.

The mindset behind those rules matters more than the rules themselves: escalating costs less than shipping mediocre work, so you have standing permission to spend up.

Delegated routing — instead of naming models, you hand Claude the heuristics and let it pick per subagent. This comes from superpowers, the same plugin from Chapter 4:

Inside Claude Code:

/plugin install superpowers@claude-plugins-official

Its subagent-driven-development skill hands Claude the routing guidance directly: use the least powerful model that can handle the job; match the model to task complexity — mechanical one-to-two-file work goes cheap, integration and judgment go mid-tier, architecture and the final review go to the most capable; and remember that turn count beats token price. The cheapest model can take two to three times the turns on a multi-step job and cost more in the end, so mid-tier is the floor for anything that is not trivial. The point is that an Opus main can hand a trivial rename down to Haiku on its own judgment, without you writing a rule for it.

When you do want to pin a subagent to a specific model, it is one line in that subagent’s definition file:

In a subagent file (~/.claude/agents/bulk-renamer.md):

---
name: bulk-renamer
description: Mechanical find-and-replace across many files.
model: haiku
---

A word on Haiku, because the two schools disagree. My line is that Haiku is exactly right for trivial delegated work — bulk renames, simple lookups, transcribing a plan that already contains the code. Theo’s stricter rule is “never use Haiku” for anything that ships or reasons. Both are defensible; I lean permissive and let the task decide.

Which tool when#

Four tools, four jobs — keep them straight:

• /advisor — a second opinion at decision points. Claude triggers it; you set it once.
• opusplan — Opus during plan mode, then Sonnet for execution. Smart thinking, cheap doing.
• A subagent with model: set — a chosen model for a whole delegated subtask.
• /model — switch the model for everything going forward.

You turn on opusplan the same way you switch any model:

Inside Claude Code:

/model opusplan

That is the model-orchestration layer. For the multi-agent machinery it sits on top of — background agents, agent teams, dynamic workflows — see the menu in Chapter 15.

The takeaway#

A session is not one model. It is a small team you direct — a fast worker for the grunt work, a strong advisor for the hard calls, a frontier lead when the whole thing needs a steady hand. Spend the expensive thinking only where the decision is expensive, and you get the quality of the top tier at something much closer to the price of the bottom one.

The model-selection table and the routing rules here are adapted from a framework shared by the developer Theo (t3.gg); the delegated-routing heuristics come from the superpowers subagent-driven-development skill.