Sakana Fugu: Orchestrator statt Monolith

Worum es geht

Am 22. Juni 2026 hat Sakana AI das Fugu Technical Report veröffentlicht (arXiv 2606.21228). Fugu ist kein weiteres Foundation-Modell im Rennen um die größte Gewichts-Datei. Es ist ein Orchestrator – ein leichtgewichtiger Selection-Head, der eingehende Prompts auf einen Pool spezialisierter LLMs unterschiedlicher Anbieter verteilt.

Das Timing ist kein Zufall. Zehn Tage vorher, am 12. Juni 2026, hat das US Department of Commerce Export-Kontrollen auf Anthropics Fable 5 und Mythos verhängt. Über Nacht standen Teams ohne API-Zugriff da, ohne Migrationspfad. Fugu ist die strategische Antwort: Wenn jedes einzelne Modell ein Single Point of Failure ist, ist die Lösung kein größeres Modell – sondern weniger Abhängigkeit von jedem einzelnen.

Die These hinter Fugu

Die letzten drei Jahre Frontier-Entwicklung folgten einer Annahme: Ein Modell, das alles kann, ist besser als viele Modelle, die einzelne Dinge können. Mehr Parameter, mehr Daten, mehr RLHF – am Ende rangiert ein einziger Stack auf Platz 1 der Leaderboards.

Sakana stellt diese Annahme leise infrage. Provider spezialisieren sich zunehmend: Anthropic auf Long-Context-Reasoning, OpenAI auf Tool-Use, Z.ai auf günstiges Coding, Moonshot auf Agenten-Loops, Google auf Multimodalität. Wer immer das jeweils beste Modell für eine Teilaufgabe will, braucht keinen größeren Monolithen – sondern einen guten Router.

Das ist Fugu. Ein Modell, dessen einzige Aufgabe es ist, das richtige Modell für den jeweiligen Prompt auszuwählen.

Architektur: Selection Head, nicht Mixture of Experts

Wer „Multi-Model" hört, denkt oft an Mixture of Experts (MoE) im Inneren eines einzelnen Modells. Fugu ist das genaue Gegenteil: Die Experts sind externe Modelle verschiedener Anbieter, und der Router ist ein separates, kleines Modell, das vor dem eigentlichen Inference-Call sitzt.

Prompt
  │
  ▼
┌──────────────┐
│ Fugu Router  │  (kleiner Selection Head)
└──────┬───────┘
       │ wählt Modell
       ▼
┌───────────────────────────────────────────┐
│  Claude  │  GPT  │  GLM-5.2  │  Kimi K2  │
└───────────────────────────────────────────┘
       │
       ▼
   Response

Der Vorteil: Modelle sind swappable. Fällt ein Provider aus (Export-Control, Outage, Preiserhöhung), ändert sich die Route, nicht die Architektur.

Wie der Router lernt

Fugu wird in zwei Stufen trainiert:

1. Supervised Fine-Tuning (SFT) auf gelabelten Prompt → Bestes-Modell-Paaren. Sakana baut sich dafür eine Trainings-Pipeline, die jeden Prompt durch alle Kandidaten-Modelle schickt und das Ergebnis evaluiert.
2. Online Adaptation – der Router updated kontinuierlich, wenn neue Modelle in den Pool kommen oder bestehende sich verändern.

Das ist der eigentliche Trick: Der Router weiß nicht nur, welches Modell gut ist, sondern für welche Art von Prompt welches Modell gut ist. Ein Coding-Prompt geht woanders hin als eine juristische Recherche oder ein Marketing-Text.

Die zwei Varianten

Beide unterstützen bis zu 1M Kontext – wichtig, weil der Router auch bei langen Konversationen die Modell-Wahl pro Turn neu treffen kann.

Benchmarks: matched Fable und Mythos

Laut Sakanas Technical Report erreicht Fugu in Aggregat-Benchmarks Niveaus, die mit Anthropics Fable 5 und Mythos vergleichbar sind – ohne selbst ein Frontier-Modell zu trainieren. Die Leistung kommt aus dem Pool, nicht aus den eigenen Gewichten.

