Fugu Ultra v2: Sakana's Orchestrator Model, Explained

Every model release this year has been some variation of “bigger, cheaper, or faster.” Fugu Ultra v2, which Sakana AI shipped on September 11, is none of those. It’s an argument that the next gain in LLM output isn’t a better model at all. It’s a better dispatcher.

Send it a request and Fugu doesn’t answer directly. It reads the task, decides which model or combination of models in its pool is best suited, routes the work, and stitches the results into one response. You call one OpenAI-compatible endpoint. What happens behind it is, by Sakana’s own description, hidden by design.

What Fugu actually is

Sakana calls it a multi-agent system that behaves like a single model. Fugu itself is a trained coordinator, not a generalist: its job is deciding when a task is simple enough for one model versus when it needs several working in sequence or parallel, then verifying and synthesizing what comes back. The approach draws on two of Sakana’s own ICLR 2026 papers, Trinity and Conductor.

Both are about teaching a coordinator model to route and combine work from other models, rather than doing the work itself.

Two versions shipped the same day. Fugu Ultra v2 is the accuracy-first tier: $5 per million input tokens, $30 per million output tokens, a 1 million token context window, and 128,000 tokens of maximum output. Fugu Max is the cost-first tier, built more heavily on open-weight and specialist models, including NVIDIA’s Nemotron family, at $2 input / $6 output per million tokens.

Here’s the detail that should give you pause before assuming “Ultra” always wins: Fugu Max beats Fugu Ultra v2 outright on six of Sakana’s benchmarks, Terminal Bench 2.1 among them. Paying more doesn’t automatically buy you a better result. It buys you a different routing strategy, tuned for a different kind of task.

The numbers, and what they actually mean

On Chartography, Sakana’s visual-reasoning and data-interpretation benchmark, Fugu Ultra v2 scores 48.3. Opus 5 scores 27.3 on the same test. On DeepSWE, a software-engineering benchmark, Fugu Ultra v2 hits 74.3.

Those are Sakana’s own numbers, from Sakana’s own benchmark suite, so treat the margins with the skepticism you’d apply to any vendor publishing a comparison that flatters its own product. What’s harder to dismiss is the training cutoff: August 28, 2026, meaning the coordinator has been retuned against a current generation of frontier models, not last year’s. That’s not nothing. A router trained against stale models routes badly, the same way a load balancer tuned for last quarter’s traffic pattern mis-allocates today’s.

What Sakana won’t tell you is which models are actually in the pool for a given request. That’s the real tradeoff here, and it’s worth being blunt about: you’re buying better outcomes on the tasks Fugu was built for, at the cost of losing the ability to reason about why a particular answer came back the way it did. If your team already treats LLM routing as production infrastructure, building fallback logic and cost caps around tools like LiteLLM or OpenRouter, Fugu is a different animal entirely. Those tools route to models you choose and can name. Fugu routes to models it chooses and won’t name.

Where this fits against everything else that shipped this month

September has been a genuinely crowded month for model releases: GPT-6 Astra shipped tiered access gated by enterprise partnership, and Gemini 3.8 Flash landed as a quiet, same-price iteration. Fugu is the first release in that window that isn’t trying to be a better base model at all. It’s making a bet that orchestration, not raw capability, is where the next real gains sit for tasks that already stretch a single model’s context or reasoning depth.

That bet only pays off for specific workloads. A multi-step agent pipeline, a visual-reasoning task, a software-engineering benchmark where combining a coding-specialized model with a verification pass genuinely changes the outcome, those are Fugu’s target. A customer-support chatbot answering FAQ questions is not. Paying $30 per million output tokens to route a question that any $2 model answers identically is money spent on architecture you don’t need.

Should you actually use it

Test it on the workload it’s built for before you touch anything else. If you’re running an agentic pipeline that already chains multiple model calls by hand, point one representative task at Fugu Ultra v2 and compare cost and output quality against your current chain, not against a single model in isolation, since that’s not the comparison Fugu is making. If the workload is simpler than that, work out what the feature actually costs to run today before adding another routing layer on top of it. Skip Fugu entirely if you serve EU or EEA users; Sakana hasn’t cleared GDPR compliance yet, and building a production dependency on a service you can’t legally serve to part of your user base is a mistake you’ll have to unwind later.

The interesting question isn’t whether Fugu’s benchmarks hold up under independent testing, though that’s worth watching. It’s whether “route, don’t reason” becomes the default shape of the next wave of AI products, the way “retrieve, then generate” did for RAG. One release doesn’t answer that. It does mean it’s no longer a hypothetical worth ignoring.