Skip to content
Intermediate· 15 min read

What the Sakana Fugu Paper Actually Says — Orchestration as a New Scaling Axis

Sakana Fugu is a learned orchestrator that coordinates frontier LLMs (Claude, GPT, Gemini) to beat each one at its own game. A breakdown of the paper, its two variants, and why orchestration may be AI's third scaling axis.

Why This Paper Matters

What if you could call Claude Opus for coding, GPT-5.5 for math, and Gemini for science — all through a single API, with a model smart enough to decide which one to use for each query?

That's the premise of Sakana Fugu, a family of learned orchestrators released by Tokyo-based Sakana AI. Fugu doesn't try to be a better model — it tries to be a better coordinator of existing models. It's a small language model trained to understand your query and dynamically decide which frontier worker to invoke, or how to compose a multi-agent workflow when the task demands it. The technical report, published June 19, 2026, shows Fugu-Ultra surpassing every publicly accessible frontier model — including Claude Opus 4.8, GPT-5.5, and Gemini 3.1 Pro — on benchmarks spanning software engineering, scientific reasoning, competitive programming, and long-horizon agentic tasks.

The paper's central claim is deliberately provocative: orchestration is a third scaling axis, alongside data and compute. What makes this claim concrete is what it unlocks. Today, improving AI capability means training a bigger model — billion-dollar runs, months of engineering, export-controlled weights. Fugu offers a different path: you can get better results by learning to coordinate the models we already have. That was not possible before. You cannot "merge" closed-source APIs. You cannot hand-code routing logic that adapts per query at this granularity. Fugu does both, using a small orchestrator trained on nothing but worker performance data. If this direction holds, it changes who can push the frontier — from organizations that can train 100B-parameter models to any team that can orchestrate them.


What Problem Does It Solve?

Frontier LLMs are becoming increasingly specialized. Claude Opus 4.8 sets the standard for software engineering and cybersecurity. GPT-5.5 dominates mathematical reasoning. Gemini 3.1 Pro leads in scientific knowledge and niche factual recall. No single model is best at everything — and the gaps between them are growing, not shrinking.

If you're building a system that needs coding, math, and scientific reasoning, you must either pick one model and accept its weaknesses, or build multi-model routing logic yourself. Prior approaches to combining models fall into two camps, each with fundamental limitations:

Model merging combines capabilities at the weight level — averaging parameters or stitching layers. This requires access to model weights and assumes architectural compatibility, making it impossible for closed-source APIs. You cannot "merge" GPT-5.5 and Claude Opus.

Hand-designed multi-agent systems coordinate multiple models through fixed patterns — always debate, always vote, always route to the best single model. These patterns work well for the tasks they were designed for but fail to adapt when the task changes.

Sakana Fugu addresses both gaps. Instead of merging weights or fixing interaction patterns, it trains a small orchestrator model to learn how to coordinate its worker pool for each query. The result is a system that adapts its strategy per task — sometimes routing to a single specialist, sometimes composing multi-step workflows — without requiring parameter access or hand-coded rules. What was previously a labor-intensive engineering problem (designing, testing, and maintaining routing logic) becomes a learned capability.


The Core Insight

The central idea is that orchestration is learnable. Rather than hand-designing how models should collaborate, you train an orchestrator model to discover effective coordination strategies from data.

This rests on a straightforward observation: different frontier models have different strengths, and those strengths are consistent enough to learn. If GPT-5.5 is reliably better at math across thousands of test questions, and Claude Opus 4.8 is reliably better at debugging across thousands of coding tasks, then a model can learn to route math questions to GPT and debugging to Opus. The same logic extends to multi-step workflows: if a task requires both math and debugging, the orchestrator can learn to compose a sequence that uses each model where it excels.

Sakana Fugu implements this as two complementary systems:

  • Fugu is a low-latency router that selects a single worker per query. It reads the user's input, computes which model is most likely to produce the correct answer, and dispatches the query directly — without generating any text of its own. In practice this means the response feels as fast as calling a single model, but the model behind the call changes depending on what you ask.

  • Fugu-Ultra is a full multi-agent workflow generator. For complex tasks, it produces a structured plan: subtasks, worker assignments, communication patterns, and a synthesis step. Multiple models collaborate, each contributing their specialty, and the orchestrator verifies and combines their outputs. The latency is higher, but so is the ceiling on what the system can accomplish.

Both variants present a single model interface. The complexity of multi-agent coordination is hidden behind one API call.


How It Actually Works

How Fugu Routes Queries with Near-Zero Overhead

Fugu is designed for speed. Its orchestrator is a pre-trained language model with two small additions attached to its final hidden layer.

A lightweight selection head sits parallel to the normal language-model head. Instead of predicting the next token, this head outputs a set of logits — one score per worker model in the pool. The orchestrator reads the user's input up to an early token position, computes a hidden state, applies the selection head, and picks the worker with the highest score. The query is then dispatched to that worker, and the orchestrator does no further decoding. The key result: the orchestrator generates zero tokens. It only classifies. This is why Fugu's latency is comparable to a direct API call — the routing decision happens in the time it takes to process a few hundred tokens of input.

