/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, 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). One step down is not always cheaper: see the Fable 5.1 cache-read bullet for the implementer exception.

• **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`. On every model that supports effort the default is `high` - an unset effort IS high effort, not medium, and there is no exception. Opus 4.7 and 4.8 are often misread as one: they RECOMMEND starting at `xhigh` for coding and agentic work, which is a value you have to pass, not what runs when you pass nothing. 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. The per-model recommendation moves with the generation: Opus 4.7 and 4.8 are told to start coding and agentic work at `xhigh`, while Opus 5 is told to start at `high`, step up to `xhigh` for demanding coding and agentic work, and use `low` and `medium` liberally as the primary control for token cost and response time wherever evals show quality holds. The step down got cheaper, not the step up. `xhigh` is also the newest level and absent on some models that support `max` (e.g. the 4.6 generation), so check the model's own docs when in doubt - and 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 below the product default, wherever the task allows one, is where the effort savings come from.

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. On Sonnet 5 this level is described as comparable to Sonnet 4.6 at `high` - the sonnet/medium pins are not a downgrade to last year's quality.

• **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.

• **max** - exceptional frontier-grade problems only, not a routine level

anywhere in this table.

Match effort to task difficulty, not to tier - most work is a `low`/`medium` task in disguise. Where effort is set: the bundled agents pin theirs in frontmatter (`effort:` field - overrides the session level for that agent); Workflow scripts take an `effort` option per `agent()` call; any other Agent dispatch inherits the session effort. The Agent tool has NO effort param, so dispatching a pinned agent with `model=opus` changes the model, not the effort - the frontmatter pin still applies. Vary effort across workloads, not inside one conversation: changing the effort value between requests invalidates the cached prompt prefix, so per-agent pins and per-`agent()` opts - each with its own context - are the cache-safe way to differ.

Routing table

Each row carries a default effort - the second knob, tuned to the task, not the tier. For the bundled agents the effort is pinned in their frontmatter; the column documents it rather than asking the caller to set it. For unpinned rows it is the target level, reached via the session effort or a Workflow `effort` opt - a plain Agent dispatch carries no effort param:

| Task | Where | Agent / model | Effort | |------|-------|---------------|--------| | Planni