Fugu Ultra v2: What Sakana's Top Orchestrator Claims and Costs

Fugu Ultra v2 is the expensive end of Sakana AI's Fugu family: a multi-agent system behind a single OpenAI-compatible endpoint, tuned for answer quality on hard, multi-step problems rather than for cost or latency. Sakana released it on 11 September 2026, the same day as its cheaper sibling Fugu Max.

The question this guide tries to answer is narrow and practical. At five times Max's output price, what does v2 claim to buy you, how much of that claim can you check, and how do you decide whether a given task deserves it?

What v2 claims, in numbers

Unlike the original June launch, which showed its results only as images, the v2 announcement includes some figures in text:

• Chartography: 48.3, against 27.3 for Opus 5 and 29.5 for Fable 5.
• DeepSWE: 74.3.
• Overall: best or joint-best on five of eight benchmarks (GDP.pdf, Chartography, SWEFish, DeepSWE and Toolathon) and in the top two on seven of eight.

Sakana also states what is not in the pool: Fable 5, Fable 5.1 and GPT-6-Astra are excluded. So where v2 beats Fable 5 on a benchmark, it is not doing it by calling Fable 5. The training cutoff is given as 28 August 2026, which matches the knowledge cutoff in OpenRouter's catalogue.

The architecture is the same as Max. A coordinating model, descended from Sakana's TRINITY and Conductor research, decides per request whether to answer directly or build a team of models from a pool and verify their work. The difference between the tiers is the pool and the tuning, not the mechanism.

Unfamiliar benchmarks deserve a closer read

Several of the benchmarks in that list are not the ones most comparison tables use. GDP.pdf, Chartography and SWEFish are not as widely reproduced as SWE-bench or GPQA, and Sakana describes SWEFish as its own internal coding benchmark. A lead of roughly 20 points on chart understanding is large enough that you should want to know exactly what the task is before generalising from it.

That is not an accusation. Vendors choose evaluations that show their strengths, and a multi-agent system that can cross-check a reading of a chart has a plausible structural advantage there. But a benchmark you cannot inspect is evidence about the vendor's chosen tasks, not about yours. Benchmark contamination explained covers the general problem, and it applies doubly when the system under test can change its pool between runs.

Sakana's product page also carries demonstration case studies, such as an LLM training research loop and a Rubik's Cube solver, attributed to Fugu Ultra without a version. They are interesting as illustrations of what long multi-agent runs can do, but they are single setups, measured against baselines the page anonymises.

Pricing: where the 272K line bites

Sakana lists Ultra at $5 per million input tokens, $30 per million output and $0.50 per million cached input. Above 272K tokens of context, those become $10, $45 and $1.00. OpenRouter showed the base rates for sakana/fugu-ultra-v2 at the time of writing, with a 1M-token context and 128K maximum output in its catalogue.

A worked example makes the trade-off concrete. Take a request with 200K tokens of input and 10K of output:

• Ultra v2: $1.00 input plus $0.30 output, $1.30 in total.
• Max: $0.40 input plus $0.06 output, $0.46 in total.

Push the input to 300K and Ultra v2 crosses the threshold. If the higher rate applies to the whole request, as long-context tiers usually do, the same call costs $3.00 plus $0.45, or $3.45, against $0.66 on Max, which has no long-context step. Check Sakana's billing documentation for exactly how the threshold is applied, but plan on long-context work being where Ultra v2 gets expensive fastest. Context window cost trade-offs covers why trimming input usually beats paying for a bigger window.

Ultra v2 versus Max: a worked choice

Sakana's own guidance is Max for the best output at the lowest cost and Ultra v2 for the highest capability where quality is the priority. A more operational version:

1. Run your evaluation set on Max first. Most tasks in a typical workload will pass.
2. Take only the failures and run them on Ultra v2.
3. Count how many v2 recovers. If it rescues a meaningful share of hard tasks, route that task class to v2 permanently.
4. If it rescues almost none, the failures are probably in your prompts, tools or task definitions, and a stronger model will not fix them.

Because both tiers share an API shape, this two-tier route is a one-parameter switch. The cost of escalating a small fraction of requests is modest; the cost of sending everything to v2 by default is five times the output bill.

Constraints that come with it

Ultra v2 is not available in the EU or EEA, and OpenRouter notes it is not offered through EU in-region routing. Usage data may be used for training unless you opt out in the console. The Ultra pool is fixed, so you cannot exclude individual models as you can on the base Fugu tier. Sakana does not publish latency figures, and a quality-tuned multi-agent answer will typically take longer than a single model call, so measure it before putting v2 behind anything interactive.

Sakana labels the current Ultra fugu-ultra-v2.0, and OpenRouter lists no free variant. If you are moving from the original endpoint, the Fugu Ultra guide covers what changed between v1.0, v1.1 and this release, and why your evaluations need a date as well as a model name.