Sakana Fugu, a team of LLMs working as one

Sakana AI just released Fugu, an orchestrator rather than a bigger AI model. It sits in front of multiple frontier models and decides when one model is enough and when a team of models should work together. Let's break down how it works, how it learned to coordinate models, where the idea came from, and why its benchmark results need a closer look.

Most frontier releases this year were about scale, a bigger model, a longer context, a higher score. Sakana Fugu, released June 22, 2026, takes a different swing. It is a model whose whole job is to command other models, a learned conductor that hides a team of frontier LLMs behind a single API and decides, per request, who should play. This is what Fugu actually is, how the orchestration is trained rather than hardcoded, and how seriously to take the benchmark claims.

The headline & the story behind it

Most frontier model news in 2026 has felt repetitive. Bigger models, longer context windows, and new benchmark highs. On June 22, 2026, Sakana AI released something different. It is called Fugu, named after the pufferfish, and instead of being just another model, it is positioned as something that coordinates other models. Sakana describes it as "One Model to Command Them All."

The key idea is in the word command. Fugu is not trying to be a bigger brain than models like GPT-5.5 or Claude Opus 4.8. Its role is to direct them. You send a request to a single endpoint. Fugu reads it, decides if it can handle it alone or needs help, and if needed it brings in a set of frontier models, coordinates them, and returns a single answer. To the user it looks like one model, but inside it works like a small committee.

Fugu reframes the question. The old one was how to build a bigger model. Fugu asks how to combine the strong models we already have into something more capable than any one of them. Its answer is a model whose only skill is orchestration.

A model and a system at the same time

It is easy to say Fugu is not really a model but a system. That is only partly true. Fugu is a trained language model, but it is trained for a very specific role. Its job is to read a user query and build an Agentic Scaffold around it, then execute it end to end. Sakana describes it as an orchestrator model that harnesses and amplifies the capabilities of an LLM agent team. Those agents include full frontier models, and Fugu can also call copies of itself.

The pool is swappable. Public reporting lists models like GPT-5.5, Claude Opus 4.8, and Gemini 3.1 Pro as the kind of workers Fugu coordinates, and Sakana says you can opt specific providers or models in or out. Crucially, one of the workers Fugu can call is Fugu itself. That recursive self-call means a hard subtask can be handed to a fresh orchestrator instance, which can spin up its own little team, and so on. Orchestration depth becomes a compute knob you turn at inference time, with no retraining required.

The phrase "it is not a model" is a useful slogan but technically imprecise. Fugu is a model. It is just a model that mostly issues instructions to other models instead of answering from its own weights.

How Fugu learns to coordinate

The obvious objection is that we already have model routers. Many systems already inspect a prompt and decide things like send this to a cheap model or send this to a coding model, and call that orchestration. If Fugu were just a more advanced version of that, it would not be very interesting.

The difference Sakana emphasises is that Fugu does not run on hand-written rules about which model handles what. It is trained to learn the coordination itself. When delegating is worth the latency, how the agents should communicate, how many steps a problem deserves, and how to combine and check the pieces into one reliable answer. A rule-based router picks a destination. Fugu designs a workflow.

That role decomposition, a planner, an executor, and a checker working in a loop, comes straight from Sakana's research. The thing to hold onto is that Fugu learned the policy for when and how to spin up structures like this, rather than having an engineer write them down.

Two tiers, Fugu and Fugu-Ultra

Sakana ships two models, and the split tells you a lot about how the orchestration works under the hood. The fast one keeps the coordination shallow. The heavy one lets it go deep.

The mechanics are simple but interesting. In base Fugu, a small prediction head runs alongside the normal next-token head and outputs a score for each worker model in the pool. That makes selecting the model a single fast decision. Only a small part of the backbone is adapted using singular-value fine-tuning. Training starts with supervised learning and then moves to an evolution strategy, sep-CMA-ES, on full end-to-end tasks. Fugu-Ultra goes further by removing the single-step shortcut and using reinforcement learning (GRPO) to build and execute multi-step workflows of up to five steps, where most of the reasoning and verification happens.

Notice the pattern. The fast tier is tuned with an evolution strategy, the deep tier with reinforcement learning. That is not a coincidence, it mirrors the two research papers Fugu is built on.

The research it comes from, TRINITY and Conductor

Fugu did not appear from nowhere. Sakana says directly that the models are based on two of its ICLR 2026 papers, with the methods substantially improved for the product. Knowing the two papers is the cleanest way to understand the two tiers.

• TRINITY, an evolved coordinator: A small coordinator model (on the order of 0.6B parameters) optimised with evolutionary search (CMA-ES). It assigns three roles over multiple turns, a Thinker that sets strategy, a Worker that executes, and a Verifier that judges whether the task is actually done. This is the lineage behind the fast, evolution-tuned Fugu tier.
• Conductor, a reinforcement-learned coordinator: A model trained with reinforcement learning to discover coordination strategies expressed in natural language, learning how to direct a team rather than being told how. This is the lineage behind the RL-trained Fugu-Ultra tier.

