Der nächste Fortschritt bei KI muss nicht zwingend aus einem noch größeren Sprachmodell kommen. Sakana AI hat Fugu Ultra auf Version 1.1 aktualisiert. Hinter dem Namen steckt kein einzelnes neues Basismodell, sondern ein Router: Er zerlegt schwierige Aufgaben, verteilt sie auf mehrere spezialisierte Systeme und setzt das Ergebnis wieder zusammen. Für Entwicklerinnen und Entwickler ist das interessant, weil sich die Auswahl eines Modells damit teilweise vom Arbeitsplatz in die Infrastruktur verschiebt.
Fugu Ultra 1.1 lässt sich laut Sakana über eine OpenAI-kompatible Schnittstelle ansprechen und kann auch in Codex- oder Claude-Code-Umgebungen eingebunden werden. Der Dienst verspricht, für schwere Aufgaben tiefer zu planen und zu prüfen. Das klingt nach einer bequemen Abkürzung im Modell-Dschungel. Es ist aber auch ein Tauschgeschäft: Wer einen Router nutzt, gibt einen Teil der Kontrolle darüber ab, welches Modell welche Daten und welche Teilaufgabe sieht.
Das Wichtigste in Kürze
- Fugu Ultra 1.1 ist ein Orchestrierungssystem, kein klassisches einzelnes Sprachmodell.
- Es bündelt mehrere KI-Agenten hinter einer API und priorisiert Qualität bei komplexen Aufgaben vor kurzer Antwortzeit.
- Die neue Version ist als Standard hinter dem Alias fugu-ultra dokumentiert und ergänzt eine zusätzliche maximale Reasoning-Stufe.
- Die von Sakana veröffentlichten Benchmarks sind ein Signal, aber keine unabhängige Kaufempfehlung.
- Für sensible Anwendungen bleiben Transparenz über Datenflüsse, Latenz und Kosten wichtiger als ein hoher Benchmarkwert.
Ein Dirigent statt eines Solisten
Bei einem gewöhnlichen KI-Modell entscheidet ein System selbst über die Antwort. Fugu arbeitet anders. Der technische Bericht von Sakana beschreibt einen Koordinator, der eine Anfrage analysiert und daraus eine passende Arbeitsfolge baut. Je nach Problem kann er andere Agenten zum Planen, Ausführen oder Prüfen einsetzen. Fugu Ultra nutzt dabei mehr Orchestrierung als die schnellere Variante Fugu und akzeptiert ausdrücklich zusätzliche Wartezeit zugunsten der Antwortqualität.
Das Prinzip ist nicht neu: Teams kombinieren seit Langem verschiedene Modelle für Recherche, Code oder Zusammenfassungen. Neu ist der Produktanspruch, diese Entscheidung selbst als Modellleistung zu verkaufen. Die API soll sich für den Aufrufer wie ein einziger Endpunkt anfühlen. Für komplizierte Programmieraufgaben kann das sinnvoll sein, denn ein Agent kann Entwürfe erzeugen, ein zweiter sie prüfen und ein dritter Lücken suchen. Gerade dort, wo Arbeitsoberflächen wie Codex immer mehr Werkzeuge zusammenführen, wird diese unsichtbare Arbeitsteilung zum Produktmerkmal.
Was Version 1.1 praktisch verändert
Sakanas aktuelle Dokumentation führt fugu-ultra-v1.1 als Version hinter dem allgemeinen Modellnamen fugu-ultra. Neu beziehungsweise ausdrücklich hervorgehoben sind drei wählbare Denkintensitäten: high, xhigh und max. Die höchste Stufe ist für besonders schwere Aufgaben gedacht. Das ist keine Garantie für bessere Ergebnisse bei jeder Frage. Es bedeutet vor allem, dass der Dienst mehr Rechen- und Orchestrierungsaufwand zulassen kann.
Die Schnittstelle bleibt zu gängigen OpenAI-Formaten kompatibel; zusätzlich dokumentiert Sakana eine Anbindung an Codex und Claude Code. Das senkt die Umstellungskosten: Ein Team muss nicht sofort seine gesamte Toolkette neu schreiben. Genau hier liegt die Stärke eines Routers. Wer heute ein Modell für Planung und ein anderes für Code nutzt, kann die Auswahl zentralisieren. Der Haken: Längere Agentenketten erhöhen die Latenz. Vercel weist für Fugu Ultra deshalb ausdrücklich darauf hin, dass Koordination und Prüfungen langsamer sein können als ein einzelner Modellaufruf.
Benchmark-Spitzen sind noch kein Freifahrtschein
Sakana veröffentlicht für Fugu Ultra hohe Werte bei Programmier- und Reasoning-Tests, etwa 73,7 Prozent bei SWE-Bench Pro und 82,1 Prozent bei TerminalBench 2.1. Diese Zahlen erklären, warum Orchestrierung Aufmerksamkeit bekommt. Sie sind jedoch Herstellerangaben in einer Vergleichstabelle, keine neutrale Feldstudie. Der zugehörige technische Bericht legt die Methode offen, vergleicht aber teils mit von anderen Anbietern gemeldeten Werten. Für eine Beschaffungsentscheidung sollten Teams daher eigene, repräsentative Aufgaben testen: den eigenen Codebestand, reale Dokumente, typische Fehlermeldungen und klare Erfolgskriterien.
Das gilt besonders, weil sich die Rolle eines Routers von der eines einzelnen Modells unterscheidet. Bei einem festen Modell lassen sich Version, Region und oft auch Datenbedingungen präziser festlegen. Bei Fugu Ultra legt Sakana die konkrete Auswahl pro Anfrage nicht offen. Vercel nennt das direkt als Grenze für Anwendungsfälle, in denen nachvollziehbar sein muss, welches Modell eine Aufgabe bearbeitet hat. Für personenbezogene Daten, regulierte Branchen oder vertraulichen Quellcode ist das keine Fußnote, sondern eine Architekturfrage.
Der richtige Test ist kleiner als der Hype
Fugu Ultra 1.1 ist deshalb weniger eine Aufforderung, ein Lieblingsmodell zu ersetzen, als ein Zeichen für einen Richtungswechsel. Die spannendere Frage lautet zunehmend nicht nur: Welches Modell ist am stärksten? Sondern auch: Wer entscheidet, wann welches Modell eingesetzt wird, und kann diese Entscheidung überprüft werden? Dass der jüngste Vergleich von Claude-Modellen vor allem Preise und Einzelwerte behandelt, zeigt den Kontrast: Router verlagern Wettbewerb auf Auswahl, Kontrolle und Betrieb.
Ein vernünftiger Einstieg wäre ein begrenzter Pilot ohne sensible Daten. Teams sollten Antwortqualität, Laufzeit, Gesamtkosten und Fehlerraten gegen ihren bisherigen Ablauf messen. Außerdem brauchen sie Klarheit darüber, welche Unteranbieter in Frage kommen und ob sich die Nutzung protokollieren lässt. Wenn diese Fragen gut beantwortet sind, kann ein KI-Router Arbeit sparen. Wenn nicht, wird aus dem bequemen einen Endpunkt nur eine weitere Black Box mit guter PR.