Sakana Fugu Max: What Buying an Orchestrator Instead of a Model Means for Your Stack

Sakana AI shipped two models on September 11, 2026: Fugu Ultra v2, a flagship orchestrator we compared against GPT-6 Astra in our earlier look at orchestration versus a frontier monolith, and Fugu Max, the cheaper sibling most teams will actually deploy. Fugu Max is priced at 2 dollars per million input tokens and 6 per million output, and Sakana states that output pricing runs 40 to 60 percent under Sonnet 5, GPT 5.6 Terra, and Kimi K3. That price point puts an orchestrator model, not a single trained model, in direct competition with mid tier frontier pricing for the first time, and it is worth treating as its own decision rather than a footnote to the Ultra v2 story.

Attribute	Fugu Max	Typical mid tier frontier model
What you call	One API, one coordinator	One API, one trained model
What runs behind it	A pool of specialist models, routed per task	The model itself
Input price	$2 per million tokens	Varies, often comparable or higher
Output price	$6 per million tokens	40 to 60 percent higher, per Sakana's comparison
Availability	Hosted API only, not offered in the EU or EEA	Varies by vendor
Failure mode to evaluate	Coordinator misroute on your specific task shape	Model capability gap on your specific task shape

Buying coordination instead of buying capability

The standard way to choose a model is to evaluate its capability directly: run your evaluation set against it, look at benchmark scores, check the price per token, decide. Fugu Max breaks that model in a specific way, because the thing you are actually purchasing is not a fixed capability, it is a coordinator's judgment about which of several specialist models should handle each part of your task. Two calls to Fugu Max with similar prompts can be served by different combinations of underlying models depending on what the coordinator decides, which means the capability you get is a function of the router's quality on your specific task shape, not a fixed property of "the model" the way it is with a single trained system.

This is the same shift we described from the architecture side in multi agent orchestration patterns: a router in front of a pool of models is a pattern plenty of engineering teams already hand build. Fugu Max is that pattern productized and sold as a single hosted endpoint, with Sakana absorbing the work of building and tuning the router. The tradeoff is that you give up visibility into which specialist handled your request and control over that routing, in exchange for not having to build, evaluate, and maintain the coordination layer yourself.

Why the price comparison is more interesting than it looks

A 40 to 60 percent discount on output tokens against Sonnet 5, GPT 5.6 Terra, and Kimi K3 sounds like a straightforward cost argument, and for high volume, mixed difficulty workloads it likely is one. But the honest framing is that Fugu Max's cost is not a fixed per token rate the way those comparison models' pricing is. It is a function of how often the coordinator routes a given request to a cheap specialist versus an expensive one. Sakana's published price is what you pay at the API level regardless of which specialists handled the work underneath, which means the economics work in your favor specifically when your workload has a mix of easy and hard subtasks that a router can meaningfully differentiate.

For a workload that is uniformly hard, every request needing frontier level reasoning, an orchestrator has less room to route around expensive specialists and the cost advantage compresses. For a workload that is uniformly easy, you likely do not need frontier capability or an orchestrator at all, and a smaller dedicated model is probably cheaper still. The orchestration pricing model earns its keep specifically in the middle: mixed difficulty task streams where a coordinator can send the hard 20 percent to something capable and the easy 80 percent to something cheap, all behind one integration.

What this changes about evaluation

If you are used to evaluating a model against your own held out task set and getting a stable, repeatable capability read, evaluating an orchestrator requires a different mental model. You are not just testing whether the system can do the task, you are testing whether the router's decisions on your specific task distribution are good ones, and that can shift as Sakana updates the coordinator or the pool of specialists it draws from, independent of any change you make on your end. Version pinning and periodic re evaluation matter more here than they do for a single model with a stable checkpoint, because the thing generating your output is a decision process that the vendor can and will keep changing.

The upside is that an orchestrator can, in principle, get better over time on your workload without you doing anything, as Sakana improves the coordinator or expands the specialist pool. The downside is the same coin flipped: it can also degrade on a specific task pattern you depend on, without a version number change you can point to as the cause. Treat an orchestrator subscription more like a managed service with an SLA you should monitor continuously than like a model checkpoint you evaluate once and trust.

Where this fits against a hand built router

Teams that already run a router in front of a pool of models they pay for directly have a real alternative to Fugu Max: keep building and tuning that router themselves, informed by what Sakana's benchmarks suggest is achievable. We looked at the open weights side of that build versus buy question in Kimi K3 versus GPT-6 Astra on open weights, GPQA, and cost, and the orchestration layer adds a second axis to that same decision: not just which models to run, but whether to pay someone else to route between them or to own that routing logic yourself. Owning it gives you visibility and control over which specialist handled a given request, at the cost of building and maintaining the evaluation harness that tells you whether your routing decisions are actually good ones.

FAQ

What is Fugu Max? An orchestrator model from Sakana AI, released September 11, 2026 alongside Fugu Ultra v2. It coordinates a pool of specialist models behind a single API call rather than generating answers as one trained model, and it is priced at 2 dollars per million input tokens and 6 per million output.

How much cheaper is Fugu Max than a frontier model? Sakana states its output pricing runs 40 to 60 percent below Sonnet 5, GPT 5.6 Terra, and Kimi K3, though the actual savings on your workload depends on how much of your task mix the coordinator can route to cheaper specialists.

Is Fugu Max the same as Fugu Ultra v2? No. Fugu Ultra v2 is the flagship orchestrator, benchmarked directly against GPT-6 Astra in our earlier post. Fugu Max is the cheaper sibling most teams evaluating cost sensitive, mixed difficulty workloads will actually deploy.

Does Fugu Max work everywhere? It runs as a hosted API only and is not offered in the EU or EEA at launch.

When this applies to your stack

If your workload is a mix of easy and hard subtasks and you are currently paying frontier rates on every request regardless of difficulty, Fugu Max is worth an evaluation specifically on cost per completed task rather than a benchmark score. If you already run a hand built router, the question is whether Sakana's coordination is good enough on your task shape to justify handing that logic to a vendor. Either way, building the evaluation harness that answers that question, and the agent architecture that acts on it, is the kind of AI infrastructure work we do at Contra Collective.