Fugu Max and Ultra v2 turn several models into one API

When an application calls fugu-max, it is not choosing one model that will answer from beginning to end. It is handing that choice to another model. That model may decide which workers to use, assign subtasks to them, share selected results among them, and synthesize an answer. The interface retains the familiar shape of a model call; the real unit of computation has become a team.

Sakana AI launched Fugu Max and Fugu Ultra v2 on September 11. Max seeks the best performance-price tradeoff using the company's broadest pool, which includes open-weight Nemotron models. Ultra v2 spends more work on complex problems and pursues maximum quality. Both are available through an OpenAI-compatible API, and an existing integration can switch by changing only the model identifier.

That is a practical novelty, not merely a different name for a router. A developer can submit a task without prescribing whether it needs a cheap model, a visual specialist, several coding agents, or a verification round. Sakana trains a coordinator to make those decisions from the request and task state. The product moves part of system design—which model calls which other model and when—from application code into a learned policy.

The model is also the organization of work

The Fugu technical report, published for the first version in June, describes two mechanisms. The fast variant uses the internal states of a coordinator model and a small selection head to choose one worker at each step. It was first trained on verifiable tasks: all candidate models were run, and the coordinator learned which tended to perform best. It was then optimized on real coding-agent trajectories, where reward depended on completing the task rather than merely answering an isolated question well.

Ultra follows the Conductor line, a model trained with reinforcement learning to write workflows in natural language. It can divide a request, assign each part to a worker, and decide which previous outputs the next worker will see. These workflows are not limited to the simple pattern of “one proposes and another reviews”: they can form chains, parallel branches, votes, or recursive calls to the coordinator itself. The earlier TRINITY work contributes the lightweight approach for iterative selection of models and roles.

This explains why calling Fugu a “model” is not entirely false, even if it is incomplete. Trained weights are making decisions; it is simply that much of the capability received by the user comes from worker models and additional inference-time computation. It resembles evaluating a team by its final result, except that here the organization chart is generated again for each problem.

It also clarifies what this release does not open. Fugu Max incorporates open-weight models, but neither Max nor Ultra v2 is a downloadable checkpoint. They are hosted services. The model documentation says Max and Ultra have fixed pools; only standard Fugu lets users exclude providers in the console. The page does not enumerate the complete updated pool. Ultra v2 explicitly excludes Claude Fable 5, Fable 5.1, and GPT‑6 Astra, showing that its results are not a concealed call to those three systems, but not that all its workers are open or that provider dependence has disappeared.

Availability itself draws another boundary: the service is not yet offered in the European Union or European Economic Area while Sakana works toward GDPR compliance. A compatible API lowers the cost of migrating code; by itself, it does not resolve data residency, contracts, auditability, or continuity for every model behind it.

A token's price is not the price of solving a task

Sakana says Max achieves the best aggregate result on six benchmarks and extends the performance-cost frontier on seven of ten. For Ultra v2, it reports the best or joint-best result on five of eight tests spanning coding, tools, documents, and visual reasoning. The interesting claim is not that all these tests represent general intelligence. It is that a policy selecting and coordinating workers can outperform any one of them on tasks that benefit from planning, execution, and review.

But the public evidence from September 11 remains a provider evaluation. The report linked from the announcement is still the June version and documents the pool, configurations, and results for Fugu Ultra v1, not the new Max and Ultra v2 experiments. The announcement supplies charts and aggregate results, but not the runs, answers, number of internal calls per task, or a recipe another party could use to reconstruct the comparison. One cited evaluation, SWEFish, is also an internal set based on Sakana's own coding challenges and use cases.

There is a second difficulty on the cost axis. According to the public price sheet, Max costs $2 per million input tokens and $6 per million output tokens. Ultra v2 costs $5 and $30 respectively at standard context lengths. These are attractive unit prices, but they do not say how much it costs to finish a task. For Ultra, the same documentation separates visible tokens from tokens used internally for orchestration and explains that the latter count toward the bill. If several workers read long contexts, produce proposals, and verify one another, a short final answer may rest on many more billable units.

Comparing only dollars per million output tokens therefore puts unlike quantities side by side: a token from a direct model and the final token of a system that may have run several models first. The useful comparison for builders is cost per solved task at a specified latency and error rate. It should also include run-to-run variation, because an orchestrator may choose different teams for similar requests.

This does not invalidate the savings. A policy able to send many requests to small models and reserve expensive teams for difficult cases may reduce total spending. It may even improve availability by replacing a worker that disappears. But those advantages must be observed on a real work distribution, including failed attempts and internal computation; they do not follow from a nominal rate or from selecting the best point on each chart.

My reading is that Fugu Max signals an important shift in the model market. An endpoint stops promising a stable technical identity and starts promising a service level: “give me the best result this budget permits.” That may be exactly what an application needs. It also concentrates power in a new layer, because the orchestrator decides which providers receive the data, how much compute to spend, and which version of each worker influences the result.

The missing test does not require another giant scoreboard. Sakana could publish a versioned pool manifest for Max and Ultra v2, evaluation configurations, total token and wall-clock expenditure per task, complete attempts from a reproducible sample, and results against simple routers under the same budget. Sensitive deployments would also need per-response provenance: which classes of model participated and under which data rules, even if private reasoning traces remain closed.

Fugu makes convenient an idea that previously required custom infrastructure: treating coordination as a way to scale inference. The conceptual jump is real. The next editorial and technical discipline should be equally clear: when a variable organization of models works behind “one model,” capability, cost, privacy, and dependence can only be evaluated at the level of the complete system.

Sources

• Sakana AI, Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier, September 11, 2026.
• Sakana AI, Sakana Fugu Technical Report, version 2, June 23, 2026.
• Sakana AI, model and API documentation and pricing and orchestration-token accounting, accessed September 12, 2026.
• Sakana AI, Learning to Orchestrate Agents in Natural Language with the Conductor and TRINITY: An Evolved LLM Coordinator, work accepted at ICLR 2026.