Jak zbudowałem zespół 12 modeli AI jako freelancer — i co z tego wyszło

Mam dwanaście modeli AI pracujących równolegle. Jestem jedną osobą. Koszty: Claude Pro, ChatGPT Plus, i jakieś 5–10 euro dokładane na kredyty Claude, kiedy pula się kończy w środku taska. Tyle. ChatGPT Plus przy takim użyciu — modele jako zewnętrzne węzły systemu, nie codzienny asystent — jest właściwie trudno przepalić do końca. Tokeny Claude’a schodzą szybciej, bo to mózg operacji. Setup kosztował weekend.

Teraz po co w ogóle to robię. AI używam non-stop — do własnych projektów i do pracy z klientami. I jest jedna rzecz, o której mało kto mówi wprost: jeden model to jedna perspektywa. Jeden zestaw martwych punktów. Kiedy opieram się wyłącznie na odpowiedzi jednego modelu, nie mam jak sprawdzić, czy to dobra odpowiedź, czy tylko pewnie brzmiąca.

Multiagent AI to dokładnie to, co sugeruje nazwa. Zamiast jednego modelu, budujesz system, w którym kilka pracuje razem — jedne analizują, inne robią robotę operacyjną, inne głosują nad odpowiedziami i składają je w finalną rekomendację. Jakość wyników jest zauważalnie inna, kiedy trzy modele niezależnie dochodzą do tego samego wniosku, niż kiedy jeden strzelił odpowiedzią.

Dla mnie to szczególnie ważne przy researchu i wchodzeniu w nowe obszary. Dzięki temu dostarczam klientom dane, kod i wyniki, za którymi mogę stanąć — nie dlatego, że jeden model tak powiedział, ale dlatego, że kilka niezależnych źródeł doszło do tego samego miejsca.

Co właściwie zbudowałem

Mózgiem operacji jest Claude Opus 4.6, odpalony przez Claude Code w terminalu. To jest HAL, mój główny asystent AI. HAL ogarnia reasoning, decyzje, pisanie, code review, w praktyce wszystko, co wymaga realnego myślenia. Tokeny Opus nie są tanie, więc nie wykorzystuję go do przeszukiwania plików, odpalania komend w shellu czy pobierania stron. Od tego są subagenty.

Wbudowane w Claude Code mam subagenty zasilane przez Haiku. To małe, szybkie i tanie “robociki” do konkretnych zadań. Bash agent odpala komendy w terminalu. Explore agent przeszukuje codebase. Plan agent robi architekturę z limitem 300 tokenów, żeby nie odpływał. Opus myśli, Haiku wykonuje. Mój rachunek za tokeny spadł, kiedy zacząłem delegować to konsekwentnie.

A potem jest HydraMCP. To jest to, co robi z tego prawdziwy system multiagentowy. HydraMCP to lokalny serwer MCP, który łączy się z zewnętrznymi modelami. Mam 10 wariantów GPT-5.x przez CLIProxyAPI, plus Kimi K2.5 przez Nvidia NIM. Dwanaście modeli łącznie, licząc Claude’a.

HydraMCP daje mi cztery narzędzia:

• ask_model — pingujesz jeden model z pytaniem, dostajesz odpowiedź. Dobre do szybkiego sanity checku.
• compare_models — wysyłasz ten sam prompt do kilku modeli równolegle. Widzisz, jak każdy odpowiedział, z latencją i metrykami tokenów obok siebie.
• consensus — pytasz trzy lub więcej modeli o to samo i sprawdzasz, czy się zgadzają. Strategie: majority, supermajority albo unanimous.
• synthesize — bierzesz najlepsze fragmenty z wielu odpowiedzi i łączysz je w jedną.

Workflow w praktyce: klient zadaje pytanie o strategię produktową. Mówię HAL-owi, żeby odpalił consensus na trzech wariantach GPT-5.x. Jeśli wszyscy się zgadzają, mam wysoką pewność. Jeśli się nie zgadzają, odpalam compare_models, żeby zobaczyć, gdzie jest rozbieżność. Potem albo syntetyzuję najlepsze elementy, albo używam własnej analizy. AI daje mi lepsze inputy do podjęcia decyzji. Nie podejmuje decyzji za mnie.

Ostatnio w trakcie researchu pozwalam HALowi samemu dojść do określonych wniosków, zaprezentować mi je i — jeśli uważam, że ma rację i ma to poparcie w źródłach — akceptuję i wrzucam bezpośrednio do dokumentów projektu.

Co faktycznie działa

7 lutego 2026 odpaliłem pełny stress test. To nie był kontrolowany benchmark. To była realna sesja, w której wrzuciłem konkretne zadania i sprawdziłem, co się wydarzy.

Czasy odpowiedzi były bardzo dobre (według HALa). gpt-5.1-codex wrócił w 960ms. gpt-5-codex zrobił 700ms na pytaniach z dużą ilością kodu. Odpalenie compare_models na czterech wariantach GPT-5.x równolegle zadziałało bez problemu. Cztery odpowiedzi wróciły, sformatowane i gotowe do porównania. Narzędzie consensus trafiło na jednogłośną zgodność, 3 z 3, na testowych pytaniach.

Największą wartość dała mi stabilność. System działał przez 90 minut autonomicznie. Bez interwencji człowieka, bez crashy i bez dziwnych zwieszeń. HAL delegował do subagentów, subagenty robiły swoje, HydraMCP wywoływał zewnętrzne modele, wyniki wracały do głównego wątku. Ja w tym czasie zrobiłem kolację.

Co absolutnie nie działa

