O czym jest ten film
- Japońska firma Sakana AI wypuściła Fugu i Fugu Ultra — system wielu agentów sprzedawany jako jeden model, z deklaracją dorównania Fable i Mythos oraz braku ryzyka związanego z kontrolą eksportu.
- Pod spodem nie ma nowego LLM: niewielki model-menedżer rozbija zadanie i deleguje je do modeli Claude, GPT i Gemini przez jedno API.
- Autor uruchomił Fugu Ultra w Claude Code i jednym promptem „/goal” zbudował w niecałą godzinę dashboard analityczny swojego kanału YouTube — z danymi na żywo i analizą robioną przez AI.
- Sam wzorzec nie jest nowy: Claude Code robi podobnie ze swoimi podagentami, tyle że w obrębie jednej rodziny modeli.
- Orkiestracja różni się od Fusion API OpenRouter — to drugie wysyła ten sam prompt do trzech modeli naraz i scala odpowiedzi za pomocą „sędziego”, bez dekompozycji zadania.
- Test porównawczy: 38 zadań w czterech falach (zagadki, pułapki, specyfikacje, ciężkie algorytmy), przygotowanych i ocenianych przez Codexa, na identycznych promptach.
- Wynik: 36 remisów i dwa zwycięstwa Opusa; Fugu był 4,5 raza wolniejszy (357 vs 80 minut) i pięć razy droższy (50 vs 10 dolarów).
- Subskrypcja Fugu wyczerpuje limity szybciej niż Claude Code: na planie za 100 dolarów trzy pełne okna pięciogodzinne zjadłyby cały tygodniowy limit.
- Werdykt autora: do pracy z wiedzą Fugu Ultra nie jest zauważalnie lepszy od Opusa 4.8 — zostaje przy subskrypcjach Codex i Claude Code.
- Największy potencjał widzi dla zespołów programistycznych pracujących na wspólnej bazie kodu oraz w samej umiejętności doboru najtańszego wystarczającego modelu do zadania.
10 najważniejszych takeaways — z kontekstem zastosowania
1.„Dorównuje Fable” nie znaczy „nowy, lepszy model”
Na czym polega: Fugu Ultra to nie samodzielny LLM, lecz warstwa orkiestracji: mały model-menedżer dzieli zadanie i zleca jego części Opusowi, GPT i Gemini. Dobre wyniki w benchmarkach biorą się z koordynacji kilku modeli, a nie z nowej architektury.
Jak stosować: Gdy kolejna firma obwieszcza „model klasy frontier”, sprawdź, czy pod spodem nie siedzi składanka istniejących modeli — to całkowicie zmienia interpretację benchmarków, ceny i oczekiwań co do jakości.
Na co uważać: Porównywanie orkiestratora z pojedynczym modelem jest z natury nierówne — ten pierwszy może po cichu korzystać z tego drugiego (Opus 4.8 należy do puli Fugu).
2.Wiele perspektyw może podnosić jakość — płacisz czasem i pieniędzmi
Na czym polega: Zarówno dekompozycja z delegacją (Fugu), jak i równoległe odpytanie trzech modeli z sędzią scalającym (Fusion API) potrafią poprawić wynik. W teście autora poprawa okazała się niezauważalna, a koszt wzrósł pięciokrotnie.
Jak stosować: Wielomodelowość traktuj jako narzędzie do zadań o wysokiej wartości, gdzie kilka procent jakości jest warte dodatkowych minut i dolarów — a nie jako domyślny tryb pracy.
Na co uważać: Każde dodatkowe wywołanie to podwójna zapłata: za samą pracę i za czekanie. Przy rutynowych zadaniach zwrot z tej inwestycji zwykle nie istnieje.
3.Orkiestracja to dwa pytania: kto robi i kto scala
Na czym polega: Cały mechanizm sprowadza się do przydziału kroków między modele oraz do modelu scalającego poszczególne odpowiedzi w całość. Dokładnie to robi Claude Code z podagentami na Haiku, Sonet i Opus.
Jak stosować: Projektując własne workflow, rozpisz te dwa kroki świadomie: które podzadania trafią do którego modelu i co połączy wyniki. Ten sam schemat działa w skali makro (między dostawcami) i mikro (między wersjami jednego modelu).
Na co uważać: Etap scalania to dodatkowy koszt i miejsce, w którym wyniki częściowe mogą zostać zniekształcone; im więcej ogniw, tym trudniej namierzyć błąd.
4.Ślepy test porównawczy zrobisz sam — zrób go przed zakupem
Na czym polega: Autor wygenerował 38 zadań w Codexie, żeby wykluczyć własną stronniczość, przepuścił oba systemy przez te same prompty i oceniał głównie zero-jedynkowo (zaliczone albo nie), co upraszcza i ułatwia obiektywną ocenę.
Jak stosować: Zanim kupisz subskrypcję, zbuduj własny zestaw 20–30 typowych zadań, przepuść kandydatów przez identyczne prompty i porównaj czas, koszt oraz jakość. Wystarczy rozliczenie API według zużycia.
Na co uważać: Testy tworzone przez AI mają własne ślepe punkty, a model-sędzia też bywa stronniczy. Autor sam zaznacza, że nie przeprowadził ciężkich refaktoryzacji — wyniki traktuj jako wskazówkę, nie wyrok.
5.Proste zadanie na orkiestratorze może czekać minuty zamiast sekund
Na czym polega: W testach Opus odpowiadał na łatwe zadania w sześć sekund, a Fugu na te same potrzebował kilku minut — każde zapytanie przechodzi bowiem przez menedżera, dekompozycję i scalanie. Suma: 357 minut wobec 80.
Jak stosować: Zmierz czas odpowiedzi na swoich codziennych zadaniach, zanim przeniesiesz pracę na orkiestrator. Szybkie pytania i drobne poprawki zostawiaj bezpośrednio pojedynczemu modelowi.
Na co uważać: Narzut dekompozycji jest stały — nie znika przy „lekkich” zadaniach. W pracy interaktywnej, gdzie liczy się tempo, potrafi zniweczyć cały sens narzędzia.
6.Limity subskrypcji multiagentowej znikają błyskawicznie
Na czym polega: Na planie za 200 dolarów autor wypełnił pięciogodzinne okno i doszedł do 34% tygodniowego limitu; na planie za 100 dolarów trzy pełne okna oznaczałyby wyczerpanie limitu. Limity schodzą szybciej niż w Claude Code.
Jak stosować: Porównuj nie ceny abonamentów, lecz koszt typowego dnia pracy: ile okien i wywołań realnie pochłaniają twoje zadania. Rozliczenie API pozwala to zmierzyć, zanim zwiążesz się na miesiąc.
Na co uważać: Orkiestrator uruchamia wiele modeli przy jednym zadaniu — każdy z nich osobno wchodzi do limitów i na rachunek.
7.Fugu w Claude Code działa, ale integracja nie jest trywialna
Na czym polega: Fugu obsłużył umiejętności (skills) i research w środowisku Claude Code, a okno kontekstu w ogóle się nie zapełniało, bo zapytania są kierowane przez serwery Fugu. Podpięcie jest jednak bardziej złożone niż przy GLM 5.2, gdzie wystarczy podmienić endpoint i wkleić klucz.
Jak stosować: Zanim ocenisz usługę, przepuść ją przez własny zestaw narzędzi i zadań; autor udostępnia plik markdown z instrukcją konfiguracji.
Na co uważać: Nietypowy routing może zmieniać zachowanie narzędzi i sposób rozliczania tokenów — lokalne liczniki nie zawsze pokazują to, co dzieje się po stronie dostawcy.
8.Marketingowe „dorównuje Fable” zweryfikuj własnymi zadaniami
Na czym polega: Zapowiedź z 15 milionami wyświetleń obiecywała wyniki Fable i Mythos. W subiektywnym odczuciu autora Fable był wyraźnie lepszy od Opusa 4.8 — natomiast Fugu Ultra nie był.
Jak stosować: Odróżniaj tabele benchmarków od odczuwalnej różnicy w codziennej pracy. Najlepszym filtrem jest twój własny test na twoich zadaniach, nie materiały producenta.
Na co uważać: Komunikaty w stylu „możliwości klasy frontier bez ryzyka kontroli eksportu” to obietnice biznesowe — nie mówią nic o jakości w twoim konkretnym zastosowaniu.
9.Realni beneficjenci: zespoły na wspólnej bazie kodu
Na czym polega: Autor nie zajmuje się ciężkim programowaniem, więc Fugu nie daje mu nic ponad Codex i Claude Code. Jeśli jednak pracujesz w zespole nad jednym repozytorium, perspektywa „recenzenta GPT i planisty Claude w jednym API, bez ręcznego przełączania” może mieć realną wartość.
Jak stosować: Jeśli dziś ręcznie żonglujesz Codexem i Claude Code nad tym samym kodem, orkiestrator może tę żonglerkę zautomatyzować — zacznij od pilotażu na jednym projekcie.
Na co uważać: To hipoteza, nie przebadany scenariusz — autor sam zastrzega, że nie testował Fugu na masowych refaktoryzacjach. Zmierz czas i koszt, zanim przestawisz cały zespół.
10.Umiejętność na przyszłość: ekonomia pojedynczego zadania
Na czym polega: Autor wierzy, że przyszłość to niezamykanie się na jednym dostawcy i świadomy dobór najtańszego modelu, który dla danego zadania nie traci jakości. Przy rosnących cenach modeli ta kompetencja zyska na wartości.
Jak stosować: Prowadź prostą mapę: jakie typy zadań (pisanie, kod, research) najlepiej wychodzą na których modelach i ile kosztują. Ręczne łączenie narzędzi — jak Codex obok Claude Code — to dobry trening przed automatami.
Na co uważać: Automatyczny delegator nie zna twoich priorytetów; bez własnej wiedzy o słabych stronach poszczególnych modeli oddajesz decyzje o kosztach maszynie.
Redakcyjne tłumaczenie
Zapowiedź, którą trzeba było sprawdzić
„Przedstawiamy Sakana Fugu. Nasz model Fugu Ultra osiąga wyniki na poziomie Fable i Mythos, zapewniając możliwości klasy frontier bez ryzyka związanego z kontrolą eksportu” — tak brzmiała zapowiedź Sakana AI, która w jeden dzień obiegła internet. (Informacja dodatkowa: „frontier” to żargonowe określenie najmocniejszych dostępnych modeli; „kontrola eksportu” odnosi się do amerykańskich ograniczeń w dostępie do nich — argument skierowany do firm obawiających się, że taki dostęp mogą stracić.) Tego typu deklaracji nie da się zostawić bez sprawdzenia, więc zabrałem się za testy.
Pierwsza próba odbyła się w moim Claude Code, pracującym na Fugu Ultra 1 million. Na ekranie widać było przeniesioną listę zadań: funkcje dashboardu i jego wygląd. Wystarczył prompt „/goal” — w praktyce nagrany na głos brief — i po niecałej godzinie dostałem kompletny panel. Szczerze mówiąc, robi wrażenie. Dane odświeżają się na żywo; po kliknięciu jednego przycisku widzę statystyki, „puls odbiorców”, rozkłady i wyniki: medianę, wartości odstające. Widzę, co u mnie działa, co nabiera tempa, co kuleje — i dostaję gotowe rekomendacje. Do surowych liczb z mojego kanału dochodzi więc analiza robiona przez AI. Mogę wejść w pojedyncze filmy i obejrzeć ich metryki, przejrzeć odbiorców i komentarze, zajrzeć do strategii. A wszystko to powstało w odpowiedzi na jeden prompt „/goal” wystawiony Fugu Ultra.
Skąd się wzięła nazwa i co siedzi pod maską
Za całością stoi sakana.ai, firma z Japonii. „Sakana” znaczy po japońsku „ryba” — i widać to w logo: mnóstwo małych rybek układa się w jedną dużą. Dokładnie tak działa Fugu: to system wielu agentów sprzedawany jako jeden model. (Informacja dodatkowa: „fugu” to rozdymka, więc japońska nazwa marki konsekwentnie trzyma się wodnego świata.) W praktyce dostajemy jedno API, które koordynuje zapytania i kieruje je do różnych czołowych modeli: Opusa, GPT, Geminiego i zapewne kilku innych.
Sam pomysł nie jest niczym nowym. To główny agent dowodzący grupą podagentów, z których każdy siedzi na innym modelu i w innej specjalności — po prostu ładnie opakowany. Od dawna powtarzam: w pracy z AI najlepiej sprawdza się zasada „jeden model — jedna, bardzo konkretna rzecz”, a świetne efekty biorą się z łańcuchowania, w którym wynik jednego narzędzia staje się wejściem następnego. Dokładnie tak Sakana dochodzi do wyników z benchmarków, na których Fugu wyprzedza Fable, GPT-5.5 i Opusa 4.8 — bo w gruncie rzeczy każe im pracować razem.
I jedno zastrzeżenie, żeby nie było niedomówień: Fugu nie jest własnym, mądrzejszym modelem, który pobił Fable. Firma pokazuje, że orkiestrując kilka modeli, uzyskała na niektórych testach lepsze rezultaty niż Fable i wersja preview Mythosa. To różnica zasadnicza.
Skoro komunikat zrobił taki szum, postanowiłem zmierzyć Fugu Ultra z Claude Opusem 4.8 na 38 testach. Poniżej — jak testowałem, co z tego wyszło i czy sam chciałbym tego używać.
Dyrygent i specjaliści
Tak, Fugu Ultra dało się wpuścić do Claude Code. Komu zależy na szczegółach: w mojej darmowej społeczności na Skool czeka plik markdown — wrzucacie go Claude Code, podajecie klucz API i gotowe. (Informacja dodatkowa: Skool to platforma do prowadzenia społeczności internetowych; w „classroom”, w zakładce „all YouTube resources”, znajdziecie wszystkie materiały z kanału za darmo.)
Wróćmy do dashboardu. Fugu budował go zespołowo: GPT, zapewne trochę Geminiego do warstwy wizualnej, GPT-5.5 i pewnie parę innych. Pod spodem jest jedno API z niewielkim modelem-menedżerem, wytrenowanym wyłącznie do rozbijania zadania na części i przekazywania ich dalej. Pytanie zadajemy dyrygentowi, a dyrygent zleca pracę specjalistom: Claude może pisać, GPT siedzieć w kodzie i łatać błędy, Gemini zbierać fakty i robić research. Dochodzą kolejne modele, dobierane do złożoności zadania.
Cała sztuka sprowadza się do jednego: kto decyduje o podziale pracy. Na jednym końcu skali wszystko robicie ręcznie — to wy wybieracie wykonawcę do każdej części. Na drugim końcu model ogarnia to sam. I znów: nic nowego — pewnie większość z was robi coś podobnego codziennie, nawet o tym nie myśląc. Claude Code zachowuje się tak samo, kiedy rozbija plan, uruchamia podagentów i zleca zadania robotnikom na Haiku, Sonet lub Opus. (Informacja dodatkowa: Haiku, Sonet i Opus to trzy „rozmiary” modeli Claude — od najlżejszego do najmocniejszego.) Różnica jest jedna: Claude Code dyryguje wyłącznie modelami Claude, a Fugu — modelami różnych rodzin. Skoro GPT ma swoje mocne strony, a Opus swoje, dostajemy to, co najlepsze, ze wszystkich światów naraz — Fugu jest bowiem wytrenowany tak, by wiedzieć, który model w czym jest dobry i co komu zlecić.
Czyli, bez ubarwiania: bardzo sprytne API opakowane wokół znanego wzorca. Jeśli już pracujecie z Codexem i Claude Code nad wspólną bazą kodu, ten układ znacie — tutaj po prostu delegowanie dzieje się samo.
Dwa pytania, z których składa się orkiestracja
W gruncie rzeczy orkiestracja to dwa pytania. Pierwsze: kto robi którą część? Jeśli zadanie X składa się z kroków A, B i C, krok A bierze jeden model, krok B drugi i tak dalej. Drugie: kto scala? Kiedy poszczególne modele zwrócą odpowiedzi, potrzebny jest jeszcze jeden LLM, który złoży je w całość i przedstawi wynik. To niemal dokładnie ta sama mechanika, którą znacie z podagentów Claude Code.
Cały kod HTML dashboardu — też zbudowany w całości przez Fugu, dla jasności — wrzucam za darmo do społeczności, gdyby ktoś chciał dokopać się do szczegółów.
A jak na tym tle wypada Fusion API?
Przy okazji przyszło mi do głowy Fusion API od OpenRouter, które zadebiutowało tydzień czy dwa wcześniej. Z pozoru podobna idea, w praktyce inna. Fusion nie rozbija zadania i nie deleguje — wysyła wasz prompt do trzech modeli naraz, każe wszystkim odpowiedzieć na to samo, a potem sędzia scala trzy odpowiedzi w jedną. To samo w sobie też podnosi jakość rezultatów. Ogólny wniosek z obu podejść: gdy na wasz problem patrzy kilka różnych modeli, wynik zwykle wychodzi lepszy. Pozostaje pytanie, za jaką cenę — czasową i finansową. A tanio nie jest.
Ile to kosztuje
Wziąłem plan za 200 dolarów miesięcznie. Wypełniłem pięciogodzinne okno i sięgnąłem 34% tygodniowego limitu — przy czym subskrypcję podniosłem ze 100 do 200 dolarów dopiero w trakcie testów. Liczcie więc tak: na planie stuzdolarowym trzy pełne okna pięciogodzinne realnie wyczerpałyby mi cały tygodniowy limit. Te progi schodzą wyraźnie szybciej niż w mojej subskrypcji Claude Code.
Start jest prosty: zakładacie konto na sakana.ai i wybieracie subskrypcję albo rozliczenie API według zużycia. Dostępne są Fugu i Fugu Ultra — dla pełnej przejrzystości: ja testowałem wyłącznie wersję Ultra.
Jak wyglądał test
Zestaw zadań przygotował Codex — po to, by wykluczyć moją stronniczość i przecieki między testami. Wszystko szło przez rozliczenie API: Opus 4.8 przechodził przez wszystkie próby i Fugu przechodził przez wszystkie próby, a porównywaliśmy wyłącznie wyniki. Trzeba przy tym pamiętać, że Opus 4.8 jest jednym z modeli, po które Fugu sięga — realnie jakieś 60% wspomnianego dashboardu powstało właśnie na Opusie, podobnie jak HTML-owe decki. Miejcie to z tyłu głowy.
Konkrety: 38 zadań w czterech falach — zagadki, pułapki, specyfikacje do zrealizowania i ciężkie algorytmy. Oceniał Codex, oba systemy dostawały identyczne prompty i wejścia, a duża część zadań była pomyślana zero-jedynkowo (zaliczone albo nie) — właśnie dla obiektywności.
Wyniki: remis za pięciokrotną cenę
Bilans: 36 z 38 zadań zakończyło się remisem, dwa pozostałe wygrał Opus. Co samo w sobie ciekawe, skoro Opus 4.8 siedzi w środku Fugu Ultra. Ale bardziej niż punkty zainteresował mnie czas oczekiwania. Wszystkie przebiegi Fugu zajęły łącznie 357 minut; Opus uporał się z tymi samymi 38 zadaniami w 80 minut. Najbardziej wymowne były łatwe pozycje: Opus odpowiadał w sześć sekund, a Fugu na to samo potrzebował kilku minut.
Rachunek wygląda podobnie. Opus kosztował przez wszystkie wywołania jakieś 10 dolarów, Fugu — 50. Pięć razy tyle. Spodziewałem się, że będzie drożej — zakładam, że Fusion API też nie jest tani — ale nie pięciokrotnie. A skoro już tyle dopłacam, to oczekiwałbym zauważalnie lepszej jakości, której w moich zastosowaniach po prostu nie odczułem. Przy takich samych wynikach po co czekać dłużej i płacić więcej? No właśnie.
Fugu w codziennym użyciu: działa, tylko wolno
Poza formalnym testem wpuściłem Fugu do Claude Code i przegoniłem przez swoje codzienne zajęcia — umiejętności (skills), research. Działało bez zająknięcia; trudno, żeby było inaczej, skoro pod maską siedzą Opus 4.8 i GPT-5.5. Po prostu było przeraźliwie wolno.
Jest i ciekawostka techniczna: okno kontekstu w ogóle się nie zapełniało. Mogłem prowadzić 20–30 rund rozmowy, a licznik stał na zerze — to skutek sposobu, w jaki ruch jest kierowany przez serwery Fugu. Nie będę tu rozkładał konfiguracji na czynniki pierwsze, bo nie jest to tak proste jak przy GLM 5.2, gdzie wystarczy podmienić endpoint i wkleić klucz. Wszystko siedzi w tamtym pliku markdown w społeczności.
Werdykt
Nagrałem ten odcinek, bo gdy zapowiedź zbiera 15 milionów wyświetleń, a w komunikacie widnieje „dorównuje Fable i Mythos”, każdemu świerbią ręce, żeby to wypróbować — mnie też. Szczera konkluzja: w moich zastosowaniach Fable był wyraźnie lepszy od Opusa 4.8. Fugu Ultra wyraźnie lepszy nie jest.
Nie odbieram im zasług — te metryki robią wrażenie i wierzę, że to kierunek rozwoju. Tylko nie sądzę, żeby to była odpowiedź dla mnie, dziś. Nie będę tego używał; może jeszcze trochę potestuję, ale do pracy z wiedzą nie mam na to potrzeby — więcej wycisnę z subskrypcji Codexa i Claude Code. Z drugiej strony nie zajmuję się ciężkim developmentem: nie buduję produktów, nie pracuję w zespołach siedzących na jednym repozytorium. A jeśli to właśnie jest wasza codzienność, korzyść może być realna — recenzent GPT i planista-pomysłodawca Claude w jednym API to kusząca perspektywa.
Jedno zastrzeżenie: nie odbierajcie tej analizy jak wyroku. Nie przepychałem Fugu przez dziesiątki refaktoryzacji dużych baz — przepuściłem go przez zestaw testów wygenerowanych przez AI. I pamiętajcie: to nie jest mądrzejszy model, to menedżer.
Orkiestracja jako umiejętność przyszłości
Najważniejsza myśl, którą z tego wynoszę. Przyszłość to niezamykanie się na jednym dostawcy i rozumienie ekonomii pojedynczego zadania: jaki najtańszy model wystarczy do tej konkretnej pracy, nie tracąc jakości? Ta kompetencja moim zdaniem szybko zyska na wartości. OpenRouter nie wypuścił swojego API przez przypadek — sam przecież próbuję robić to ręcznie, dobierając Codexa i Claude Code do ich mocnych stron. A gdy Fable wróci — jeśli w ogóle wróci — i ceny modeli pójdą w górę, biegłość w dostrajaniu kosztów do jakości będzie umiejętnością pierwszej kategorii, o którą trzeba dbać na co dzień.
Po tym bojowym sprawdzianie będę uważnie obserwować Sakana AI i cały nurt orkiestracji. Krótki to był odcinek, ale mam nadzieję, że coś wam z niego zostało. Jeśli tak — łapka w górę bardzo pomaga. Wpadnijcie do darmowej społeczności na Skool, dziś już grubo ponad 400 tysięcy osób; w środku wszystkie materiały z kanału za darmo: repozytoria z GitHuba, skille, pliki markdown, przewodniki. Dzięki, że dotrwaliście do końca — do zobaczenia w następnym odcinku.