Skip to main content
The Fusion plugin gives your model access to a multi-model deliberation tool. When the model invokes it, a panel of models answers your prompt in parallel (with openrouter:web_search), a judge compares their responses and returns structured analysis, and your model uses that analysis to write a better final answer. The Fusion plugin is a configuration surface for the openrouter:fusion server tool. It’s also the mechanism behind the openrouter/fusion model alias. All three entry points hit the same pipeline.

When to use Fusion

Reach for Fusion when a single model isn’t enough — research, expert critique, or tasks that benefit from multiple perspectives. Fusion is overkill for short tactical prompts; use it when the cost of being wrong outweighs the cost of a few extra completions.

How it works

  1. The plugin injects the openrouter:fusion tool into your request. If you used model: "openrouter/fusion", it also resolves the alias to a real model.
  2. Your model reads the prompt and decides whether to invoke openrouter:fusion.
  3. The panel — a set of models — answers your prompt in parallel, each with openrouter:web_search and openrouter:web_fetch enabled.
  4. The judge receives all panel responses, with openrouter:web_search and openrouter:web_fetch available, and compares them — it doesn’t merge them. It returns structured analysis as JSON: consensus (points all or most models agree on, treated as higher-confidence), contradictions, partial coverage, unique insights from individual models, and blind spots none of them addressed.
  5. Your model receives the structured analysis and writes the final answer.

Configuration

When you send model: "openrouter/fusion" without a plugin config, the defaults match the Quality preset on the Fusion lab.

Presets

Don’t want to pick models? Reference a curated preset by slug with preset — the panel and judge are chosen for you:
Slugs follow <task>-<tier>: task is what you’re optimizing the panel for, and tier is the quality/cost/speed tradeoff (high = strongest models, budget = cheaper panel with the same frontier judge, fast = a latency-homogeneous panel where every model has similar TTFT so no single model gates the fan-out). These mirror the presets shown in the Fusion lab UI. Explicit analysis_models or model always take precedence over a preset.

Two entry points, one pipeline

openrouter/fusion is equivalent to enabling the openrouter:fusion server tool on the configured model. These behave identically:
In both cases, the model decides when to call openrouter:fusion. For prompts that don’t need deliberation, it answers directly — including invoking any other tools you’ve defined.

Complete example

Recursion protection

Inner fusion calls carry an x-openrouter-fusion-depth header. Panel and judge models cannot recursively invoke openrouter:fusion — the plugin refuses to inject the tool a second time, keeping deliberation bounded to a single level.