Japan’s New AI Just Challenged Claude Mythos — But There’s a Catch

Inside Sakana Fugu, the Japanese multi-model system that coordinates GPT, Claude, Gemini, and other AI workers — and why more intelligence does not always produce a better result.

A developer gives an AI one prompt. Behind the scenes, that prompt may be divided among three or four models. One writes the code. Another checks it. A third investigates a narrow technical problem. Finally, a separate system combines everything into one answer.

From the developer’s side, it still looks like a single API call.

That is the idea behind Sakana Fugu, a new AI system from Tokyo-based Sakana AI. Its reported benchmark results place it alongside — and sometimes ahead of — several frontier models.

Image: Sakan fugu vs other models (Image from Sakana Fugu Website)

But benchmarks only tell part of the story.

In hands-on coding tests, Fugu built functional games, interactive interfaces, and visual experiences. It also ignored explicit requirements, entered expensive verification loops, and occasionally delivered weaker results than a standalone model.

So, what exactly did Japan build?

Fugu Isn’t Another Giant LLM

At first, I assumed Fugu was a new foundation model competing directly with GPT, Gemini, and Claude. It isn’t.

Fugu is better understood as an orchestrator.

You send it a prompt through an OpenAI-compatible API. It then decides whether to answer directly, select one model, or construct a workflow involving multiple AI workers.

Architecture Diagram: Developer → Fugu → Selected AI Workers → Verification → Final Response

This distinction matters. Sakana does not need to train one enormous model capable of doing everything. It trains a smaller system to decide which existing model should handle each part of a problem.

Its reported worker pool includes models from OpenAI, Anthropic, Google, and open-source providers. Claude Mythos and Fable are reportedly not part of that pool because they are not publicly accessible.

Fugu is therefore challenging those models through orchestration — not secretly using them.

Fugu and Fugu Ultra Work Differently

Sakana offers two versions with different approaches.

Base Fugu’s router is reportedly decision-only. It reads an early internal representation of the request, scores the available models, and sends the task to the highest-scoring worker.

Fugu Ultra goes much further.

Its Conductor writes a workflow containing the task steps, assigned workers, and an “access list” defining which previous outputs each worker can see. This isolation prevents the first answer from automatically influencing every other agent.

**Flowchart: Prompt → Create Workflow → Assign Workers → Share Approved Context → Check Results → Respond**

Persistent memory also allows later steps to reuse earlier tool calls. In theory, this reduces repeated searches and calculations during long sessions.

Here’s a simplified representation:

const workflow = [
 {
 task: "Build the application",
 worker: "coding-model",
 canAccess: [],
 },
 {
 task: "Review security risks",
 worker: "security-model",
 canAccess: [0],
 },
 {
 task: "Fix verified problems",
 worker: "coding-model",
 canAccess: [0, 1],
 },
];

Each worker receives only the context it needs. That can reduce bias and unnecessary token usage.

The common implementation mistake is giving every agent the full conversation. It feels safer, but it increases cost and allows one incorrect assumption to spread through the entire workflow.

Then the Hands-On Tests Exposed the Catch

You can also watch these tests on Bijan Bowen youtube channel.

On paper, deeper orchestration should improve difficult tasks. In practice, the results were inconsistent.

The regular Fugu model reportedly created a browser-style operating system in approximately six minutes. It included applications, playable experiences, saved state, and a working restoration feature. The recorded cost was around five cents.

Fugu Ultra then produced:

A subway environment converted into a first-person game
A self-contained C++ skateboarding game
A visual reconstruction of a retro laptop
A premium watch website
A flight-combat simulator

Most outputs worked. The layouts were clean, controls existed, and several interactions showed careful implementation.

But an important pattern appeared.

When asked to reproduce a laptop in 3D, Fugu initially created something closer to a layered 2.5D scene. After correction, it produced a real 3D version — but with an inverted keyboard.

The watch website repeated the same failure. The watch looked polished and animated, yet it was not the requested true 3D model.

That is not a cosmetic issue. It is requirement failure disguised by a visually convincing result.

3D laptop Designed by Fugu — Image from Bijan Bowen

A Standalone Model Sometimes Did Better

The watch prompt was also given independently to GPT, Claude, and Gemini.

In that comparison, the standalone GPT result reportedly produced the strongest implementation, including detailed watch straps, stitching, product variations, and more convincing 3D construction. Claude produced attractive product sections but introduced visual problems in the hero. Gemini generated two alternatives with mixed results.

Fugu Ultra combined characteristics associated with several models, yet it did not outperform the strongest individual response.

This is the counterintuitive part:

An orchestrator can inherit several models’ competence without preserving any one model’s strongest interpretation.

More agents can introduce more review, but also more compromises. Sakana reportedly refers to this failure mode as over-orchestration.

Even its benchmark results suggest that the more expensive Ultra version does not win every comparison against base Fugu.

Fugu vs OpenRouter Fusion

Fugu is often compared with OpenRouter Fusion, but the systems organize work differently.

Fusion resembles a panel. Fugu resembles a project lead assigning specialized tasks.

Fugu also uses a blended billing model instead of charging separately for every internal worker. That can make complex workflows cheaper, although actual value still depends on how much orchestration a task needs.

Reflection: More AI Wasn’t the Real Upgrade

What changed for me was the way I evaluate multi-agent systems.

I used to think orchestration was automatically more advanced than selecting one capable model. Now I see it as an architectural expense that must justify itself.
For research, security analysis, scientific reproduction, and workflows requiring independent verification, Fugu’s approach is genuinely interesting.
For a focused frontend build or a clearly specified coding task, one strong model may be faster, cheaper, and easier to debug.

The surprising lesson is simple: coordination is a capability, but it is also another place where quality can be lost.

The Practical Takeaway

Sakana Fugu represents a meaningful shift from “Which model is best?” to “Which combination of models should solve this task?”

Its architecture is thoughtful. The early results are promising. Still, many performance claims are vendor-reported, independent testing remains limited, and hands-on results do not consistently show superiority over frontier models used directly.

Before choosing it, test your actual workload.

If the task requires multiple specialties, independent checks, and long-term memory, orchestration may justify the extra complexity. If one model already follows the requirements well, adding more agents could leave you paying for a sophisticated way to reach a weaker answer.

From Tech By Neha Gupta

👏 Enjoyed the article? Don’t forget to leave a clap.
💬 Have thoughts or questions? Share them in the comments.

Before you go

Please take a moment to like the post and follow the writer!
Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here