There is a bigger idea behind this. Sakana AI has been saying for a while that the next gains come from getting many specialised models to work together, using evolution-like methods to combine them. Earlier they worked on evolutionary model merging, where different fine-tuned models are blended into a single model at the weight level. Fugu moves that idea one step higher. Instead of merging models into one, it trains a controller that combines their outputs at runtime. In that sense, Fugu is less a surprise than a continuation of a direction Sakana has been exploring for a while.

The two problems Fugu is trying to solve

Problem one. No single model is best at everything

Anyone who has shipped with these models knows they have personalities. One is stronger at long-horizon coding, another at careful reasoning, another at tool-heavy multimodal work. The usual response is to pick a favourite and live with its weak spots, or to wire up brittle routing logic by hand. Fugu's pitch is that a learned orchestrator can pull the right specialist for each subtask and, by combining them, reach results that no single model in the pool would reach alone. Sakana frames the goal as accessing "performance beyond any individual LLM agent."

Problem two. Putting all your weight on one vendor

The second problem is strategic rather than technical. If your product is built on one provider's model and that provider raises prices, has an outage, or restricts access, you are stuck. Sakana points to recent export controls affecting Anthropic's top models as a concrete example of how fast access can change. Fugu sits in front of a swappable pool and speaks an OpenAI-compatible API. The argument is that you can route around a disrupted provider, drop a model you no longer want, and never rewrite your integration. Whether that hedge holds up in practice is its own question, but it is clearly part of the pitch.

These two problems point in the same direction. Treat frontier models as interchangeable specialised components behind a stable interface, not the core of the system.

The benchmark claims

Sakana reports that Fugu, and especially Fugu-Ultra, reaches state-of-the-art results across a serious set of benchmarks. SWE-Bench Pro and Terminal Bench for agentic coding, LiveCodeBench for code generation, GPQA-Diamond for graduate-level science, Humanity's Last Exam for hard reasoning, and CharXiv Reasoning for chart understanding. That is an impressive spread, and a team beating any individual model is exactly the kind of result orchestration should produce if it works.

The numbers need careful interpretation. After checking the claims, only one comparison is consistent enough to trust, the one against Claude Opus 4.8.

Those two results are the only solid ones. Other comparisons that were shared against Gemini 3.1 Pro, GPT-5.5, and Anthropic's Fable 5 are inconsistent across sources and not verifiable, so they cannot be treated as reliable. The result is simple. Fugu-Ultra shows a small edge over Opus 4.8 on those benchmarks. It does not mean it beats all frontier models.

Three things matter here. The numbers are from Sakana and not independently verified. The baselines were tested in different setups than Fugu. And Anthropic's top models like Fable 5 and Mythos are not included in the comparison. Any one of these is enough to treat the "frontier parity" claim with caution.

The sceptic's read

A new release should be judged fairly, but also questioned. On the positive side, the architecture is interesting, the research background is solid and peer-reviewed, and the design of swapping and combining models is a clean way to make orchestration tunable. On the unclear side, the limitations are what you would expect from something that is only a few days old at the time of writing.

• Reproduction is pending: No third-party lab has yet rerun the benchmarks under a uniform harness. Until that happens, State Of The Art (SOTA) is a claim, not a result.
• The comparison pool is favourable: Leaving out Anthropic's top-tier models, which at least one source says would top some of the same benchmarks, shapes how the table reads.
• Real-world latency and quality: Within a day of launch, early testers reported long waits on hard tasks and output that was fine but did not clearly beat calling a single strong model directly. Coordinating a team costs time and tokens, and that cost is not free.
• Proprietary internals: The exact routing policy and the full agent pool are closed, so the orchestration cannot be independently audited.

None of this makes Fugu a bad idea. It just means it is early. The right way to look at it is with interest and caution. It is a strong concept, but the real costs, latency, and quality tradeoffs still need to be tested outside Sakana.

What Fugu shows, even if the numbers are not stable

Step back from the leaderboard and Fugu is a signal of where applied AI is going. Earlier the default idea was pick one best model and prompt it well. That is shifting toward systems with agents, tools, retrieval, verification, and multi-model orchestration. Fugu packages that systems approach into something you call like a single model.

This is the next step after prompt engineering to loop engineering. First people tuned prompts, then context, then the loop around a single agent. Fugu pushes it further. The unit is a set of models controlled by a learned policy, not one model with a loop. Even if Fugu itself is not the winner, the direction is clear. Treat models as interchangeable specialists and use a controller to orchestrate them.

The key idea is not the benchmarks but the design shift. Instead of forcing one model to do everything, train a model whose job is to coordinate other models to work together.

If you want to build orchestration like this

The pieces behind Fugu are patterns you can learn and build. The Agentic AI and Multi-Agent Systems track covers orchestrator-worker setups, delegation, and how agents verify each other, which is the heart of what Fugu automates. The LLM track covers the routing, evaluation, and synthesis logic that any orchestrator needs. And if you want to weigh the cost side honestly, the reliability and observability work in the MLOps track is exactly what tells you whether coordinating a team is worth the latency it adds.

Primary sources for this post. Sakana's release notes at sakana.ai/fugu-release and sakana.ai/fugu, the technical report on arXiv (2606.21228), and the two underlying papers, TRINITY (2512.04695) and Conductor (2512.04388).