Sakana Fugu vs OpenRouter Fusion: Two Ways to Wrap a Multi-Agent System in a Single Model

For the past couple of years, picking a model was simple. You'd check the leaderboard, grab whatever was sitting at the top, wire up the API, and you were done. But by 2026, that logic is starting to fall apart. The frontier models have basically converged — they're all roughly as good as each other, but each one has its own quirks, its own strengths, its own blind spots. And if you commit to "always one model," you're carrying single-vendor risk and throwing away everything the other models happen to be better at.

So a new kind of product showed up to fix this. The idea is: orchestrate several models behind the scenes, but only expose one endpoint. You call it like it's a single model — but behind that wall, a whole pool of them is collaborating. Today I want to dig into two of the leading examples. One is Sakana AI's product called Fugu. The other is OpenRouter's product called Fusion. They're chasing the exact same problem, but they take completely opposite design philosophies to get there.

Let's start with why this is happening now.

Both products rest on the same observation — it's sometimes called "mixture-of-agents." The idea is, you take one prompt, fan it out to several models, combine the results, and you'll often beat any single model working alone. And OpenRouter has this one data point that really drives it home. They found that even when you fuse Opus 4.8 with *itself* — the same model, twice — the score jumped from about 59% up to 65%. That's nearly seven points, from a model talking to a copy of itself. Which tells you something important: it's not just diversity of models that helps. The *synthesis step itself* — the act of combining and reconciling — is where a big chunk of the gain comes from.

Think about why that is. When one model is wrong, it has no reason to doubt itself. But when several models answer the same question, the places where they disagree become a signal. The disagreement is the value. Both Fugu and Fusion build on this insight — they just hand the job of "collaboration" to very different machinery.

So let's talk about Fugu first.

Fugu's core philosophy is basically: don't pre-design how the team divides up the work — let the system *learn* how to do it. And it's built on two research papers Sakana published at ICLR 2026. The first one is called TRINITY. It's a lightweight, evolved coordinator that dynamically assigns roles to different models — a Thinker, a Worker, and a Verifier — across a series of turns. Good for coding, math, reasoning. The second paper is called Conductor, and this one uses reinforcement learning to actually *discover* coordination strategies and communication patterns between agents, in natural language, instead of someone hand-coding the workflow.

And that's the key contrast. Traditional multi-agent frameworks — think LangGraph, think CrewAI — you, the developer, hand-craft every node and every edge. You decide who does what. Fugu throws that out. A trained coordinator decides who speaks first, who verifies, when to hand off. And here's the thing: all of that is completely opaque to you. From the outside, it's just one OpenAI-compatible endpoint. You don't pick models. Fugu decides which ones participate and how they pass work between each other.

There's also a nice compliance angle here. You can tell Fugu to exclude specific providers — to meet privacy rules or export-control requirements. That's a genuine selling point if you're operating somewhere geopolitically sensitive.

Now, Fugu comes in two tiers. There's regular Fugu, and there's Fugu Ultra. The regular one balances performance against latency — it's your everyday workhorse, good for coding, chat, interactive tasks. Ultra reaches into a deeper pool of agents and prioritizes raw answer quality over speed — it's aimed at the hard stuff, like reproducing research papers, Kaggle competitions, security analysis. One difference worth noting: with regular Fugu you can opt out of specific providers, but Ultra's agent pool is fixed, you can't adjust it.

The benchmark numbers are genuinely strong. On SWE Bench Pro — that's a real-world software engineering test — regular Fugu scores 59, and Ultra jumps to nearly 74. On LiveCodeBench they're both in the low 90s. On GPQA-Diamond, a hard science-reasoning test, both hit 95.5. But honestly the qualitative results are more fun. Fugu Ultra solved all 300 Rubik's cubes it was given, while competitors generated code that just didn't work. And in blindfold chess, it beat three frontier models *and* the Stockfish engine.

On pricing — there are subscription tiers at twenty, a hundred, and two hundred dollars a month, scaling up your usage. Or you can pay as you go. But here's the detail I love: when multiple agents are active on your request, the fees don't stack. You pay at the rate of the highest-tier model involved, not the sum of all of them.

The limitations are clear, though. Because its GDPR compliance isn't complete, Fugu is not available in the EU or the EEA. The routing is a black box you fundamentally cannot inspect. And as I mentioned, Ultra's agent pool is locked.

Okay. Now let's cross over to the other philosophy — OpenRouter's Fusion.

Fusion takes the opposite road. There's no trained coordinator hiding in a box. Instead, it's an explicit, interpretable deliberation pipeline. It actually packages mixture-of-agents as a *tool* attached to an outer model. Let me walk you through how a request flows.

