Fusion Routing

Fusion routing runs a single session on a cheap build model and consults an expensive advisor model only for the hard parts — planning, architecture decisions, debugging a failure the build model cannot resolve. The two models share one task but not one token budget: the advisor is invoked per question, while the build model carries the long, repetitive execution loop.

It is also called fusion, or a smart router, in contrast with the auto-routing family, which picks one model per request or per session. Fusion is not a choice between models; it is a division of labor inside the same run.

Why It Matters

In an agentic coding loop, the token volume is dominated by execution: reading files, applying edits, running tests, re-reading output. That traffic is cheap to serve with a small model. The reasoning that actually needs a frontier model — "what is the right design here?", "why does this test fail?" — is a handful of short exchanges.

Paying frontier prices for the whole loop over-provisions the 95% of tokens that do not need it. Running the whole loop on a cheap model under-provisions the 5% that does, and the resulting flailing costs more tokens than the advisor would have.

Mechanics

• Advisor invocation: the build model calls the advisor as a tool ("ask the smart model"), or the harness triggers it on signals — start of task, plan revision, repeated tool failure, test still red after N attempts.
• Context hand-off: the advisor usually receives a condensed brief (task statement, relevant file excerpts, the failing output), not the full transcript. This is Context Isolation pointed upward instead of downward: the expensive model sees the least context, not the most.
• Answer size: the advisor returns a plan or a diagnosis, not code. Its output is short in both directions, which is what makes the per-call price tolerable.
• Caching: the build model keeps a stable prefix across the whole session, so Prompt Caching works normally; the advisor's calls are separate, usually uncached, requests.

Trade-offs

• Pros: frontier-level planning at near-cheap-model cost; the build model's cache is never broken by a model switch; failure modes of the cheap model are caught rather than compounded.
• Cons: two model bills and two vendors to manage; the hand-off brief is a lossy channel — the advisor can give good advice about the wrong problem; hard to attribute regressions to the right model.
• Failure mode: advisor calls triggered too eagerly turn fusion into "frontier model with extra latency".

See Also

• Model Routing — picks one model per task; fusion uses two at once.
• Effort Calibration — the same idea applied to reasoning effort within one model.
• Context Isolation via Subagents — the advisor is a subagent whose context is deliberately kept small.
• Cache-aware Routing — fusion sidesteps the cache-boundary problem by never swapping the main model.
• Incremental Plan Updates — what the advisor typically returns.

Tools

• Anthropic Advisor — a stronger model consulted by Claude Code for planning and hard questions while the session model executes.
• Devin Fusion — advisor/build model split in the Devin CLI.
• OpenRouter Fusion — hosted fusion endpoint pairing a reasoning model with an execution model.
• Sakana Fugu — fixed-rate fusion routing service.