Singular-value fine-tuning adapts a small subset of the orchestrator's weight matrices. Rather than full fine-tuning, selected matrices are decomposed and only the singular-value scales are trained. Together with the lightweight head, this yields an extremely small trainable parameter set while still allowing the orchestrator's representations to adapt to the routing problem.

Training happens in two stages. First, supervised fine-tuning on a large collection of single-step tasks spanning coding, math, reasoning, and agentic scenarios. For each question, every worker model generates multiple candidate solutions. Each worker's performance is measured against the ground truth, producing a soft target distribution — not a single "best model" label, but a probability distribution over workers reflecting their relative skill on that question. The orchestrator learns to match this distribution.

Second, evolutionary optimization on end-to-end multi-turn tasks. Single-step questions do not capture how models behave inside interactive coding harnesses, where tool use, environment feedback, and multi-turn context matter. The paper collects real-world trajectories from systems like Claude Code and Codex. The orchestrator's parameters are then refined using sep-CMA-ES, an evolutionary strategy that directly maximizes task completion rates. The SFT initialization places the parameters in a good region of the search space, and the evolutionary stage fine-tunes routing behavior at a granular level.

How Fugu-Ultra Generates Multi-Agent Workflows

Fugu-Ultra tackles problems that benefit from combining multiple specialists. It builds on the Conductor framework, which trains a language model with reinforcement learning to output complete agentic workflows as natural language.

A workflow is a sequence of steps, each specifying a natural-language subtask, the ID of the worker agent assigned to it, and an access list indexing which earlier steps' outputs to include in that worker's context. This simple structure can represent anything from a best-of-N ensemble to a sequential chain to a parallel tree — the orchestrator discovers which topology works best for each query.

Training uses GRPO (Group Relative Policy Optimization). The reward function has two conditions: the response must be parseable as a valid workflow, and the final output must match the correct solution. No KL divergence penalty is applied, which lets the model explore freely. Trained on a mixture of public data and expert-designed end-to-end environments, the orchestrator develops the ability to decompose problems into subtasks, assign them to the right specialists, and synthesize their outputs.

Function calling across multiple agents introduces a unique challenge: if any agent can call tools at any time, the system must track which agent made each call and route responses back correctly. Fugu-Ultra solves this with two mechanisms:

  • Intra-workflow agent isolation — each agent sees only its own action history within the current workflow step. This prevents "orchestration collapse," where the first agent's trajectory biases all subsequent agents into following the same path.

  • Inter-workflow shared memory — across different workflow steps, agents can see tool-calling results from previous steps. This prevents redundant work — re-discovering the same file paths, re-querying the same APIs — while preserving independent reasoning within each step.

The result: agents contribute independently within their assigned subtasks but build on collective discoveries across the full workflow.


Key Results

The paper reports results across a broad suite of benchmarks. The headline numbers compare Fugu models against their own worker pool — the very models the orchestrator coordinates.

BenchmarkFuguFugu-UltraOpus 4.8Gemini 3.1 ProGPT 5.5
SWE Bench Pro59.073.7 🥇69.2 🥈54.258.6
Terminal Bench 2.180.2 🥈82.1 🥇74.670.378.2
LiveCodeBench v690.392.0 🥇90.388.990.7 🥈
LiveCodeBench Pro87.890.8 🥇84.882.988.4 🥈
GPQA Diamond95.5 🥇95.5 🥇92.094.3 🥈93.6
Humanity's Last Exam47.250.0 🥇49.8 🥈44.441.4
CharXiv Reasoning85.1 🥈86.6 🥇84.283.384.1
SciCode60.1 🥇58.753.558.9 🥈56.1

Fugu-Ultra achieves the highest raw scores, especially on agentic benchmarks like SWE Bench Pro and Terminal Bench 2.1. But the more interesting result is what the numbers do not capture: Fugu-Ultra recovers from its own mistakes mid-trajectory. On Terminal Bench 2.1, it alternates between GPT-5.5 as a "builder" and Opus as a "debugger" — GPT builds the scaffold, Opus spots the vulnerabilities, GPT rebuilds. No single model produces that collaboration pattern.

Fugu (the lightweight variant) also often beats or ties every individual frontier model — despite selecting only one worker per query. This suggests that even learned single-model routing outperforms any fixed model choice.

