oaustegard/claude-skills/agent-routing

Agent Routing — model, effort, and cascade selection

Current prices, and what changed in 2026-10

Haiku 5.5 is 20× under Sonnet 5.5 on every token class (Haiku 4.5 was 2–5×), and its prices hold for prompts up to 100K tokens ($0.50/$2.50 beyond). On the 14-repo seeded-bug battery it solved 11/14 at rung 1, which is the pass set Sonnet 5.5 at low gets. With the same-model informed retry it solved 14/14 for $0.12 in total, less than one Sonnet 5.5 spawn (oaustegard/experiments → temporal-routing-headroom, 2026-10-07). Where the Haiku 4.5 figures below say Haiku loses on cost, rerun the arithmetic at 5.5 prices before trusting them.

On real issues the picture holds with a smaller margin. Over 295 SWE-bench Verified tasks (django and sympy) Haiku 5.5 resolved 256 (86.8%) at rung 1 for $7.06 in total. On its 39 misses, rung 2 with the failing tests' output resolved 30 retrying Haiku ($1.43) and 34 escalating to Sonnet 5.5 ($13.53). Sonnet solved every task the Haiku retry did and 4 more (p = 0.125) (oaustegard/experiments → swe-ladder, 2026-10-09). Real repair spawns run longer than seeded ones, so a spawn costs 3–5× the small-repo figure on Haiku and 1.5–2× on Sonnet; the ratio between the tiers stays near 10×.

In Claude Code, price a subagent per spawn first. A fresh Agent-tool subagent writes a ~55K-token prefix (system prompt, tools, skills list) to the 5-minute cache on its first request. On short repair tasks that prefix outweighed everything the subagent produced: a Sonnet 5.5 spawn cost $0.17 input-side, 14× the $0.0121 output-only figure this skill used to quote per completed task. Same-model spawns in sequence share the cached prefix (reads cost 0.1×), so serialise spawns of one model when they can wait, and count spawns before counting output tokens. Every table further down prices output tokens only. That is still right for comparing tiers on long outputs, but it understates what a spawn costs.

The rule that decides everything

Cost is output tokens × output price, plus the spawn's prefix. Prices span ~5× across tiers. Token counts span up to 7× within a single tier depending on task shape. The shape therefore decides more than the tier does, and routing on the per-token discount gets the answer backwards.

Measured 2026-08-17, 14 spec-dense Python modules graded by hidden tests, all tiers at equal quality where noted:

Haiku 4.5 was 5× cheaper per token and cost 30% more per solved task than Opus, because it emitted 6.7× the tokens. Prices then: Haiku 4.5 $1/$5, Sonnet 5 $2/$10, Opus 5 $5/$25 per MTok. At Haiku 5.5's $0.50 output price the same 20,051 tokens would cost $0.010 a task, a fifth of Sonnet's $0.048. Whether Haiku 5.5 is as verbose as 4.5 on generation is unmeasured. It would have to emit about 95K tokens a task to lose on output cost.

Two questions before spawning

1. Is the output short or long? Short = a schema instance, a label, an answer,

a small patch. Long = a module, a document, a plan, a review.

1. Is it mechanically checkable, or does it need judgment?

On Haiku 4.5, output length was the discriminator, because it is what the verbosity multiplier multiplies: Haiku 4.5's premium was invisible on a 200-token JSON object and ruinous on a 700-token module that cost it 13,000 tokens of thinking. At 5.5 prices verbosity no longer decides it, so the checkable column now starts on Haiku at any output length. The long-output cell is projected from price and from the repair battery, and has not been measured on generation.

The one measurement that has separated Haiku 5.5 from Sonnet 5.5 is judgment without a stated rule: triage of real private email, 84.7% against 91.7% (McNemar p = 0.0005), in the same external study whose two synthetic benchmarks with stated rules did not separate them. That the missing rule is the cause is the study's hypothesis, not a measurement. Until someone tests it, treat "the prompt states the rule and the answer is checkable" as the condition for the checkable row, and route rule-less sorting, triage and prioritisation to the judgment row.

