OpenRouter Fusion：把难题升级给模型小组，策略留在自己的仓库里

On September 10, 2026, OpenRouter published a Fusion explainer that turns a vague “ensemble models” idea into a production decision. Fusion is a compound inference path: one prompt goes to a panel of models in parallel, a judge maps consensus and contradictions, and a calling model writes a single final answer. The question for builders is not whether the demo looks clever. It is when you should escalate a request into that loop, when you should refuse the cost and latency, and where that policy lives so agents cannot invent it mid-session. If your team still copies the same hard question into three chat windows and reconciles the answers by hand, Fusion is doing that job as an API. If your product already needs a durable agent harness or a rented Linux shell, treat Fusion as a third, narrower tool: deliberation for high-stakes prompts — not a replacement for the repo you own. What Fusion actually changes OpenRouter’s write-up is explicit about the trade. An invoked Fusion call adds panel and judge completions. A default three-model panel costs roughly four to five times as much as one completion on the same prompt and often takes two to three times longer. Quality can rise on research-style work; chat, autocomplete, and tight interactive loops usually cannot absorb that delay. The pipeline has four stages: The calling model evaluates the prompt (answer directly, or invoke Fusion when deliberation is warranted). A panel of one to eight models answers in parallel; panelists can use OpenRouter web search and web fetch. A judge (analyst) compares responses for consensus, contradictions, partial coverage, unique insights, and blind spots. The calling model writes the response your application returns. That is different from auto-routing. Auto-routing picks one model. Fusion combines several reasoning paths and forces a structured comparison before synthesis. OpenRouter also notes that even pairing the same frontier model with itself can improve a deep-research score versus a solo run — the comparison step is doing real work, not only “more models.” Practically, production builders should stop treating multi-model polling as tribal knowledge in Slack. Encode escalation rules the same way you encode tool permissions. How to call it without turning every request into a panel The simplest path is the openrouter/fusion model slug. With no extra config, Fusion uses the default Quality panel and lets the model decide whether deliberation is necessary. You can force Fusion with tool_choice: "required", pick a preset, and override the judge: import os from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key=os.environ["OPENROUTER_API_KEY"], ) response = client.chat.completions.create( model="openrouter/fusion", messages=[{ "role": "user", "content": "Compare three approaches to multi-tenant data isolation for a B2B SaaS.", }], tool_choice="required", extra_body={ "plugins": [{ "id": "fusion", "preset": "general-budget", "model": "~openai/gpt-latest", }] }, ) print(response.choices[0].message.content) Enter fullscreen mode Exit fullscreen mode Presets currently called out in the explainer: general-high — strongest all-around panel general-budget — cheaper panelists with a frontier judge general-fast — panel tuned around similar response times You can also attach the openrouter:fusion server tool to your own outer model when that model already holds other tools. Docs describe the same underlying panel → judge → synthesis pipeline whether you enter through the model slug, the plugin config, or the server tool. Pin presets and judge overrides in config you review in git. Do not leave panel membership only inside a chatroom experiment. When Fusion earns the cost — and when it does not OpenRouter’s own guidance maps cleanly onto shipping products. Escalate when: Being wrong is expensive: research summaries, expert critique, due-diligence comparisons, architecture choices before you commit engineering weeks. You already poll several models by hand and merge answers in a doc. Cost per accepted result matters more than cost per request — one Fusion call that sticks can beat three cheap retries plus human cleanup. Skip when: Latency is the product: customer chat, inline completion, high-QPS interactive paths (Fusion often runs two to three times slower). You need reproducibility: evals, regression suites, CI checks that compare yesterday’s output to today’s. Panel plus synthesis is non-deterministic by design. A mid-tier single model already handles the task: classification, extraction, short rewrites, format conversion. That selective-escalation pattern is the ICP-consequence bar. Shipping Fusion on every agent turn because the slug is new is a cost trap, not a strategy. Keep the default path on one model; escalate the minority of prompts where an incomplete answer burns more money than the panel. Fusion vs shell vs a managed harness OpenRouter’s recent surface area can blur together if you only read headlines. Keep the ownership lines separate: Capability What it buys What still lives in your repo Fusion Multi-model deliberation on hard prompts Escalation policy, prompt templates, acceptance criteria Hosted shell / Files API Rented Linux seconds for any tool-calling model Network policy, promotion rules, domain executors — see OpenRouter hosted shell Managed agent harness (e.g. OpenAI Agents API) Session loop, compaction, subagents Skills, MCP, schema, approvals — see OpenAI Agents API ownership split Fusion does not give you a product. It gives you a more expensive, slower, sometimes better answer path. Shell does not give you a product either — it rents compute. A hosted harness does not invent your domain invariants. If those distinctions only exist in a founder’s head, agents will escalate everything, shell everything, and still ship the wrong schema. Ownership checklist for selective escalation Before you wire openrouter/fusion into a customer-facing flow, write these into the product repository: Escalation predicates — which task classes may invoke Fusion (research, critique, high-stakes compare) and which must stay single-model. Preset policy — general-budget vs general-high vs general-fast by surface (internal ops vs user-facing). Latency budgets — hard timeouts and fallbacks when the panel is too slow for the UX. Cost caps — per-request and per-user ceilings; Fusion multiplies completions on purpose. Acceptance checks — what “good enough to ship” means so the judge’s prose does not become an unreviewed merge. Logging — store whether Fusion ran, which preset, and whether a human accepted the result; otherwise you cannot tune the policy. Non-goals — explicitly ban Fusion on autocomplete, classification, and CI golden-output checks. Repo conventions still matter when the panel is rented. Durable product knowledge — schemas, “never do this” rules, MCP permissions — belongs next to the app the same way it does for any other agent path. A practical adoption sequence Pick one internal research or architecture-review workflow where people already paste the same prompt into multiple models. Run that prompt through openrouter/fusion with general-budget first; compare answer quality and total token cost against your current single model plus human merge time. Encode the escalation rule in code (feature flag + task classifier), not only in a chat system prompt. Keep customer-facing chat and codegen on a single model until you have latency and cost numbers you can defend. Only then open Fusion for a narrow production surface — for example, “generate three migration options and a risk list” — with a human accept step. Revisit presets quarterly; panel membership and pricing move, and a fixed “always high” choice decays into a silent budget leak. What not to do this week Do not put Fusion on every agent turn because the blog post is new. Do not use Fusion as a substitute for owning schema, MCP tools, or deploy scripts. Do not run regression evals through Fusion and then wonder why golden files thrash. Do not treat a budget panel that nearly matches a frontier solo model on one research benchmark as proof it replaces your coding model everywhere — OpenRouter’s DRACO numbers are deep-research results, not a blanket coding claim. Fusion is selective escalation as a productized loop: panel, judge, synthesis, with clear cost and latency taxes. Your edge remains the owned product repo — the predicates that decide when deliberation is worth it, the presets you pin, and the acceptance path that keeps multi-model prose from becoming unreviewed product truth. Ship that policy on purpose. Sources OpenRouter Fusion: How It Works and When to Use It (September 10, 2026) Fusion plugin documentation (OpenRouter)