Sakana AI has released Fugu Max and Fugu Ultra v2, two new versions of its model-orchestration system that present a single OpenAI-compatible API while coordinating multiple underlying models. The September 11 release makes the cost-versus-capability tradeoff the product’s central claim: Max is positioned as the cheaper orchestration tier, while Ultra v2 targets the highest-quality output.
For engineering teams, the important change is not simply another benchmark table. Sakana is turning model selection itself into a managed runtime decision. That can reduce the amount of routing logic an application team owns, but it also moves more architectural responsibility into the orchestration provider.
Fugu Max makes routing a priced service
Fugu Max is priced at $2 per million input tokens, $6 per million output tokens and $0.25 per million cached input tokens. Sakana says the model expands its pool of open-weight and specialized models, including models from NVIDIA’s Nemotron family, and dynamically sends work to the model it considers appropriate for the task.
The company reports that Max achieves the best overall score in six of the benchmarks it evaluated and expands the cost-performance Pareto frontier on seven of ten. Those are vendor-run results and should be read as Sakana’s measurements rather than independent proof of superiority. The release also includes Sakana’s own SWEFish benchmark, which reflects the company’s internal coding workloads.
The pricing model is operationally more interesting than the headline benchmark claim. Fugu Max exposes one fixed API price instead of asking the application to calculate the cost of each internal model choice. For teams already building routers across several providers, that can simplify budgeting and integration.
Ultra v2 raises the ceiling but keeps the orchestration hidden
Fugu Ultra v2 is priced at $5 per million input tokens and $30 per million output tokens, with higher rates when context exceeds 272,000 tokens. Sakana reports a score of 48.3 on Chartography and 74.3 on DeepSWE, and says Ultra v2 exceeds several frontier-model baselines on its evaluation suite.
The underlying design is not a conventional single model. Sakana Fugu is itself an orchestrator model that decides how to assemble and coordinate a pool of other models. The project’s technical report describes training methods that include fine-tuning, evolutionary optimization and reinforcement learning for dynamic agent coordination.
That architecture changes what “model version” means in production. An application may call fugu-max-v1.0 or fugu-ultra-v2.0, but the behavior depends on both the orchestrator and the pool available behind it. Sakana says it expects to retrain and evaluate Fugu when new frontier models become available.
The abstraction reduces integration work but creates a new dependency
Aipolix’s analysis is that Fugu shifts the vendor-dependency problem rather than removing it. A team no longer has to bind its application directly to one frontier model, but it becomes dependent on Sakana’s routing policy, agent pool, pricing rules and model-update process.
That distinction matters for governance. If an organization needs to know which provider can receive a request, where data may be processed, or which model versions are permitted, a single API endpoint does not remove those questions. It can make them less visible. Sakana’s standard Fugu product allows users to opt specific agents out of the pool for data, privacy and compliance requirements, but the product page describes Fugu Ultra as using a fixed pool to deliver its performance.
The same issue applies to reproducibility. A benchmark or production trace tied to an orchestration product may not be reproducible later if the underlying pool or coordinator changes. Teams evaluating Fugu should therefore treat the orchestrator configuration and available model pool as part of the deployed system’s identity, not only the public model alias.
Portugal and the EU have an immediate availability constraint
Sakana’s product page states that Fugu is not yet available in the EU or EEA while the company works toward GDPR and other region-specific compliance requirements. That directly limits the practical relevance of the release for developers and organizations in Portugal today.
This is more than a launch-footnote. The architecture itself makes data-governance questions central because a request may be routed across a pool of models. For Portuguese and other European teams, the useful signal is therefore not just the lower token price. It is whether Sakana can expose enough provider, processing and policy control to satisfy EU deployment requirements when regional availability arrives.
What to verify before adopting an orchestration model
Fugu Max makes multi-model routing look like a single-model purchase, which is a meaningful developer-experience improvement. But engineering teams should evaluate the system as an orchestration layer: which models may handle data, how pool changes are versioned, how costs are accounted for, whether routing decisions are observable, and what happens when a provider or model is removed.
Sakana has shipped a concrete API and published the architecture behind the Fugu family, so this is more than a conceptual multi-agent demo. The remaining question is whether the operational controls around the model pool mature at the same pace as the benchmark and pricing story.