Fugu Max: Sakana AI Bets on Orchestration for Cheap Frontier Work

Most model guides start with architecture: parameters, experts, context. That framing does not work for Fugu Max, because Fugu Max is not one set of weights in the usual sense. It is a coordinating model that decides, per task, which other models to call, how to split the work between them and how to check the result, and then hands you one answer through one endpoint.

Sakana AI released it on 11 September 2026 alongside Fugu Ultra v2. Where Ultra is tuned for peak quality, Max is tuned for the cost-performance trade-off: route each task to the leanest model that can handle it and only escalate when the task needs it.

A model that is mostly a router

The Fugu family comes out of two ICLR 2026 papers from Sakana. TRINITY uses a very small evolved coordinator, under 20,000 learnable parameters on top of a compact language model, that assigns models in a pool to Thinker, Worker or Verifier roles over several turns. The Conductor is a 7B model trained with reinforcement learning to write the coordination plan in natural language: which agent to call, what prompt to give it, and which earlier messages it may see.

Sakana describes Fugu as itself a language model trained to decide when to delegate and how its agents should communicate. For a simple question it can answer directly; for a harder one it assembles a team from its pool and handles delegation, verification and synthesis internally. The routing per query is proprietary, so you see the result and the token bill, not the internal call graph.

If you already run model routing yourself, this is the same idea moved behind the API and made adaptive per request rather than per rule.

What sits in the Max pool

Sakana says Max orchestrates the largest pool of open-weight and specialised models it has offered, including NVIDIA's Nemotron family through a collaboration with NVIDIA. It does not publish the full list.

Two consequences follow. First, the pool is fixed for Max: the base Fugu tier lets you exclude specific models in the console, but Max and Ultra do not, so if a compliance rule forbids a particular provider you cannot carve it out here. Enterprise customers can ask for custom configurations. Second, the pool can change over time; Sakana says an updated model typically takes about two weeks of training and evaluation after a new frontier model becomes public. Behaviour on your workload can shift without a model name changing.

The price, and what it is compared against

Sakana lists Fugu Max at $2 per million input tokens, $6 per million output and $0.25 per million cached input, with no step-up at long context. Built-in web_search and web_fetch calls cost $0.007 each. OpenRouter listed the same token rates at the time of writing, with a 1M-token context window and 128K maximum output in its catalogue; Sakana's own page does not state a context limit.

Sakana's launch post says Max's output price is 40 to 60 percent lower than Sonnet 5, GPT 5.6 Terra and Kimi K3. Comparison prices date quickly, so check them against current list rates before relying on the percentage. The less obvious point is what a flat price means for an orchestrator: you pay $6 per million output tokens regardless of which model inside the pool produced them, so the vendor absorbs the routing risk. That makes the bill more predictable than running a similar multi-model setup yourself, where an escalation to an expensive model shows up directly on your invoice.

There is also a subscription route, from $20 to $200 a month, which includes Max, Ultra and the base Fugu tier.

Claims without numbers

Sakana says Max achieves the best overall score on six benchmarks, Terminal-Bench 2.1, GPQA Diamond, AA-LCR, GDP.pdf, AutomationBench and SWEFish, and extends the cost-performance Pareto frontier on seven of ten. The launch material gives these as charts and rankings rather than scores, so there is nothing precise to cite.

That is a reason to test rather than a reason to dismiss. Pareto claims are only meaningful against a specific set of competitors and price points, and an orchestrator is unusually sensitive to task mix: a pool tuned to escalate rarely will look superb on cost for routine work and less so on the long tail. Building a 20-task eval from your own work is the only way to find out where your tasks fall.

Max or Ultra v2

Sakana's own guidance is short: Max for the best output at the lowest cost, Ultra v2 for the highest capability on complex multi-step work. The price gap is large. Fugu Ultra v2 lists at $5 input and $30 output, five times Max on output, and its rates rise again above 272K tokens of context, to $10 input and $45 output.

A reasonable default is to start on Max and escalate specific task classes only when your eval shows Ultra v2 solving something Max does not. Because both share the same API shape, switching is a one-parameter change, which makes a two-tier route cheap to build.

Practical constraints before you adopt it

• Region: Fugu is not available in the EU or EEA, and OpenRouter notes it is not offered through EU in-region routing.
• Data use: usage data may be used to improve Fugu unless you opt out in the console.
• Latency: a multi-agent answer can take longer than a single model call, and Sakana does not publish latency figures. Measure it on your own requests.
• Reproducibility: OpenRouter lists one id, sakana/fugu-max, and Sakana labels the current version fugu-max-v1.0, so record the date of any evaluation and re-run it periodically.

The decision rule is simple. If your workload is broad, mostly routine, and you value a predictable per-token price over control of exactly which model answers, Max is worth an evaluation. If you need to know and fix which model touched your data, run your own routing instead.