Kimi K2.5 dwukrotnie „zniknęło” po stronie odpowiedzi. Poprosiłem je, żeby napisało draft tego posta. Pierwsza próba: wysłałem prompt, czekałem ponad dwie minuty i dostałem pustą odpowiedź. Dosłownie brak treści. Spróbowałem jeszcze raz. To samo. Odłożyłem ten model na później i poszedłem dalej, bo miałem zadania do domknięcia.

Później znalazłem źródło problemu. Kimi K2.5 to reasoning model. Zanim napisze właściwą odpowiedź, robi wewnętrzne „myślenie”, chain-of-thought, który zużywa tokeny. Kiedy ustawienie max_tokens jest za niskie, model zużywa limit na etap rozumowania i nie zostaje mu budżet na właściwy output. Z mojej strony wyglądało to tak, jakby model „odpowiedział niczym”. Po stronie Kimi model wykonywał pracę, tylko nie miał jak zwrócić finalnej treści.

Fix miał dwie części: wymusić minimum 512 tokenów na każde wywołanie reasoning modelu i dodać fallback na odczyt pola reasoning_content, jeśli główny content wraca pusty. Dzięki temu, nawet jeśli model zużyje tokeny na rozumowanie, przynajmniej widzę, w jakim kierunku poszedł. Jest to ważne szczególnie wtedy, gdy serwery NVIDIA są obciążone — twórcy z całego świata korzystają z darmowych tokenów i czas odpowiedzi potrafi wtedy mocno się wydłużyć.

Lekcja: jeśli budujesz system multiagentowy, potrzebujesz fallbacków. Przemyślanych. W praktyce chodzi o plan B, który odpala się, gdy agent zwraca pusty output, nie odpowiada albo łapie rate limit. U mnie to logika, która najpierw próbuje wyciągnąć odpowiedź z reasoning_content, jeśli główny content wraca pusty. Innym razem przekierowuję zadanie do innego modelu w puli, który działa stabilniej. Jeśli odpowiedź jest ucięta, podbijam max_tokens i robię retry. Nie każdy model zachowuje się tak, jak sugeruje dokumentacja. Kimi K2.5 to dobry model, kiedy działa. Ale to „kiedy działa” niesie w sobie sporo ukrytej złożoności.

Aktualizacja (15 lutego): Po wdrożeniu obu poprawek Kimi K2.5 działa stabilnie od ponad tygodnia. Jest wolny — 45 sekund na odpowiedź to norma dla reasoning modelu — ale zwraca wyniki konsekwentnie. Używam go tam, gdzie chcę mieć naprawdę inną perspektywę niż rodzina GPT. Fix był tego wart.

Jak zbudować coś takiego samemu

Zacznij od dwóch modeli, nie trzynastu. Weź jeden mocny reasoning model jako główny mózg. Claude Opus, GPT-5, co wolisz. Potem dodaj jeden tani i szybki model do pracy operacyjnej. Doprowadź to do stabilnego działania, zanim dołożysz kolejne elementy. Złożoność systemu multiagentowego rośnie z każdym modelem. Każdy nowy to nowy punkt awarii, nowe zachowanie API i kolejna pozycja na fakturze. Ja zacząłem od dwóch i dodawałem następne dopiero wtedy, kiedy miałem konkretny powód.

A tutaj porady od HALa dla twojego systemu AI:

Sprawdzaj zdrowie wszystkiego. Zanim wyślesz do modelu realne zadanie, pingnij go czymś trywialnym: „Ile to 2+2?”. Jeśli nie potrafi odpowiedzieć w pięć sekund, nie wysyłaj mu ważnego prompta. Odpalam health checki na początku każdej sesji. Zajmuje to około trzydziestu sekund. W praktyce uchroniło mnie to przed wysyłaniem pracy do modeli, które leżały albo miały rate limit. Loguj każde zapytanie, każdy czas odpowiedzi i każdą awarię. Kiedy coś wyłoży się o 2 w nocy (a to się zdarza), logi robią różnicę między naprawą w pięć minut a długim debugowaniem po omacku.

Wiedz, kiedy przestać pytać modele i zacząć pytać ludzi. Consensus działa dobrze, kiedy trzy modele niezależnie się zgadzają. Ale kiedy się nie zgadzają, odpalisz to drugi raz i dalej masz rozjazd, to zwykle nie jest problem techniczny. To jest trudne pytanie. W zeszłym tygodniu odpaliłem consensus na strategii cenowej i dostałem split 2-1. Odpaliłem jeszcze raz i wyszło tak samo. Zamiast próbować trzeci raz, wziąłem dwa stanowiska, streściłem je w trzech akapitach i wysłałem oba klientowi wraz z własną rekomendacją. To było bardziej użyteczne niż kolejne próby wymuszenia zgodności.

Pilnuj kosztów. Śledzę zużycie tokenów per model, per sesja. Kiedy koszty Opus zaczynają rosnąć, sprawdzam, jakie zadania mogę delegować do Haiku. Kiedy model konsekwentnie daje przeciętne wyniki, odsuwam go na bok zamiast płacić za odpowiedzi, których i tak nie wykorzystam. Traktuj swój zestaw modeli jak skład zespołu. Każdy ma swoje miejsce, ale musi je uzasadniać wynikami.

To w gruncie rzeczy hydraulika, tylko z lepszą obsługą błędów niż w wielu integracjach. Ale kiedy widzisz, jak cztery modele odpowiadają równolegle i dochodzą do tego samego wniosku w mniej niż sekundę, ten weekend poświęcony na konfigurację szybko się zwraca.

Masz już swoje eksperymenty z AI czy dopiero zaczynasz? Napisz na kontakt — pogadamy co ma sens, a co warto odpuścić.