If you already route work through Fugu-Ultra, the update that landed on July 24, 2026 is easy to sum up: same price, newer models under the hood, and a Sakana claim of up to 7.9 points of improvement. The details worth your attention are what the benchmark claim does and doesn't prove, and one reason some users should not switch blindly.
Fugu-Ultra is not a model in the usual sense. It's the top tier of Sakana Fugu, an orchestration layer that takes your single API call and fans it out across a pool of frontier models, assigning each a role like planner, worker, or verifier, then stitches the results into one answer. You can read the setup on Sakana's official Fugu page, which is also the source for the pricing, benchmark, and availability facts below.
What's new in Fugu-Ultra v1.1
The v1.1 update swaps in newer frontier models under the hood. Sakana frames it as a refresh rather than a rebuild: same orchestration system, upgraded pool of models doing the actual work, same three tiers (Fugu, Fugu-Ultra, Fugu-Cyber).
The headline from Sakana's launch announcement is up to 7.9 points of improvement over v1.0, with the biggest gains on ProgramBench and Terminal Bench 2.1, both agentic multi-step coding suites where a single model tends to lose the thread. That is the kind of task orchestration is built for, so the direction is plausible. The size of the gain is Sakana's own number, and below is what you can and can't check about it.
The benchmarks — and what Sakana hasn't published
Here are the scores Sakana currently publishes for Fugu-Ultra:
Two things are worth knowing before you treat the +7.9 as settled.
The public benchmark table isn't split by version. It lists Fugu-Ultra scores, not a v1.0 column next to a v1.1 column, so the per-benchmark deltas behind the 7.9-point figure aren't shown anywhere you can verify them. The scores that are visible (SWE-Bench Pro 73.7, Terminal Bench 2.1 82.1, LiveCodeBench 93.2) are the same figures already published for the v1.0 build, so the visible table doesn't yet show the claimed gain.
ProgramBench, named in the announcement as a top gainer, doesn't appear in the public scorecard at all.
None of that makes the claim wrong. But if you choose models on numbers, the honest status is: treat up to 7.9 points as a vendor claim, and test it against your own tasks before quoting a delta that Sakana hasn't released.
What stayed the same: price and access
Pricing didn't move with v1.1. Fugu-Ultra is $5 per million input tokens and $30 per million output, rising to $10 / $45 once a request crosses 272K of context, with cached input at $0.50 per million. The subscription plans ($20, $100, and $200 a month) carry over too. For what that works out to once orchestration overhead is counted, we keep a running Sakana Fugu pricing and API guide that goes tier by tier.
The model ID is fugu-ultra-v1.1; the previous build was fugu-ultra-20260615. One limit if you're outside the US: Sakana lists Fugu as unavailable in the EU/EEA while it works toward GDPR compliance.
Should you switch from the v1.0 build?
For most setups this is low-risk. Same price, same endpoint, same request format, so you change the model ID and you're done. If you call the unversioned fugu-ultra alias, you are likely already on v1.1 with no change on your side.
The exception is reproducibility. If you pinned fugu-ultra-20260615 on purpose, for a regression suite, a benchmark you maintain, or output that has to stay stable, then v1.1 is a behavior change, not a free win. A refreshed model pool can shift routing and outputs, and Sakana hasn't published a migration diff. Keep the pinned ID, run v1.1 against your own eval set first, then move once it holds up.
Fugu vs. a plain API gateway
Fugu isn't the only way to reach many frontier models from one endpoint, so it's worth being clear about what the price buys.
Fugu is an orchestration layer: it decides which models to call and how to combine them, and a single task can fan out to several models, so real cost per task runs above the base token rate. That's the right trade when the work is genuinely hard and multi-step.
If the job is closer to "call one strong model reliably and cheaply," a routing gateway is the simpler path. Services like OpenRouter put many models behind one endpoint without the orchestration markup, and platforms such as AIReiter offer direct Claude and GPT API access at below list price. The quick test: if you can't name a task where one model reliably fails and coordination fixes it, you're probably paying for orchestration you don't need.
FAQ
Is Fugu-Ultra v1.1 actually better than v1.0?
Sakana claims up to 7.9 points of improvement, concentrated on agentic coding suites like ProgramBench and Terminal Bench 2.1. There's no public per-benchmark table comparing the two builds, so confirm the gain on your own tasks before relying on the figure.
How do I stay on the old v1.0 build?
Pin the model ID fugu-ultra-20260615 in your requests instead of fugu-ultra-v1.1 or the unversioned fugu-ultra alias. The alias tracks the latest build, so leaving it in place will move you to v1.1.
Is Sakana Fugu open source?
Partly. The method and supporting code are published (Sakana's orchestration is described in its TRINITY work), but the hosted service and the Conductor routing that decides which models to call are not. You can read how it works; you can't self-host the production orchestrator.
Can I use Fugu-Ultra v1.1 in the EU?
Not yet. Sakana lists Fugu as unavailable in the EU/EEA while it works toward GDPR and EU-specific compliance.
Does the price change on v1.1?
No. It ships at the same rates as v1.0: $5 input, $30 output, and $0.50 cached per million tokens, with the higher $10 / $45 tier above 272K context.