/model-routing

name: model-routing
description: Route work to the cheapest model tier that holds quality. Use when deciding which model or agent should handle a task, when the user asks about token economy / cost optimization, or when dispatching implementation, review, or test-run work to subagents.

Model Routing

The expensive model thinks, cheaper models grind. The main-session model cannot be switched by Claude - routing works through subagent delegation (the `model` param of the Agent tool, or the agents bundled with this plugin).

**Routing makes a dispatch cheaper; it does not make dispatching cheap.** A subagent starts empty, so everything it reads is a cache write, while the main session pays cache read - 12.5x less, 25x on Opus 5.5 and Sonnet 5.5, 50x on Fable 5.1 and Mythos 5.1 - for context it already holds. That penalty is paid whether or not the tier is routed down, so the rules below only pay off on work that was going to be delegated anyway. On one wide-reading session, three runs: doing it inline cost $1.36 and delegating with the tier routed down $1.68, both measured; delegating at the session tier comes to $2.01, which is those same measured subagent tokens repriced at the higher tier rather than a run of its own. Route every dispatch - roughly a sixth off work already leaving the session - and do not manufacture dispatches to collect it.

Tiers

Think in tiers, not model names - names rot, tiers do not:

• **strongest** - the main-session model the user picked (Fable, Opus,

whatever their plan offers). Highest reasoning quality, highest cost.

• **mid** - one step down (e.g. Opus when the session runs Fable, Sonnet

when the session runs Opus).

• **cheap** - Sonnet/Haiku class. Mechanical work.

Effort, not just tier

Model tier is one knob; reasoning effort is the second, and it moves cost as hard as tier does. The same model at `low` effort can cost a fraction of `max` and still clear a task that was never hard - a strong model thinking lightly often beats a weaker model thinking hard. Pick both: which model, and how hard it thinks.

The full ladder is `low / medium / high / xhigh / max`. What runs when nothing sets a level is Claude Code's per-model default: `high` on every model that supports effort, except `medium` on Opus 5.5, Sonnet 5.5 and Haiku 5.5 and `xhigh` on Opus 4.7. The API's own default can differ (it runs both Opus 4.7 and Sonnet 5.5 at `high`), but a session's effort is what Claude Code sends. Levels are saved per model under `modelSettings`, and a top-level `effortLevel` in the user settings file no longer reaches Opus 5.5 or any model released after it, Sonnet 5.5 included - so a session that ran Opus 5 or Sonnet 5 at a saved level starts its 5.5 successor at `medium` until a level is chosen for that model. Which levels exist at all is a per-model list rather than a version cutoff, and setting a level the model does not support runs the highest supported level at or below it (`xhigh` is absent on the 4.6 generation). The recommendation moves with the generation: Anthropic reports Opus 5.5 at `medium` matching or exceeding Opus 5 at `high` on coding and knowledge work, and `low` close to it on several coding evals, while at any given level it thinks more per turn than Opus 5 did - a level carried over buys more depth and costs more tokens than it used to. Re-sweep effort on your own evals after a model change instead of carrying old settings across generations. This plugin tunes for cost: pins sit at the lowest level the task shape allows and step up on evidence (a weak result retries one step up). That deliberate step down, wherever the task allows one, is where the effort savings come from - measured against the level the dispatch would otherwise inherit from the session, which is what a pin actually replaces.

Effort is not only thinking depth - it shapes every token in the response, tool calls included. At lower effort the model folds operations into fewer tool calls and skips preamble, so a cheap pin saves twice: less reasoning AND fewer round trips. Anthropic's own example use case for `low` is subagents.

• **low** - mechanical or well-scoped work: exploration, renames, running

tests, reading a diff for a known-shape change.

• **medium** - normal implementation: real logic, but the approach is

already clear. It is also where Sonnet 5.5 is told to start agentic coding and multistep tool use on well-specified tasks, moving to `high` for harder or longer ones. This plugin draws its own line one step earlier and on the tier instead: harder work goes to opus, still at the pinned medium, because a dispatch has no effort param to raise. Sonnet 5.5's levels are recalibrated against Sonnet 5 - the same name buys a different amount of thinking than it did, and Anthropic does not say in which direction, so re-sweep rather than carry a level over. Note what an effort pin is measured against: the level the dispatch would otherwise INHERIT from the session, not the pinned model's own default. So `implementer` at `medium` still steps down from a session running `high` or above - a Fable 5.1 session at its default, say - and buys nothing on a session already at `medium`, which is now the Claude Code default for Opus 5.5, Sonnet 5.5 and Haiku 5.5 sessions. The three haiku agents' pins are live on the Anthropic API, where `haiku` is Haiku 5.5 with the full ladder. On Claude Platform on AWS, Bedrock, Google Cloud and Foundry `haiku` is still Haiku 4.5, which has no effort knob at all, so there the pins document intent and cost nothing.

• **high** - genuinely hard reasoning: architecture, subtle debugging,

high-risk final review, anything where a wrong approach is expensive to unwind.

• **xhigh** - long-horizon agentic or coding work (multi-hour runs, token

budgets in the millions) that genuinely earns the extra reasoning. In this plugin that is a session-level or Workflow `effort` choice, never an agent pin.