Fugu Ultra: How an AI Orchestrator Model Challenges GPT and Claude

What matters here isn't the score on a leaderboard. It's the thinking behind how that score was produced.

Keeping up with AI model launches over the last year, you start noticing a pattern.

More parameters.

Bigger context windows.

A handful of extra benchmark points.

Cheaper tokens.

Yet another "most capable model yet."

Then, on September 11, Sakana AI unveiled Fugu Ultra v2.0, and something about this particular announcement broke the pattern.

It wasn't the benchmark scores themselves that stood out.

What caught attention was the mechanism producing those scores.

Fugu Ultra doesn't aim to be the single smartest AI model on the planet.

Instead, it pursues a different question entirely:

What if the strongest AI setup isn't one model, but a system smart enough to know which model should handle which piece of a problem?

That question may matter more in the long run than any single benchmark win.

So, What Exactly Is Fugu Ultra?

Here's the first detail that sets Fugu apart from the pack.

Fugu Ultra doesn't work like a standard model in the vein of GPT or Claude.

Sakana instead frames it as a controller, or orchestration layer.

Picture it as a skilled engineering manager overseeing a team.

You hand it a complex request.

Rather than trying to handle every part of that request itself, the controller can:

1. Parse what's being asked
2. Split the request into smaller subtasks
3. Figure out which specialist model fits each subtask
4. Hand off the work accordingly
5. Merge the outputs
6. Add its own reasoning on top when needed

Say you submit a request like:

"Go through this company's financial report, generate a chart, flag any anomalies, and summarize the findings."

A conventional model would try to power through the whole request using one unified set of skills.

An orchestrated system treats the same request more like a project handed to a team:

Document parsing → a specialist model Interpreting the data → a different specialist Reasoning about the chart → a vision or data-focused specialist Writing code → a coding specialist Pulling it all together → the controller

From your side, it still looks like a single API call.

Behind the scenes, though, you're really interacting with a roster of AI models coordinated by another AI system.

Sakana's model pool is reported to combine open-weight models with specialized ones, among them NVIDIA's Nemotron lineup.

That's where this starts getting genuinely interesting.

The Benchmark Numbers

Based on Sakana's self-reported figures, Fugu Ultra v2.0 turned in strong results across several benchmark categories.

The company states that Fugu came out best or tied for best on 5 out of 8 benchmarks, and landed in the top two on 7 out of 8.

One figure that jumps out right away is DeepSWE: 74.3.

DeepSWE deserves attention because it measures software-engineering ability rather than testing simple coding puzzles.

Fugu also posted strong numbers on Chartography, SWEFish, GDP.pdf, and Toolathon.

Fugu Ultra v2 vs Other Frontier Models

According to the reported comparisons, Fugu Ultra v2 outperformed several well-known systems, among them:

• Claude Opus 4.8
• GPT-5.5
• Gemini 3.1 Pro

It's also claimed to particularly excel at Chartography, a benchmark built around interpreting charts and other structured visual data.

Here's the key qualifier:

These are figures Sakana reported about its own system.

As of the reporting covered here, no independent lab had reproduced these numbers.

That distinction matters.

A benchmark released by the company that built the model can look impressive and still need outside verification before it's fully trusted.

So the fair way to treat these results is:

Genuinely interesting. Worth digging into further. Not yet a settled conclusion.

The Benchmark Picture

Arguably, the most telling number here isn't any single score, but the 5-out-of-8 figure.

Why does that matter more?

Because winning one specific benchmark can often just mean a model was tuned for that particular task.

Landing near the top across a spread of different task types is a more meaningful signal.

Still, it's worth repeating: these are self-reported results, not independently confirmed ones.

The More Interesting Comparison: How These Systems Think

The real distinction here probably isn't the score itself.

It's the underlying architecture.

Traditional Frontier Model

User
  ↓
One large model
  ↓
Answer

GPT, Claude, and Gemini all largely follow this design, though their current products increasingly bolt on routing logic, tool use, and agent-like behavior of their own.

Fugu's Approach

┌── Coding specialist
                 │
User → Controller├── Vision specialist
                 │
                 ├── Reasoning specialist
                 │
                 └── Other models
                         ↓
                    Final answer

This reframes the whole optimization challenge.

Instead of asking:

"How do we build a single model that's better at everything?"

Sakana is essentially asking:

"How do we get better at picking the right model for each specific problem?"

That's a fundamentally different wager to make.

Fugu vs Claude vs GPT vs Gemini vs DeepSeek

So how does Fugu compare against the systems you'd normally consider when picking an AI provider?

Claude

Claude is still one of the go-to choices for demanding reasoning, coding, and long-form writing tasks.

Its main strength is that you get a single, highly capable general-purpose model straight out of the box.

There's no need to think about coordinating multiple models yourself.

Fugu takes the opposite stance: the orchestration itself is the product.

GPT

OpenAI has generally focused on pushing general-purpose model capability upward while layering on tools and agentic features.

Fugu's philosophy runs in nearly the opposite direction:

Rather than forcing a single model to handle everything,

it builds a system designed to coordinate several models at once.

That difference matters more and more as the pool of available models keeps growing.

Gemini

Gemini tends to shine when multimodal input, very large context windows, or integration with Google's broader ecosystem are priorities.

What sets Fugu apart isn't multimodal support or context length on their own.

It's the routing layer that sits on top of multiple underlying models.

DeepSeek

DeepSeek offers yet another angle worth considering.

Its appeal for many developers comes down to something simple:

solid performance at an aggressive price point.

Fugu is chasing a different goal entirely.

Rather than asking:

