
TL;DR: „Sakana AI's Fugu is a lightweight selection head that routes prompts across a pool of specialised LLMs. Two variants (Fugu, Fugu-Ultra), 1M context, from $5/1M tokens. In benchmarks the constellation matches Anthropic's Fable/Mythos – without depending on any single provider. A strategic response to the Fable 5 export lockout of June 12, 2026."
— Till FreitagWhat this is about
On June 22, 2026, Sakana AI released the Fugu Technical Report (arXiv 2606.21228). Fugu is not another foundation model in the race for bigger weights. It is an orchestrator – a lightweight selection head that routes incoming prompts across a pool of specialised LLMs from different providers.
The timing is no accident. Ten days earlier, on June 12, 2026, the US Department of Commerce placed export controls on Anthropic's Fable 5 and Mythos. Overnight, teams lost API access with no migration path. Fugu is the strategic answer: if every single model is a single point of failure, the fix isn't a bigger model – it's less dependence on any one of them.
The thesis behind Fugu
Three years of frontier development have followed one assumption: a model that can do everything beats many models that each do one thing. More parameters, more data, more RLHF – one stack ends up at the top of the leaderboard.
Sakana quietly questions that assumption. Providers increasingly specialise: Anthropic on long-context reasoning, OpenAI on tool use, Z.ai on cheap coding, Moonshot on agent loops, Google on multimodality. If you want the best model for each sub-task, you don't need a bigger monolith – you need a good router.
That's Fugu. A model whose only job is to pick the right model for the prompt at hand.
Architecture: selection head, not mixture of experts
When people hear "multi-model," they often think of Mixture of Experts (MoE) inside a single model. Fugu is the exact opposite: the experts are external models from different providers, and the router is a separate, small model that sits in front of the actual inference call.
Prompt
│
▼
┌──────────────┐
│ Fugu Router │ (small selection head)
└──────┬───────┘
│ picks model
▼
┌───────────────────────────────────────────┐
│ Claude │ GPT │ GLM-5.2 │ Kimi K2 │
└───────────────────────────────────────────┘
│
▼
ResponseThe benefit: models are swappable. When a provider drops out (export control, outage, price hike), the route changes, not the architecture.
How the router learns
Fugu is trained in two stages:
- Supervised Fine-Tuning (SFT) on labelled prompt → best-model pairs. Sakana built a pipeline that runs every prompt through all candidate models and evaluates the outcomes.
- Online adaptation – the router updates continuously as new models enter the pool or existing ones change.
That's the real trick: the router doesn't just know which model is good, but which model is good for which kind of prompt. A coding prompt goes somewhere different from a legal research query or a marketing copy task.
The two variants
| Variant | Audience | Input price |
|---|---|---|
| Fugu | Standard, low overhead | $5 / 1M tokens |
| Fugu-Ultra | Higher routing quality, more candidate models | higher |
Both support up to 1M context – important, because the router can re-pick the model per turn even in long conversations.
Benchmarks: matches Fable and Mythos
Per Sakana's technical report, Fugu reaches aggregate benchmark levels comparable to Anthropic's Fable 5 and Mythos – without training a frontier model itself. The performance comes from the pool, not from its own weights.
That's the important point: Fugu doesn't "beat" Fable through better model engineering, but through better model-selection engineering. An architectural win, not a scaling win.
What this means strategically
Three shifts we've been seeing in client work that Fugu now makes explicit:
- Single-vendor strategies are dead. Saying "we run on OpenAI" as an architecture statement in 2026 builds concentration risk. The Fable lockout wasn't an exception – it was a preview.
- Routing becomes its own discipline. Just as load balancing and caching became their own categories, model routing becomes its own layer in the stack. Fugu is the first serious standalone implementation.
- "Best model" is a routing question, not a model question. Competition shifts from the foundation model up to the orchestration layer above it. The same move we described in Agent Harness as a Category.
Where Fugu fits in our stack
We rarely deploy a single model in client projects anyway. What we currently solve with hand-built routers and heuristics (Claude for reasoning, GLM for coding bulk, Kimi for agent loops, local models for sensitive data) Fugu could take over as a service.
Open questions for us:
- Latency overhead. How many milliseconds does the router call cost in front of every inference call?
- Cost predictability. If the router itself decides which expensive model to call, how do we plan budgets?
- Privacy. What does Sakana see when we route prompts through them?
- On-prem? Can Fugu run locally, or is it cloud-API only?
We'll test it over the next weeks inside our AutoClaw pipeline and in a client project currently routing between GLM-5.2 and Claude Fable 5. Report to follow.
Build vs. buy
The obvious question: why not build it yourself? A router is conceptually trivial – a few regex rules, a small classifier, done. We build these regularly.
The difference comes down to two things:
- Training data. Sakana built a pipeline that continuously generates prompt → best-model labels. Replicating the clean version of that costs more than most teams want to invest.
- Adaptivity. The moment GLM-6 or Claude Fable 6 lands, the router has to evaluate and slot in the new model. Static rules age fast.
For internal tools with three cleanly separated use cases (coding, writing, reasoning): build it yourself. For products with open prompt spaces that need to use the best model at any time: buy Fugu or something equivalent.
What comes next
Fugu is the start of a category. We expect over the next six months:
- Open-source routers on Hugging Face that replicate Fugu's approach.
- Cloud providers (AWS Bedrock, Azure AI) announcing their own routing layers.
- Privacy-first routers that include local models in the pool – relevant for regulated industries.
If you're building an AI architecture today, at minimum design the routing layer as its own module, even if it currently calls just one model. Otherwise the rewrite in 12 months gets expensive.








