Fugu Ultra: Sakana AI's First Quality-First Orchestrator

Fugu Ultra is a useful model to study for a reason that has little to do with its scores. It is a product whose underlying models change while its name stays the same, and it went through three versions in under three months. If you build on orchestrated models, how you handle that matters more than any single benchmark.

This guide covers the original sakana/fugu-ultra endpoint: what Sakana shipped in June 2026, what changed in July, and how to think about it now that Fugu Ultra v2 exists as a separate listing.

What shipped in June

Sakana AI made Fugu generally available on 22 June 2026 with two tiers: Fugu, a default balanced for latency, and Fugu Ultra, tuned for answer quality on hard multi-step problems. OpenRouter's catalogue dates its sakana/fugu-ultra listing to 24 June. A beta had run since April with close to 500 early users.

Both tiers present as a single model behind an OpenAI-compatible API, but underneath they are multi-agent systems. A coordinating model, built on Sakana's TRINITY and Conductor research, decides whether to answer directly or assemble a team from a pool of other models, then handles delegation, verification and synthesis. It can call instances of itself recursively. The launch post stresses that the pool is swappable, so the system can route around a provider that restricts access.

Sakana's launch claim was that Ultra stands shoulder to shoulder with Fable 5 and Mythos Preview on engineering, science and reasoning benchmarks, even though neither of those models was in its pool, because neither was publicly accessible. The comparison figures for other models were provider-reported, and the launch page shows its results as images rather than numbers in text.

v1.1: same name, different pool

On 24 July 2026 Sakana announced Fugu-Ultra v1.1. The change was not new weights in the usual sense. The orchestration engine now drew on newer frontier models, which Sakana says raised performance by as much as 7.9 points over v1.0, with the strongest gains on ProgramBench and Terminal-Bench 2.1. The price stayed the same.

The same announcement added Claude Code-compatible endpoints, so Fugu's orchestration could run inside Claude Code as the backing model. That is a telling detail: the target user was a developer running long agentic coding sessions, which is where a slow but careful multi-agent answer is easiest to justify.

Sakana also says, in its product FAQ, that an updated Fugu typically takes about two weeks of training and evaluation after a new frontier model becomes public. In other words, pool updates are the normal release cadence, not exceptions.

The versioning problem with orchestrated models

With an ordinary model, a version string pins behaviour. With an orchestrator, the version describes the coordinator and the pool together, and either can move. For anyone running evaluations, three things follow.

• Your eval has a date, not just a model name. A pass rate measured on v1.0 in June tells you little about the same endpoint in August.
• Regressions can come from the pool. If a task class gets worse, the cause may be a member model you never chose and cannot see.
• The unversioned name is ambiguous. Sakana's current product page labels the Ultra tier as fugu-ultra-v2.0. Which version the original sakana/fugu-ultra listing resolves to today is not stated in anything we could read, so check with the provider rather than assuming.

The fix is the one covered in agent regression suites: keep a fixed set of tasks, run it on a schedule, and alert on changes rather than relying on release notes. For an orchestrated model, that is not optional hygiene; it is the only way you will notice a pool change.

Cost and access

OpenRouter listed sakana/fugu-ultra at $5 per million input tokens and $30 per million output at the time of writing, with $0.50 for cached input. Sakana's own pricing for the Ultra tier matches and adds a long-context step: above 272K tokens of context the rates become $10, $45 and $1.00. A multi-agent answer can use more tokens than a single call to produce, so per-request usage, which Sakana reports, is the number to watch rather than the list price.

The constraints are the same across the Fugu family. It is not available in the EU or EEA. Usage data may be used for training unless you opt out in the console. The Ultra pool is fixed, so unlike the base Fugu tier you cannot exclude individual models. OpenRouter lists no free variant of it.

Ultra or Ultra v2

For new work, start with the explicitly versioned v2 listing. It is the current Ultra, it publishes a training cutoff and concrete benchmark figures, and choosing a versioned name makes your intent clear in code. Keep the original endpoint only if you have an existing evaluation on it and want continuity while you re-run that evaluation on v2.

If quality is not the overriding constraint, look at Fugu Max first. It shares the same architecture, lists at $2 input and $6 output, and is aimed at routine work where a five-times output price is hard to defend.

Whichever you pick, write down three things next to every result: the model identifier, the date, and the per-request token count. With an orchestrator, those are what make a result reproducible.