Sakana Says Fugu Ultra v2 Beats Models It Won't Use

What you need to know

• Sakana AI released Fugu Max and Fugu Ultra v2 on 11 September 2026, under the announcement title “Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier”.
• Fugu is not a monolithic model. It is a learned multi-agent orchestration system — a language model trained to route tasks across a fixed pool of open and specialised models, and to recursively call instances of itself.
• Sakana reports Fugu Ultra v2 scoring 74.3 on DeepSWE and 48.3 on Chartography, and says it is best or joint-best on five of eight benchmarks (GDP.pdf, Chartography, SWEFish, DeepSWE, Toolathon), top-two on seven of eight.
• It does this without Claude Fable 5, Claude Fable 5.1 or GPT-6 Astra in its pool — three of the strongest systems currently shipping — and Sakana claims it still beats all three. That claim is the vendor's own.
• Pricing is frontier-tier: $5.00 per million input tokens, $30.00 per million output, $0.50 per million cached input. Above 272,000 tokens of context those become $10.00, $45.00 and $1.00.
• Fugu Max is the cost-optimised sibling, expanding the orchestrated pool to Sakana's largest yet — including the NVIDIA Nemotron family via a collaboration with NVIDIA — and routing each task to the leanest model capable of solving it. AlphaSignal framed the split as cutting costs 60%.

Read the release quickly and it looks like another leaderboard entry. Read it slowly and it is an argument about where intelligence lives in your stack. Sakana is not claiming to have trained a better base model than anyone else. It is claiming that a good enough pool, routed well, outperforms a better model used naively — and that the routing itself is the product worth paying for.

Fugu is a router that happens to speak English

The mental model most teams carry is that you pick a model, you write prompts against it, and you swap it when something better arrives. Fugu breaks that in a specific way. The thing you call is a language model, but its primary learned behaviour is delegation. It decides which member of a fixed pool should handle a task, hands it over, and — this is the part that makes it more than a classifier — it can recursively call instances of itself, so a hard task can be decomposed into sub-tasks that each get their own routing decision.

If that sounds familiar, it should. It is the supervisor pattern, and plenty of teams have hand-rolled a version of it. We walked through the taxonomy in our guide to the supervisor, swarm and fan-out multi-agent patterns, and the supervisor variant — one coordinating model that dispatches to specialists — is the most commonly deployed of the three precisely because it is the easiest to reason about. Fugu's contribution is not inventing the pattern. It is training the supervisor rather than prompting it, and then selling the whole assembly behind a single endpoint.

What Ultra v2 actually exposes

On the surface it behaves like any modern frontier endpoint. One million tokens of context, 128K maximum output, configurable reasoning effort with high, xhigh and max settings, function calling, structured outputs, image and PDF input, and built-in web search. Knowledge cutoff is 28 August 2026. Nothing in that list tells you a pool of models sits behind it, which is the point — the orchestration is meant to be invisible.

Invisible is a design choice with consequences, and we will come back to them. First, the claim that makes this release worth an article.

The awkward benchmark claim

Sakana says Fugu Ultra v2 is best or joint-best on five of eight benchmarks and top-two on seven of eight, with 74.3 on DeepSWE and 48.3 on Chartography. Those are strong numbers. What makes them provocative is the composition of the pool they came from: no Claude Fable 5, no Claude Fable 5.1, no GPT-6 Astra. Three of the strongest systems in production today are absent, and Sakana still claims to beat all three.

Take that at face value and it is a genuinely interesting result — evidence that coordination extracts more from a mixed pool than raw capability extracts from a single system. Take it sceptically and there are two obvious readings. One is that the benchmarks reward decomposition more than they reward raw reasoning, which would make the comparison flattering rather than false. The other is that excluding the three strongest proprietary systems is not only a principled stance about openness; it is also a competitive positioning decision, and the two are difficult to separate from outside.

Two opposite bets, almost the same score

Here is the detail that reframes the whole release. DeepSeek V4.1 Flash — a single 552B mixture-of-experts model, MIT licensed — scores 74.2 on DeepSWE v1.1. Fugu Ultra v2 scores 74.3. That is a gap of one tenth of a point between an orchestrated pool of many models and one large open-weight model doing the work alone.

Two architectures that could hardly be more different landed in the same place. One bets that you concentrate capability in a single set of weights and let sparsity handle the efficiency; the same bet underpins the wave of efficient MoE releases we covered when Qwen shipped a 125B model with 6B active parameters. The other bets that you spread capability across specialists and invest in the coordinator. Neither has pulled ahead of the other on this particular test.

That convergence is more informative than either number alone. If two opposite architectural bets produce equivalent results on the same benchmark, the benchmark has probably stopped discriminating between architectures and started measuring something closer to effort. It also means the choice between them is not really a capability choice. It is a choice about operating characteristics: cost profile, latency profile, licence, deployability, and how much of the system you control.

A similar convergence is visible elsewhere. GitHub's own move to route Copilot CLI across multiple models — which we covered in the HydraFusion release — came with cost reductions across three benchmarks rather than headline capability gains. Orchestration keeps arriving as an efficiency story that occasionally produces a capability story as a side effect.

Buy the orchestrator, or keep your own?

This is the decision Fugu actually puts in front of you, and a great many teams in Bengaluru and London have already built half of it. The pattern is familiar: send the request to a cheap model first, check confidence or run a validator, escalate to an expensive model when the cheap one is not good enough. That cascade is one of the most common cost-optimisation moves in production AI, and most teams who have it wrote it themselves in an afternoon and have been maintaining it ever since.