You send your prompt to a model called "openrouter slash fusion." That resolves to an underlying model with the fusion tool bolted on. First, that outer model makes a judgment call: does this task even need deliberation? If it's easy, it just answers directly. But if it's worth it, it invokes fusion. When it does, you hit the panel stage — up to eight models answer simultaneously, each with access to web search, each producing an independent response. Then comes the crucial part: a dedicated judge model receives every single one of those responses. And — this is the key — it *compares* them. It does not merge them. It emits structured analysis, as JSON. Finally, the outer model takes the judge's analysis and writes the final answer.

Let me linger on that judge step, because it's the heart of what makes Fusion different. The judge doesn't blend the answers into mush. It breaks them down along four dimensions. First, consensus — the points most models agree on, which get treated as higher-confidence. Second, contradictions — where the panel actively disagrees. Third, coverage gaps — topics only some of the models bothered to address. And fourth, blind spots and unique insights — what nobody covered, plus the novel takes that individual models brought to the table.

Now, it's worth being precise about how this differs from a normal router, because people confuse the two. A router picks *one* best model *before* it sends anything — cheap model for the easy task, expensive model for the hard one. The whole point of a router is to save money. Fusion does the opposite: it sends to many models at once and combines the results. One saves money, the other spends money to chase quality. Completely different goals.

There are two ways to call Fusion. The simple way is just to use it as a model alias — point your request at "openrouter slash fusion" and go. But if you want control, there's a server-tool mode where you specify your own outer model, choose your own judge, and even mix it with other tools. You can tune the panel — by default it's a three-model "Quality" preset, something like Claude Opus, the latest GPT, and Gemini Pro, but you can set that anywhere from one to eight models. You can force deliberation on every single request if you want. And there's recursion protection built in — the inner fusion calls carry headers that stop the panel and judge models from invoking fusion *again*, so you don't get infinite nesting.

The performance numbers come from a deep-research benchmark called DRACO. Fable 5 fused with GPT-5.5 scored 69%, beating every individual model — Fable 5 alone was 65, GPT-5.5 alone was 60. But the more interesting result is on cost. A "budget panel" — Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro — hit nearly 65%, which is almost matching standalone Fable 5, but at *half the cost per task*. So you can play this for value, not just for maximum quality.

But let's be honest about the catch, and the catch is money. With the default three-model panel, you should expect roughly four to five times the cost of a single completion — because each panel model runs independently, and then there's a judge call on top. And it scales linearly with panel size. Fusion is not a cost-saver, and OpenRouter is refreshingly upfront about this. Their positioning is: use it when the cost of *being wrong* far outweighs the cost of a few extra completions. Deep research. Expert critique. Compare-and-contrast questions. High-stakes stuff.

So let me put these two side by side, because the contrast is really clean.

The core mechanism: Fugu uses a learned, evolved coordinator that dynamically assigns roles. Fusion uses parallel deliberation plus a judge that does structured comparison. Is the collaboration interpretable? With Fugu — no, it's a black box, the routing is opaque. With Fusion — yes, completely transparent: you see the consensus, the contradictions, the blind spots. Who picks the models? Fugu decides for you, though you can exclude providers. Fusion lets you specify the panel and the judge yourself. Billing? Fugu charges at the highest-tier rate with no stacking. Fusion stacks linearly, four to five times a single call. And the headline use case: Fugu is general-purpose — coding, interactive work, with Ultra for the hard problems. Fusion is for high-stakes decisions, deep research, getting a real second opinion.

If I had to compress the whole thing into one line: Fugu bets that coordination strategy can be *trained*, and it hides all the complexity in a black box to buy you generality. Fusion bets that the deliberation should be *visible*, and it deliberately exposes where the models disagree to buy you interpretability and control.

You can almost see it in the shape of how each one works. With Fugu, picture a central coordinator handing work downward, and roles looping back and forth between the Thinker, the Worker, and the Verifier — all the control lives in that one learned coordinator at the center. With Fusion, picture the request fanning out once to all the panel models, then everything converging back onto the judge — and the control lives in a deliberation structure you can actually see and inspect.

So where does that leave you?

These two products are really two different bets on what comes after the single-model era. Neither one is wrong — the trade-off is just clear. If you want a drop-in, general-purpose endpoint that handles model selection and hand-off for you, and you can live with a black box — or you specifically need to exclude certain providers for compliance reasons — go with Fugu. It makes the whole "should we use multiple models, and how should they work together" decision *for* you.

But if you want control over the deliberation, and you want visibility into exactly where the models disagree — on tasks where being wrong is genuinely expensive, like research or real decision-making — go with Fusion. Yes, it's expensive. But it's expensive *transparently*, and it bolts onto an outer model that you choose.

And maybe the biggest takeaway sits above both of them. The question "which model do I pick" is being quietly lifted out of your hands and folded into the infrastructure itself. Whether it's Fugu's trained coordination or Fusion's deliberative synthesis, the direction is the same: what you call in the future may no longer be a model at all — it'll be a whole system, wrapped up to look like one.