The paper also presents qualitative results that stress real agentic behavior:

  • AutoResearch (LLM training optimization): Fugu-Ultra optimized a small GPT training pipeline across 123 autonomous experiments on a single H100 GPU. It achieved the best mean validation bits-per-byte (0.9774 ± 0.0019) against three frontier baselines. The gap grew in the later stages — once the search shifted from coarse configuration changes to finer optimizer and schedule tuning, the multi-model orchestration pulled ahead.

  • Blindfold chess: Fugu played four full games from memory (no board displayed, only coordinate notation) against three frontier models and a 2100-Elo Stockfish. It won all four with no blunders or mistakes. Every opponent committed at least one decisive error. This measures not knowledge but sustained state tracking over dozens of moves — a different kind of capability than benchmark scores reflect.

  • Rubik's cube solver: Fugu and Fugu-Ultra both produced Python solvers that solved all 300 test scrambles. Two of three frontier baselines produced solvers that crashed. Fugu-Ultra produced the shortest solutions (mean 19.72 half-turn metric, within one move of optimal). Fugu traded one extra move for a solver that runs 35x faster (1.9s per cube vs 70s).

  • Classical Japanese letter reading order: On 25 expert-annotated pages of chirashigaki (scattered writing) — a task with no public benchmark and no training data — Fugu-Ultra achieved a mean normalized edit distance of 0.776 against expert annotation. The best frontier baseline scored 0.642. This is the kind of task where a model cannot memorize the answer; it must reason about spatial layout from scratch.


Limitations & Open Questions

Sakana Fugu's capabilities are uneven — some tasks are "on the rails" (well-served by the orchestrator's training data and the worker pool's strengths) while others require "off-roading" where the system's limitations become visible.

On the rails

Coding benchmarks (SWE Bench, Terminal Bench, LiveCodeBench) show consistent gains from orchestration. The worker pool has strong software engineering models, the evaluation harness is well-understood, and the orchestrator's training data covers these scenarios densely.

Off-roading

Three areas where the current approach strains. First, if all workers fail equally on a task — a novel reasoning problem no model was trained on — orchestration cannot invent new capability. The system selects and combines; it does not create. Second, the benchmark numbers are self-reported against provider-reported baselines. Independent verification has not been published, and the broader community has expressed skepticism about reproducibility. Third, the export-control narrative that Fugu promotes is real but incomplete. The worker pool consists of US-based frontier APIs. The system adds resilience (failover between providers) but not true sovereignty.

The cost trade-off

Early users report that Fugu-Ultra's multi-step workflows can be 5-10x more expensive than a single model call, and on many tasks the quality gain over a well-chosen single model is modest. The orchestrator itself is small and fast, but the worker calls it orchestrates are not. For tasks that are already "on the rails" for a single frontier model, orchestration overhead may not be worth the cost.


Why It Matters Now

The Sakana Fugu report arrives at a specific moment. Days before its release, the US government ordered Anthropic to suspend access to its most capable models (Fable 5 and Mythos Preview) under export control restrictions. Sakana AI explicitly positions Fugu as a hedge against single-vendor dependency: "Frontier capability without the risk of export controls."

What matters longer-term is not whether Fugu itself becomes the standard — the product is real but early, and user experiences are mixed — but what it unlocks as a category. Learned orchestration turns model coordination from an engineering problem into a learned capability. You no longer need to hand-design routing rules or multi-agent topologies. You train a small model to discover them. This means new frontier models can be added to the pool as they appear, without re-engineering the coordination logic. It means organizations can configure the worker pool to meet compliance, privacy, or geographic constraints without retraining.

This paper connects directly to concepts covered on this blog. The Agent Loops article discussed loop engineering — designing autonomous AI workflows. Fugu extends loop engineering to multi-agent systems: instead of one agent in a loop, many agents coordinated by a learned manager. And Function Calling is the mechanism that makes agent-tool interaction possible — Fugu-Ultra's isolation and shared memory patterns are direct extensions of that paradigm.

The paper is written by a team with credible roots (founded by Llion Jones, co-author of "Attention Is All You Need"), and the two underlying frameworks — Trinity and Conductor — were accepted at ICLR 2026.


Key Takeaways

  • Sakana Fugu is a learned orchestrator, not a new foundation model. It coordinates existing frontier LLMs (Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro) to produce better results than any single one.
  • Two variants serve different trade-offs: Fugu (single-worker routing, low latency) and Fugu-Ultra (multi-agent workflows, maximum quality).
  • Fugu uses a lightweight selection head on hidden states to choose a worker without generating any tokens — keeping latency near that of a direct API call.
  • Fugu-Ultra generates agentic workflows as natural language, trained with reinforcement learning (GRPO), and handles cross-agent function calling with intra-workflow isolation and inter-workflow shared memory.
  • The paper reports Fugu-Ultra surpassing every publicly accessible frontier model across coding, reasoning, and scientific benchmarks — beating Opus 4.8 on SWE Bench Pro (73.7% vs 69.2%) and matching Gemini 3.1 Pro on GPQA Diamond (95.5%).
  • Capabilities are jagged: coding and reasoning are "on the rails" for orchestration, while novel tasks where all workers fail remain unsolved. Independent reproducibility of benchmark claims is still pending.
  • Whether or not Fugu itself becomes a product standard, learned orchestration as a scaling axis — coordinating models rather than training bigger ones — is likely to influence how AI systems are built going forward.

References

Related

Why Open-Source LLMs Matter

· 16 min read#ai#open-source#llm

A first-principles breakdown of why open-source language models are reshaping AI — from cost and transparency to sovereignty, competition, and the now-closed performance gap.