Fugu is that logic, trained rather than hand-written, and sold as an API endpoint. So the question is not whether routing is a good idea — you already decided that. The question is whether somebody else's routing is better than yours, and what you give up to find out.

The observability line is the one that decides most real arguments. If you run anything that needs an audit trail — a regulated workflow, a clinical or financial decision support tool, anything where “which model produced this output?” is a question somebody will eventually ask in writing — an opaque router is not a neutral choice. You can log the request and the response, but you cannot log the provenance, because the vendor has deliberately abstracted it away.

Against that, the maintenance argument is stronger than it first appears. Re-benchmarking a cascade every time a significant model ships is a real recurring cost, and in 2026 significant models ship most weeks. Teams consistently underestimate it because the initial build was cheap. We laid out a fuller version of this trade in our managed agent runtime versus own harness decision ladder, and the same ladder applies here almost unchanged: the higher routing sits in your product's differentiation, the less sense it makes to rent it.

The lock-in argument, and who it is aimed at

Sakana's strategic pitch is explicit: orchestrating a swappable pool of open and specialised models protects users from vendor lock-in, API revocations, geopolitical turbulence and sudden service cutoffs. If one member of the pool disappears, the router adapts around it and your endpoint keeps answering.

That argument lands differently in different rooms, which is why it is worth taking seriously rather than dismissing as marketing. For a UK public-sector supplier, dependency on a single foreign frontier provider is a procurement question before it is an engineering one — the buyer will ask what happens if the provider changes terms, and “we would rewrite our prompts” is a weak answer. For an Indian team building on IndiaAI Mission compute, the same concern arrives from the opposite direction: the point of domestic compute is reducing dependence, and an architecture that treats models as interchangeable components fits that goal better than one that hard-codes a single American API.

But the argument cuts both ways, and honesty requires saying so. A pool that deliberately excludes Claude Fable 5.1 and GPT-6 Astra is not simply neutral infrastructure. It is a curated selection reflecting a company's positioning, and swapping a dependency on one vendor for a dependency on a vendor who chooses your vendors is not obviously an improvement in sovereignty. You have moved the lock-in up a layer, not removed it. The genuinely lock-in-resistant move is the less glamorous one: keep your own routing layer, and make sure your prompts, schemas and evaluation harness are portable across providers — the discipline we covered in making structured outputs survive a provider swap.

Where Fugu Max is the more interesting product

For most teams reading this, Fugu Max rather than Ultra v2 is the release that matters. Ultra v2 at $5 in and $30 out is priced as a frontier product, so the savings story cannot rest on it. Max is the one making an economic argument: the largest orchestrated pool Sakana has built, including the NVIDIA Nemotron family through a collaboration with NVIDIA, with routing that sends each task to the leanest model capable of solving it and a target of performance within striking distance of elite models at two to six times lower cost. AlphaSignal framed the split as cutting costs 60%.

“Within striking distance” is doing some work in that sentence, and no benchmark table has been published for Max at the level of detail given for Ultra v2. But the shape of the claim is the right shape: this is a cost product that sells adequacy, not a capability product that sells the best possible answer. Lean teams in Bengaluru and London face the same arithmetic here — cost per task is the number that decides whether an AI feature ships or gets quietly shelved, and it does not care which side of the corridor you are on.

It is also worth noting where this sits in a wider pattern. The industry is spending heavily on making inference cheaper by being cleverer about placement rather than by buying more hardware — the same instinct behind Gimlet Labs raising $300M to run each phase of inference on different silicon. Fugu routes across models; Gimlet routes across chips. Both are betting that the naive approach of “one big thing, used for everything” is leaving a great deal of money on the table.

One more data point on where orchestration wins

A useful cross-reference sits on the public CyberGym leaderboard snapshot, where DeepSeek V4.1 Flash leads at 88.1%. Sakana's Fugu Cyber and Google's Gemini 3.8 Flash Cyber sit immediately behind it, within a couple of points. Once again a single open-weight model and an orchestrated system finish close to one another, with the single model narrowly ahead this time rather than narrowly behind. Leaderboard positions move, so treat the ordering as a snapshot rather than a standing result.

Two benchmarks is not a trend. But the pattern in both is the same: orchestration is competitive with the best single models rather than dominant over them, and the ordering flips depending on the task. If you were hoping the router would settle the architecture question, it has not. What it has done is make the question operational — you are no longer choosing which model is smartest, you are choosing who runs the routing and what you can see while they do it.

The honest read

Fugu Ultra v2 is a well-executed version of an idea many teams have already half-built, packaged behind one endpoint, with benchmark numbers that are strong and entirely self-published. The exclusion of the three strongest proprietary systems from its pool is simultaneously the most interesting technical claim in the release and the part most obviously shaped by commercial positioning. Both readings are available and neither is dishonest.

What the release genuinely establishes is that model choice is collapsing into a routing decision, and that routing is becoming something you can buy. That is a real change in how the stack is shaped, regardless of whether Sakana ends up being the company that wins it. If you maintain a cascade today, you now have a supplier to compare yourself against, which is more clarity than you had last week.

The useful response is not to form an opinion about Sakana. It is to go and measure the router you already own — what it costs, what it routes where, and how much engineering time it quietly consumes each quarter. If that number is small, keep it. If it is an engineer, you have just learned something worth knowing about your own architecture, and you should write it up. Measured comparisons of routing strategies are exactly the kind of work that is scarce, portable across the Indian and British markets, and far more persuasive on a Builder profile than another list of frameworks.