challenging
Cross-context adversarial review for deliverables before shipping. Use when producing blog posts, technical recommendations,…
Decide which model, effort level, and cascade shape each subagent gets, and how to keep improvement loops safe (evaluator-as-selector, stop on regression). Routes on measured cost-per-completed-task rather than per-token price, because a tier's token count varies more by task
$ npx -y skills add oaustegard/claude-skills --skill agent-routing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/agent-routingContext preview
The summary Claude sees to decide when to auto-load this skill.
Decide which model, effort level, and cascade shape each subagent gets, and how to keep improvement loops safe (evaluator-as-selector, stop on regression). Routes on measured cost-per-completed-task rather than per-token price, because a tier's token count varies more by task
name: agent-routing description: Decide which model, effort level, and cascade shape each subagent gets, and how to keep improvement loops safe (evaluator-as-selector, stop on regression). Routes on measured cost-per-completed-task rather than per-token price, because a tier's token count varies more by task shape than price varies across tiers. Covers per-model effort semantics, the concision lever, cascade preconditions, context handoff, and watching a subagent fan-out live. Use when choosing a subagent's model or effort, when choosing how to escalate a failed attempt, or when asked which model or effort a task should get. Grounded in a 2026-07 calibration, a 2026-08 coding-cost study, a 2026-09 seeded-bug repair battery, a 2026-10 Haiku 5.5 ladder priced per spawn, and a 2026-10 retry-versus-escalation ladder on 295 SWE-bench Verified tasks; Managed Agents API specifics are operational, not calibrated. compatibility: Designed for Claude Code / Claude Code on the Web — assumes an orchestrator with Agent/Workflow subagent tools. Only the Workflow tool sets a subagent's effort; the Agent tool sets its model. Not applicable to claude.ai chat use. metadata: author: Oskar Austegard and Claude version: "2.7.2"
| model | $/MTok in | out | cache read | one Agent-tool spawn, small seeded repo | one spawn, SWE-bench Verified | |---|---|---|---|---|---| | Haiku 5.5 | $0.10 | $0.50 | $0.01 | **$0.005–0.011** | **$0.024–0.037** | | Sonnet 5.5 | $2 | $10 | $0.20 | **$0.17** | **$0.23–0.35** | | Opus 5.5 | $4 | $20 | $0.20 | ~$0.34 (2× Sonnet, not measured) | — | | Fable 5.1 | $10 | $50 | $0.25 | — | — |
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.
**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:
| arm | tok/task | pass | $/task | vs opus | |---|---|---|---|---| | haiku-solo | 20,051 | 14/14 | $0.1007 | **1.30×** | | haiku + concision | 13,342 | 12/14 | $0.0672 | 1.01× | | opus-solo | 3,001 | 14/14 | $0.0774 | 1.00× | | sonnet-base | 4,687 | 14/14 | $0.0478 | 0.62× | | sonnet + concision | 2,951 | 13/14 | $0.0305 | 0.42× | | **sonnet cascade** (below) | — | **14/14** | **$0.0315** | **0.41×** |
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.
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. 2. **Is it mechanically checkable, or does it need judgment?**
| | short output | long output | |---|---|---| | **checkable** | `haiku` + verifier | `haiku` + verifier, informed retry on `haiku`, then `sonnet` @ `high` | | **judgment** | `sonnet` @ `medium` | `sonnet` @ `high`, or `opus` when the work must be discovered |
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 judgment row splits on whether the prompt **names its deliverable** or leaves the work to be found. Sonnet 5.5 finis
A collection of Claude skills distributed as a Claude Code plugin marketplace. Skills are primarily designed for the Claude.ai PaaS skill compute environment; mileage will vary if used as Claude Code Agent Skills.
Cross-context adversarial review for deliverables before shipping. Use when producing blog posts, technical recommendations,…
Convenes expert panels for problem-solving. Use when user mentions panel, experts, multiple perspectives, MECE, DMAIC, RAPID, Six…
Routes, triages, flags and rates a piece of text with a probability for every option: which department or queue a ticket goes to,…
Delegates work to a subagent or spawned session by writing only the task, while a PreToolUse hook pages the parent transcript…
Chooses how to launch subagents from Claude Code (the Agent tool, a Workflow script, or headless claude -p children) and runs a…
Distill Opus-level reasoning into optimized instructions for Haiku 5.5 (and Sonnet). Generates explicit, procedural prompts with…