The judgment row splits on whether the prompt names its deliverable or leaves the work to be found. Sonnet 5.5 finishes a named deliverable well. Given an audit-and-update goal, it listed findings, raised doubts and stopped to ask, and Oskar moved that session to Opus 5.5 mid-task (2026-10-07; one session, an observation, not a measurement).

Routing table

Haiku holds the top four rows on merit: 240/240 measured across nested modular arithmetic, 30-hop chains, 25-operation state tracking, trap-laden word math, and 5-constraint generation, some with CoT suppressed (references/calibration-2026-07-15.md). Those were Haiku 4.5 runs, which requested effort: low and ignored it, so the column says n/a. Haiku 5.5 does take effort (see below); until it is measured, leave it at its default. Do not up-tier short checkable work "to be safe"; there is no measured benefit and it costs 3–5×. The burden of proof is on routing up.

An independent run on 5.5 agrees (drknowhow/experiments → haiku-delegation-bench-hard, 2026-10-18, pre-registered, 60 items, three reps). Across log joins, multi-hop repo navigation, subtle review bugs, multi-file edits, threads where later messages supersede earlier values, and unanswerable questions with near-miss distractors, Haiku 5.5 scored 0.968 against Sonnet 5.5's 0.994 and Opus 5.5's 1.000, for about 1/16 of Sonnet's cost. The gap is 0.026 (95% CI 0.006–0.055); five of six categories routed to plain Haiku and the sixth to Haiku with a check. Every item stated its rule and had one checkable answer, which is the condition the top rows assume.

Haiku 4.5 lost the generation rows on cost alone, not capability: it scored 14/14 on the same suite Opus swept. At 5.5 prices that cost argument is gone (see the top of this file), so the generation rows now start on Haiku behind a test verifier, pending a generation-suite run on 5.5.

Effort is model-specific — verify per model before reusing a level

Measured 2026-08-17 via per-message output_tokens_details.thinking_tokens, thinking as a share of output on identical prompts:

low was a near kill-switch on Sonnet 5: it dropped 14/14 → 10/14. Sonnet 5.5 is different. On the 14-repo seeded-bug battery (2026-09-29, two replicates, temporal-routing-headroom):

• low and medium cost the same on Sonnet 5.5 for this work, and low missed only

trap tasks. Claude Code's <reasoning_effort> tag agrees: 4 at low, 5 at medium.

• high bought the paired traps: lru_ttl and wrap_text went from 0 of 2 at low to

2 of 2 and 1 of 2.

• Sonnet 5.5 @ high matched Opus 5.5 @ high at 24 of 28 each, for 0.43× the cost

per completed task. Seeded repair does not separate tiers, so this says the two are close on this family and nothing about harder work.

• The token counts are one replicate (budget deltas from r2); thinking share could not

be measured, because Claude Code omits thinking text.

Effort does not reach Haiku 4.5. The Messages API rejects effort on it; Claude Code's Workflow agent() accepts the option and drops it (0 of 12 Haiku probes carried an effort tag or a transcript effort field). The identical 88–91% thinking share at low and medium above is that fact seen from the token side, and the ~26% token drop once attributed to low sits inside the 23% run-to-run gap measured below. Tune Haiku with the prompt; the routing table lists its effort as n/a.

Haiku 5.5 takes effort. The API accepts low through max on it, defaults to medium, and thinks adaptively by default; budget_tokens and non-default temperature are 400s. Whether Claude Code's Workflow agent({effort}) reaches a Haiku 5.5 subagent, and what low does to its pass rate, are both unmeasured. The 2026-10-07 ladder ran it at the session's level through the Agent tool.

• Tune Sonnet with the prompt as well as the knob. On Sonnet 5, medium was the

working floor and low overshot into thinking-off; on Sonnet 5.5 low is a usable rung 1 and high is the rung that caught the traps.

• Buy depth only for judgment-heavy roles; drop triage and formatting roles to low

without touching the expensive role's budget.

Setting effort — which channel reaches which agent

Measured in Claude Code on 2026-09-28 (muninn.austegard.com/blog/effort-levels-in-claude-code-subagents.html):