Das ist die wichtige Pointe: Fugu „schlägt" Fable nicht durch besseres Modell-Engineering, sondern durch besseres Modell-Auswahl-Engineering. Ein architektonischer Sieg, kein Skalierungs-Sieg.

Was das strategisch bedeutet

Drei Verschiebungen, die wir bei Kundenprojekten ohnehin schon beobachten und die Fugu nun explizit macht:

1. Single-Vendor-Strategien sind tot. Wer 2026 noch „wir laufen auf OpenAI" als Architektur-Statement formuliert, baut ein Klumpenrisiko. Der Fable-Lockout war kein Sonderfall, sondern Vorbote.
2. Routing wird eine eigene Disziplin. So wie Load Balancing und Caching eigene Kategorien wurden, wird Model Routing zu einer eigenen Schicht im Stack. Fugu ist die erste seriöse Standalone-Implementierung.
3. „Bestes Modell" ist eine Routing-Frage, keine Modell-Frage. Der Wettbewerb verschiebt sich vom Foundation-Model hin zur Orchestrierungs-Schicht darüber. Genau dieselbe Bewegung haben wir in Agent Harness als Kategorie beschrieben.

Wo Fugu in unseren Stack passt

Wir setzen in Kundenprojekten ohnehin selten ein einziges Modell ein. Was wir bisher mit handgebauten Routern und Heuristiken lösen (Claude für Reasoning, GLM für Coding-Bulk, Kimi für Agent-Loops, lokale Modelle für sensible Daten), könnte Fugu als Service abnehmen.

Die offenen Fragen für uns:

• Latency Overhead. Wie viele Millisekunden kostet der Router-Call vor jedem Inference-Call?
• Cost Predictability. Wenn der Router selbst entscheidet, welches teure Modell gerufen wird, wie planen wir Budgets?
• Privacy. Welche Daten sieht Sakana, wenn wir Prompts durch ihren Router schicken?
• On-Prem? Lässt sich Fugu lokal betreiben, oder ist es nur als Cloud-API verfügbar?

Wir testen es in den nächsten Wochen im Kontext unserer AutoClaw-Pipeline und in einem Kundenprojekt, das aktuell zwischen GLM-5.2 und Claude Fable 5 routet. Bericht folgt.

Build vs. Buy

Die naheliegende Frage: Warum nicht selbst bauen? Ein Router ist konzeptionell trivial – einige Regex-Regeln, ein kleiner Classifier, fertig. Wir bauen sowas regelmäßig.

Der Unterschied liegt in zwei Dingen:

1. Trainings-Daten. Sakana hat eine Pipeline gebaut, die kontinuierlich Prompt → Bestes-Modell-Labels generiert. Die saubere Variante davon nachzubauen kostet mehr als die meisten Teams investieren wollen.
2. Adaptivität. Sobald GLM-6 oder Claude Fable 6 erscheint, muss der Router das neue Modell bewerten und einsortieren. Statische Regeln veralten schnell.

Für interne Tools mit drei klar getrennten Use-Cases (Coding, Writing, Reasoning): selbst bauen. Für Produkte mit offenen Prompt-Räumen und dem Anspruch, jederzeit das beste Modell zu nutzen: Fugu oder Vergleichbares einkaufen.

Was als Nächstes kommt

Fugu ist der Anfang einer Kategorie. Wir erwarten in den nächsten sechs Monaten:

• Open-Source-Router auf Hugging Face, die Fugus Ansatz replizieren.
• Cloud-Provider (AWS Bedrock, Azure AI), die eigene Routing-Layer ankündigen.
• Privacy-fokussierte Routers, die auch lokale Modelle in den Pool nehmen – relevant für regulierte Branchen.

Wer heute eine AI-Architektur baut, sollte mindestens die Routing-Schicht als eigenes Modul anlegen, auch wenn sie zunächst nur ein Modell aufruft. Sonst wird der Umbau in 12 Monaten teuer.

Quellen

• Sakana Fugu Technical Report (arXiv)
• The Decoder: Sakana AI's Fugu orchestrates multiple LLMs
• Indian Express: What is Fugu, Sakana's new AI agent-orchestrator?
• Outcome School: Decoding Sakana Fugu Technical Report
• Labellerr: Sakana Fugu – The Model That Outsmarts Claude Fable 5