"Which is the cheapest model capable of handling this?"

its controller asks:

"Which model is the right fit for this specific part of the task?"

Those are two distinct optimization problems.

And Then There's Pricing

Pricing is where things get even more interesting.

Sakana has apparently split Fugu into two pricing tiers.

Fugu Max

Input: $2 per million tokens

Output: $6 per million tokens

According to the reported figures, this comes in roughly 40 to 60 percent cheaper than several rival models mentioned in the release.

Fugu Ultra v2

Input: $5 per million tokens

Output: $30 per million tokens

For prompts that go beyond 272,000 tokens of context, the reported rates climb to:

Input: $10 per million tokens

Output: $45 per million tokens.

The Ultra tier is also said to include a 1-million-token context window along with an August 2026 knowledge cutoff.

Price Comparison

The figures above (measured per million tokens) come from the source material; you should verify them against each provider's current published pricing before making any purchasing decisions.

But There's a Catch

This is arguably the most interesting wrinkle in the whole Fugu story.

Orchestration isn't free.

Each time the system has to:

• break a task into pieces
• route those pieces
• call out to another model
• wait for that model's answer
• check the quality of the result
• and stitch everything back together

it adds extra overhead.

That overhead can show up as added latency.

Consider a request like:

"Write me a tweet about coffee."

You almost certainly don't need a coordinating layer juggling several specialist models for something this small.

That would be like calling in an entire consulting firm to tighten a loose faucet.

Now compare that with a much heavier ask, something along the lines of feeding in a lengthy technical document, having the system comb through an associated codebase, flag design flaws, weigh multiple possible fixes against each other, and then produce a concrete plan for implementing the winning approach.

Here, having an orchestration layer starts to pay off significantly.

The Hidden Problem: The Black Box

There's a second issue that may matter even more than speed.

You typically have no visibility into which underlying model actually processed each part of your request.

For everyday consumer use, that's not a big deal.

For enterprise use, it can be a real sticking point.

Think about organizations handling:

• confidential source code
• financial records
• customer information
• proprietary documents
• regulated data

If the routing layer is silently choosing among different models behind the scenes, companies will reasonably want answers to questions like:

Which model actually touched my data? Where was it processed? What exactly got sent to each model? Is the routing decision auditable? Can specific workloads be pinned to approved models only?

These aren't hypothetical concerns.

In enterprise settings, the ability to observe and govern the system can matter just as much as raw model intelligence.

Any orchestration platform that wants to be treated as core infrastructure, rather than just another API wrapper, will eventually need to address these governance gaps.

Why This Could Be Bigger Than One Model Release

Here's the idea that keeps standing out.

Suppose a competitor ships a dramatically better coding model next month.

A conventional model vendor would need to retrain, evaluate, and ship an entirely new release.

An orchestration-based system, by contrast, could simply plug that new model into its existing pool of options.

The controller effectively gains one more specialist to call on.

That's a meaningful advantage.

The resulting structure looks something like this:

AI Model A
                  │
              AI Model B
                  │
User → Controller → AI Model C
                  │
              AI Model D
                  │
              AI Model E

Under this model, the whole system's capability can rise simply because the surrounding ecosystem of models keeps improving.

The controller itself doesn't necessarily have to get dramatically smarter with each iteration.

What it needs is to keep getting better at making decisions.

And that shift in emphasis could turn out to be a significant direction for the future of agentic AI.

The Bigger AI Race May Be Changing

For a long stretch, the pattern behind AI progress was fairly predictable: make the model larger, feed it more training data, push its reasoning further, throw more compute at it, and repeat the cycle. That formula is starting to look incomplete.

Generation 1

A single model handling every task on its own.

Generation 2

A single model paired with external tools.

Generation 3

One agent coordinating multiple tools and multiple models.

Generation 4?

A system that assembles a custom team of models on the fly, tailored to whatever problem it's facing.

This last stage seems to be exactly what Fugu is aiming for.

If that bet pays off, the most valuable AI product going forward might not be the model with the sharpest reasoning scores. It could instead be the system smart enough to recognize when a particular model shouldn't be used at all.

Should You Actually Use Fugu?

Here's a practical breakdown.

For straightforward API-style work

Probably skip it.

If your use case involves things like:

• short summarization
• simple classification tasks
• routine content generation
• quick factual questions

then the extra coordination layer likely isn't worth the added complexity.

For sophisticated agent systems

This is where it gets interesting.

Particularly for work involving:

• software development
• research tasks
• analyzing dense documents
• data-intensive pipelines
• multi-stage reasoning chains
• autonomous agent behavior
• problems that need several distinct kinds of expertise

This is precisely the territory where routing between models starts to pay off.

Closing Thoughts

It would be premature to crown Fugu Ultra as some kind of definitive successor to GPT or Claude. The benchmark figures look strong, but they currently come from the vendor itself, and independent verification is still needed before drawing firm conclusions.

That said, dismissing this as just another entry in the benchmark wars would miss the point. The real story here is architectural, not numerical.

OpenAI, Anthropic, and Google have poured massive resources into pushing individual models to be as capable as possible. Sakana seems to be testing a different hypothesis:

Maybe the goal isn't building one flawless model. Maybe it's building an excellent coordinator for a set of imperfect ones.

That's a small conceptual shift, but not a trivial one. If it proves out, it could reshape how AI applications get built going forward.

The AI system that ends up winning might not be the one boasting the most parameters, the longest context window, or the top score on any single leaderboard. It might simply be the one capable of looking at a task and concluding: this particular model is the right one for this particular job.

That's the part of Fugu Ultra v2.0 worth paying attention to. Not the ranking table.