Fugu Max vs Fugu Ultra v2: Which Should You Use?

01

Overview

Sakana AI now offers two clearly differentiated orchestration options for developers: Fugu Max and Fugu Ultra v2. Both sit behind Sakana's OpenAI-compatible API, but they target different optimization goals.

The short answer is simple: Fugu Max is the better starting point when cost-performance matters; Fugu Ultra v2 is the better test when maximum result quality on difficult work matters more than token price. That is a product-positioning distinction, not a universal benchmark verdict.

02

Fugu Max vs Fugu Ultra v2 at a glance

Fugu Max is designed around efficient orchestration across a larger pool of open-weight and specialist models. Fugu Ultra v2 is designed for harder multi-step reasoning, autonomous research, visual and structured-data analysis, and software-engineering work where Sakana prioritizes peak output quality.

Both use fixed model pools in their current form. Both are available through the same OpenAI-compatible Fugu API family. The biggest practical differences are price, orchestration objective and the kinds of workloads Sakana is optimizing for.

03

Pricing comparison

Sakana currently lists Fugu Max at:

• $2/M input tokens.
• $6/M output tokens.
• $0.25/M cached-input tokens.

Fugu Ultra v2 is currently:

• $5/M input tokens.
• $30/M output tokens.
• $0.50/M cached-input tokens.

For context above 272K tokens, Ultra pricing increases to $10/M input, $45/M output and $1/M cached input. Sakana's pricing page says Fugu Max's listed rates remain fixed regardless of context length.

Both can also incur separate web_search or web_fetch charges, currently $0.007 per call.

04

What those rates mean in practice

The output-price gap is the most important difference for long-form and agentic workloads. Ultra v2's standard output price is five times Max's current output rate.

For illustration, a request using one million uncached input tokens and generating 250,000 output tokens would cost about $3.50 at Max's listed rates and $12.50 at Ultra's standard listed rates, before tool calls. The numbers are simple arithmetic from Sakana's published rates; they are not a guarantee of total cost per task.

If Ultra's stronger orchestration solves a difficult task in one pass that would otherwise require multiple failed attempts, the higher token rate could still be economically sensible. Conversely, if Max already clears your quality bar, paying Ultra's premium adds little value.

05

When Fugu Max makes more sense

Start with Fugu Max when your application has recurring or high-volume work and you need a strong quality-to-cost ratio. Natural candidates include coding assistance, routine analysis, content transformation, automation, back-office agents and research tasks where a slightly more expensive result is not automatically more valuable.

Sakana says Max expands its pool with open-weight and specialist models, including NVIDIA Nemotron models, and dynamically selects efficient combinations. That architecture is relevant to teams that want the benefits of model routing without operating the routing layer themselves.

06

When Fugu Ultra v2 makes more sense

Ultra v2 is more compelling when the cost of a weak result is high: difficult software tasks, deep autonomous research, complicated multi-step analysis, charts/structured-data reasoning or high-value strategic work.

Sakana positions Ultra v2 as the quality-first tier and reports strong results on benchmarks such as Chartography, DeepSWE and its SWEFish evaluation. Those are Sakana's own evaluations. They support the product positioning but do not prove Ultra wins every real-world workload.

07

Benchmark claims need context

Sakana reports that Fugu Max achieved the best overall score in its comparison on six benchmarks and improved the cost-performance Pareto frontier on seven of ten. It also highlights Ultra v2 scores including 48.3 on Chartography and 74.3 on DeepSWE.

These are vendor-run benchmark results. A buyer should not translate them into a blanket conclusion such as 'Ultra is better than Claude' or 'Max beats GPT.' Benchmark methodology, underlying model pools, task distributions and future model updates all matter.

The more useful question is whether Max or Ultra performs better on the exact tasks your application runs repeatedly.

08

Context-length pricing

One practical advantage of Max is pricing simplicity: the current page lists the same Max token rates regardless of context length. Ultra v2 introduces a higher price tier above 272K context.

Do not interpret 272K as Ultra's maximum context. It is a pricing threshold disclosed by Sakana, not a published hard context ceiling in the sources used here.

If your application regularly sends very large codebases, document collections or long agent histories, this surcharge can materially change the cost comparison and should be included in benchmarks.

09

Privacy and model-provider constraints

There is an important operational tradeoff. Sakana says regular Fugu can let customers opt out of specific models in its pool, while Fugu Max and Fugu Ultra use fixed pools. Enterprise customers that need a custom configuration can contact Sakana.

That means teams in regulated environments should not choose Max or Ultra solely on quality and price. The acceptable set of underlying providers and data-handling terms may determine whether the product fits at all.

10

Latency: do not assume the cheaper tier is faster

Sakana does not publish one universal latency figure that applies to every Fugu Max or Ultra request. Multi-agent orchestration can take different paths depending on a prompt.

Do not assume Max is automatically faster because it is cheaper, or that Ultra is always slower because it does more work. Measure end-to-end latency on representative requests and include retries, tools and time-to-acceptable-answer in the comparison.

11

A practical selection framework

Use a simple evaluation instead of choosing from benchmark headlines:

1. Collect 30–100 real tasks representative of production.
2. Run the same tasks through Max and Ultra with the same application-level instructions.
3. Record answer acceptance rate, human correction needed, latency, token use and tool calls.
4. Separate easy/routine work from high-complexity work.
5. Compare cost per accepted result, not only cost per token.
6. Check provider/privacy requirements before deciding.
7. Route only the tasks that genuinely benefit from Ultra to the higher-cost tier if a mixed strategy works better.

This approach also avoids a false either/or decision. Some applications may use Max by default and escalate only the hardest tasks to Ultra.

12

Which should creators, marketers and automation teams test first?

For most ProjectMonet.space-style workflows—marketing research, content systems, SEO analysis, automation and general business agents—Max is the more sensible first benchmark because its token rates are substantially lower and its goal is explicitly cost-performance.

Ultra becomes interesting when those workflows include difficult code generation, deep autonomous investigation, large structured datasets or tasks where a materially better answer has high business value.

That recommendation is based on the products' current positioning and pricing, not on a claim that Max or Ultra universally wins those categories.

13

FAQ

Is Fugu Max cheaper than Fugu Ultra v2?

Yes under Sakana's current published token prices. Max is $2/M input and $6/M output; Ultra v2 is $5/M input and $30/M output at standard context lengths.

Does Ultra v2 always produce better answers?

No universal claim can be made. Sakana positions Ultra as quality-first and publishes vendor benchmark results, but workload-specific testing is still necessary.

Does Max support long context without a surcharge?

Sakana's current pricing page lists Max at fixed token rates regardless of context length. That is a pricing statement, not a claim about an unlimited context window.

Can I exclude specific models from Max or Ultra?

Sakana says Max and Ultra currently use fixed pools. Custom provider configurations are an enterprise discussion.

Can one application use both?

Yes in principle: both are exposed in the Fugu API family with separate model IDs. A team can benchmark or route workloads between them at the application level.

Which one should I test first?

Start with Max if you are cost-sensitive. Test Ultra on the subset of tasks where a quality improvement would justify the higher output price.