OpenRouter's default Fusion slug lets the calling model decide when to spend 5x

Call `openrouter/fusion` with nothing else in the request and two choices are made for you. Fusion uses the default Quality panel, and the calling model evaluates the prompt and invokes deliberation when it decides deliberation is warranted ^[7]. Setting `tool_choice: "required"` puts that decision back in your code ^[8].

Billing follows the stage count. The pipeline sends one prompt to a panel that answers in parallel, hands the answers to a judge, and has the calling model write the response your application returns ^[2]. On the default three-model panel you are paying for three panel completions, one judge pass and one synthesis pass, so five completions replace one ^[1]. OpenRouter's write-up puts the increase at roughly four to five times a single completion on the same prompt, and two to three times the latency ^[6].

The dev.to walkthrough of the explainer argues that one Fusion call that sticks can beat three cheap retries plus human cleanup ^[18]. Check that against the multiplier. A single model whose answers are accepted with probability p costs 1/p completions per accepted answer; Fusion at 4.5x costs 4.5/q. Fusion is cheaper only when q/p exceeds 4.5, and q cannot exceed 1, so p has to sit below about 22 percent, between 20 and 25 percent across the quoted cost range ^[2]. If half your single-model answers already ship, no achievable panel accuracy earns the spend back. Escalating then has to be justified on what a correct answer is worth.

OpenRouter's escalate list is research summaries, expert critique, due-diligence comparisons and architecture choices taken before you commit engineering weeks ^[14]. Its skip list includes evals, regression suites and CI checks, because panel plus synthesis is non-deterministic by design ^[16]. Those escalation cases are exactly the ones a team would want a golden-output test for. The output still moves with the preset and the judge pinned.

The judge stage is the interesting engineering. OpenRouter notes that pairing the same frontier model with itself can improve a deep-research score against a solo run ^[13], which suggests the structured comparison contributes something separate from panel diversity. The judge is asked for consensus, contradictions, partial coverage, unique insights and blind spots ^[5]. Auto-routing, by contrast, picks one model ^[12].

Three presets are named in the explainer: `general-high` for the strongest all-around panel, `general-budget` for cheaper panelists with a frontier judge, and `general-fast` for panelists tuned to similar response times ^[9]. The preset and a judge override go in `extra_body` under a `fusion` plugin ^[10], and the same panel-judge-synthesis path is reachable as the `openrouter:fusion` server tool when your outer model already holds tools ^[11]. The dev.to author's recommendation is to pin presets and judge overrides in config you review in git rather than leaving panel membership inside a chatroom experiment ^[19].

In my view the escalation predicate is the only part of this you actually own. Panel composition, judge behaviour and pricing all sit on OpenRouter's side of the API. The predicate sits in your repo, if you write it there.