How to use Fable 5 Better than 99% of People

2026-07-09 Jack Roberts AI zagraniczne tutorial waga 3/5 16 min czytania

Praktyczny test Fable 5 kontra Opus 4.8 z gotową strategią: kiedy płacić za najdroższy model, a kiedy zlecić robotę tańszym. Dla osób budujących z AI i pilnujących kosztów tokenów.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

O czym jest ten film

  1. Autor przepuszcza Fable 5 przez cztery praktyczne testy i porównuje go z Opus 4.8 zamiast ufać benchmarkom.
  2. Główna teza: nie chodzi o model, tylko o to, jak się go używa — operator liczy się co najmniej tak samo jak narzędzie.
  3. Koszty tokenów są dramatycznie różne między modelami, więc ta sama praca może kosztować kilkadziesiąt dolarów albo kilka.
  4. Test „ślepej próby” na e-mailu sprzedażowym: różnica między Fable 5 a Opus 4.8 jest subtelna.
  5. W pracy projektowej (strony WWW, dashboardy) Fable 5 wyraźnie prowadzi jakościowo.
  6. Silna strategia: Fable 5 robi projekt/„myślenie”, a tańsze modele wykonują resztę.
  7. Dogrywanie do zespołu innych modeli (Gemini, DeepSeek, GPT) do cross-referencji realnie poprawia efekt.
  8. Praktyczna reguła: kiedy sięgać po Fable 5 (smak, strategia, decyzje nieodwracalne), a kiedy odpuścić.
  9. Sześć konkretnych trików na oszczędzanie kredytów i tokenów.
  10. Różnica między orkiestracją modeli („Ministerstwo Agentów”) a zwykłym delegowaniem zadań.

Redakcyjne tłumaczenie

Wstęp: nadążanie za modelami jest wyczerpujące i kosztowne

Nadążanie za wszystkimi nowymi modelami i strategiami jest męczące i drogie. W tym materiale przepuściłem najpotężniejszy model świata przez cztery testy i na tej podstawie pokażę ci moją zupełnie nową strategię, która daje świetne wyniki znacznie taniej — a przy okazji obalę największe nieporozumienie, które cię hamuje. Dzięki temu zaoszczędzisz czas, zarobisz więcej i wyprzedzisz innych o lata świetlne.

Jeśli mnie nie znasz — jestem Jack. Zbudowałem mały start-up technologiczny z ogromną liczbą klientów, a teraz buduję własne start-upy AI i dzielę się tym, co naprawdę działa. Nalej sobie kawy i wchodzimy w temat.

Benchmarki to nie wszystko

Fable 5, sto tanich agentów i kilka dodatkowych testów. Powiem wprost: te benchmarki są mniej więcej tak wiarygodne jak recenzje z Rotten Tomatoes. Bez urazy dla ludzi, którzy je robią — odwalają dobrą robotę, ale to bardzo trudne do przewidzenia. Benchmarki zawsze mówią, że Fable 5 jest zdecydowanie najlepszy, ale nie uwzględniają dwóch rzeczy: po pierwsze, jak my faktycznie używamy modelu, a po drugie, czy istnieją inne strategie, dzięki którym uzyskamy lepsze wyniki.

Osobiście nie obchodzi mnie, co mówi benchmark. Oceniam model po jego wynikach — dlatego musimy realnie zobaczyć, jak Fable 5 wypada obok Opus 4.8.

Kluczowa zasada: to nie model, to sposób użycia

Jedna podstawowa rzecz, bez której nic z tego nie będzie miało sensu: liczy się nie model, tylko to, jak go używasz. Używanie Fable 5 bez znajomości właściwych strategii jest jak danie komuś konta na 99. poziomie i wrzucenie go do gry, w której nigdy nie grał — to kompletny nowicjusz. Gracz jest równie ważny, a może i ważniejszy niż sam model. Ekspert ze słabszym modelem zwykle pobije nowicjusza z najlepszymi narzędziami. Sama surowa moc nie wystarczy — trzeba wiedzieć, jak jej użyć.

Pieniądze: te same zadania, skrajnie różne koszty

To prowadzi nas do kwestii pieniędzy. Spójrz na to: ta sama praca, około 2 miliony tokenów na wejściu i mniej więcej 500 tysięcy na wyjściu. W przeliczeniu na stawki za tokeny Fable 5 kosztuje 45 dolarów. Dla porównania GLM 5.2 to 3,36 dolara, a DeepSeek około 1,30. Widać ogromną różnicę. Byłem naprawdę ciekaw, jak daleko można pójść z tymi modelami i co się stanie, gdy zastosujemy różne strategie — jak to wpłynie na nasze projekty i oszczędności.

Test 1: Czy w ogóle poznasz różnicę? (e-mail sprzedażowy)

Pierwszy test: czy jesteś w stanie odróżnić, który model co napisał? Wziąłem ten sam prompt — raz dla Fable 5 na ustawieniu „extra high”, raz dla Opus 4.8. Zadanie nie polegało wyłącznie na napisaniu e-maila, ale na użyciu realnego narzędzia — Firecrawl, które świetnie ściąga dane z dowolnej strony.

(Informacja dodatkowa: Firecrawl to usługa, która pobiera treść strony jako czysty tekst, a nie surowy HTML — dzięki temu model dostaje mniej „śmieciowego” kontekstu i zużywa mniej tokenów.)

Chciałem wejść na glider.com — narzędzie do dyktowania, które współtworzyłem — i przygotować e-mail wychodzący. To ciekawe przy różnych modelach, bo Firecrawl czyta tekst, a nie HTML, więc nie zapychasz kontekstu zbędnymi rzeczami. Oszczędzanie tokenów przy mocniejszych modelach jest kluczowe.

Prompt brzmiał mniej więcej tak: jednym strzałem, bez dopytywania i podpowiedzi, przeprowadź pełną pętlę. Napisz zimny e-mail zapraszający na 15-minutową rozmowę zapoznawczą w imieniu mojej agencji automatyzacji AI. Użyj Firecrawl, żeby zescrapować stronę Glider. Wyślij jeden zimny e-mail: temat, zwykły tekst w treści, 150 słów, spersonalizowany na podstawie tego, co znajdziesz.

Nie zdradziłem, który model jest który. E-mail A („Kto oszczędza twojemu zespołowi 20 godzin?”) jest odrobinę zbyt rozwlekły — mógłby być krótszy — ale prowadzi do konkretnej akcji: proponuje rozmowę i prosi o dogodny termin. To dobry kierunek. Drugi e-mail też trafia w sedno, ale jest przegadany, ma dużo myślników i za dużo tekstu.

Oba działały w całkowicie odseparowanych środowiskach kontenerowych, więc podczas oceny nie wiedziałem, co jest czym. Powiedziałbym, że są mniej więcej równorzędne, choć jeden ma lepszy temat i logikę. Ujawnienie: e-mail po lewej napisał Opus 4.8, ten po prawej — Fable 5. Ogólnie logika wersji Fable 5 była nieco lepsza, ale to była bardzo wyrównana próba bazowa.

Pierwsza strategia: oszczędzaj tokeny, gdzie się da

To prowadzi do pierwszej kluczowej strategii: oszczędzaj tokeny wszędzie, gdzie możesz. Usługi takie jak Firecrawl, a także usuwanie długich plików claude.md, wywołań umiejętności czy MCP, które potrafią zapchać całe okno kontekstu — to wszystko kosztuje mnóstwo pieniędzy. Krok pierwszy: wytnij ten balast. Krok drugi: realnie zastanów się, czy do tego konkretnego zadania w ogóle potrzebujesz Fable 5.

Przy cytowaniu i przepisywaniu tekstu Fable 5 jest trochę lepszy, ale jego przewaga tkwi bardziej w myśleniu i pozycjonowaniu niż w samym tworzeniu treści. Różnica między Opus 4.8 a Fable jest realna, ale Opus 4.8 świetnie nadaje się do wielu zadań.

Test 2: Budowa strony WWW — Fable 5 kontra Opus 4.8 z zespołem modeli

Dla odniesienia mam dwie strony. Jedną zaprojektował Opus 4.8 — jest całkiem niezła, porządna, zbudowana według zasad, których uczę. Drugą zrobił Fable 5 — poziom wyżej: lepsza interaktywność, przemyślane elementy, konwersje, i wygląda po prostu przepięknie. Fable 5 to potężny agent projektowy.

Postanowiłem przetestować je razem na budowie strony. Fable 5 z jednej strony, a Opus 4.8 z drugiej — ale Opus dostał możliwość dogrywania innych modeli: DeepSeek, ChatGPT i Gemini, żeby wzajemnie się sprawdzały i podnosiły jakość.

(Informacja dodatkowa: „dogrywanie” innego modelu oznacza, że jeden model podczas pracy wywołuje drugi, by ten zrecenzował lub uzupełnił jego wynik.)

Zadanie: „Zbuduj mi stronę sprzedającą żółte czapki, niech wygląda cool”. Wersja Opus 4.8 ze swoją zbieraną drużyną modeli poradziła sobie ciekawie: fajny nagłówek, żółty motyw, zgrabne detale (nawet zaznaczanie tekstu jest żółte), sekcja z czapkami, dobre copy w stylu „Żółty to nie kolor, to zobowiązanie”. Uważam, że dogranie drugiego modelu to jedna z najbardziej przewagowych rzeczy, jakie możesz zrobić — to jak kreatyna świata AI, to hack. Co ciekawe, Gemini wyłapało problemy z copy i optymalizacją mobilną, których Opus 4.8 sam nie uwzględnił, a DeepSeek dobrze podszedł do treści i zakwestionował ją zwrotnie. To była realna praca zespołowa.

Wersja Fable 5 ma więcej charakteru — żółto-czarny styl, „bucketowo-klockowaty” wygląd, świeże copy („Żółte głowy gadają”, „10% zniżki na pierwsze zamówienie”). Dodam, że powstała w zupełnie oddzielnym oknie. Ogólnie z projektowego punktu widzenia Fable 5 jest po prostu lepszy.

Jeden wielki wniosek: jeśli to praca projektowa, to Fable 5 ma wykonać ciężką pracę — zrobić wstępny projekt, bo jest w tym najlepszy i naprawdę rozumie, jak wygląda dobry design. Kiedy projekt jest gotowy, dogrywasz tańsze modele (co najmniej o 50% tańsze), żeby wykonały to, co Fable zaprojektował. Ale sam proces cross-referencji copy i sprawdzania optymalizacji mobilnej robi dużą różnicę niezależnie od modelu.

Test 3: Tryb „unleashed” — Fable, Opus i tani rój

Poziom trzeci, trzy oddzielne wyzwania. Numer jeden: Fable w trybie „unleashed” — z własnymi sub-agentami (czego wcześniej modele nie miały) i swobodą dogrania dowolnego modelu. To z założenia powinna być najlepsza opcja. Numer dwa: to samo, ale na Opus 4.8. Numer trzy: mój koń pociągowy — Sonnet 5 plus rój (swarm), czyli eksperyment „co się stanie, gdy po prostu zaprzęgniemy wiele tańszych modeli do pracy”.

Zadaniem był dashboard. Wersja A jest całkiem niezła — ma ten „claude’owy” klimat, interaktywny wykres kołowy, bardzo standardowy Claude. Jak na jeden strzał — nieźle. Wersja B pozbyła się tej „claude’owej trucizny projektowej”, w której wszystko wygląda tak samo (jak zobaczysz taki design, od razu wiesz, że zrobił to Claude). Jest mniej interaktywna, ale wizualnie odrobinę wyżej. Wersja C rozminęła się z celem o milion mil — choć jako jedyna miała odwagę spróbować czegoś szalonego.

Ujawnienie: wersja A to Opus, wersja B to Fable, a wersja C to rój tanich modeli. Wniosek? Fable 5 jest o kategorię wyżej — różnica jest, ale nie jest szalona; większość ludzi by jej nie zauważyła. I tu sedno: większość różnicy bierze się z twojej strategii promptowania. Fable jest po prostu trochę mądrzejszy, ale wszystko rozbija się o to, jakie pytania zadajesz.

Widać za to gigantyczną różnicę, gdy pozwolisz tanim modelom działać bez nadzoru — one wręcz „walą w klawisze” i sieją chaos. Wyraźnie potrzebny jest inteligentny orkiestrator, żeby te systemy w ogóle działały.

Wnioski: kiedy warto płacić podwójnie

Rzecz do zapamiętania: możliwości są względnie zbliżone. Fable 5 myśli na wyższym poziomie i widać, że jest lepszy we wszystkich obszarach, ale to nie tak, że Opus 4.8 rysuje kredkami w kącie. Jest lepszy — ale kosztuje dwa razy tyle. Czy warto? Tak, dla pewnych rzeczy: dla orkiestracji, dla zadań wymagających inteligencji. Ale nie do policzenia, ile to jest 10 plus 10.

Byłem niedawno w supermarkecie na Węgrzech, patrzyłem na kubełek i zastanawiałem się, czy to jogurt grecki. Zapytałem o to Fable 5 i chyba wydałem na tokeny więcej, niż kosztował sam jogurt. Tak wygląda 2026 rok. Zawsze musisz mieć w głowie ten kompromis: to jak Lamborghini — od zera do setki w rekordowym czasie, ale słono za to zapłacisz.

Kiedy sięgać po Fable, a kiedy odpuścić

Fable dogrywasz w następujących sytuacjach — i tak sam robię:

  • Kiedy liczy się smak. A smak liczy się zawsze. Duże projekty i strony robię na Fable 5.
  • Edycje przekazuję Opus 4.8 lub innym modelom. Co ciekawe, DeepSeek V4 z dobrym frameworkiem edycyjnym jest w tym nadzwyczaj świetny — zwłaszcza gdy działa w istniejącej strukturze, architekturze i modelu danych.
  • Patrzenie za róg — praca strategiczna. To, co Jeff Bezos nazywa „drzwiami jednokierunkowymi”: większość decyzji w biznesie i życiu jest odwracalna, ale niektóre nie — gdy przez nie przejdziesz, nie ma odwrotu. To terytorium Fable 5, bo koszt błędu jest zbyt wysoki. Do strategii używaj Fable 5 — dopóki nie pojawi się lepszy model.
  • Debugowanie, gdy nic innego nie pęka. Lubię przepuszczać wszystko przez Fable 5, żeby mieć pewność.

Kiedy odpuścić Fable? Tam, gdzie inne modele wyłapią błędy, przy pracy masowej i gdy masz już gotową infrastrukturę. Praktycznie może się okazać, że tylko 5% twoich decyzji trafi do Fable 5. Gdyby tokeny nie były problemem, mógłbyś zejść do 50/50. Chodzi o właściwy model do właściwego zadania — jesteśmy agnostyczni wobec modeli. Jeśli jutro Mistral wypuści „fable blastera”, pogadamy o tym.

Realia są takie: już płacisz za Opus 4.8 — masz go w subskrypcji. Nie wiemy, czy Fable 5 zostanie na stałe w aplikacji Claude; jeśli tak, zmieni to układ. Ale gdy twój dostęp do Fable 5 wygaśnie, za Fable płacisz za tokeny — więc dogrywaj go tylko do naprawdę ważnych rzeczy z jasnym zwrotem z inwestycji, gdzie liczy się smak i decyzja jest istotna.

Sześć hacków, które od razu poprawią wyniki i oszczędzą kredyty

  1. Rozdziel pracę (routing). Tanie modele do roboty czarnej, Fable do myślenia. Niech Einstein liczy, a nie myje podłogi.
  2. Cache’uj kontekst. Możesz usunąć mnóstwo tokenów. Zadbaj też, by twój plik konfiguracyjny miał sensowny rozmiar. Jesteśmy w punkcie, w którym nie zaprojektujesz systemowego promptu lepiej niż Anthropic — harness robi świetną robotę. My sterujemy i kierujemy, ale nie przejmujemy tego na siłę.
  3. Przycinaj okno. Stare pliki siedzą w historii i są przebudowywane przy każdej wiadomości — to potrafi kosztować 20 tysięcy tokenów. Gdy model kończy zadanie, otwieraj nowe okno, żeby oszczędzić kontekst.
  4. Specyfikacja najpierw, uruchom raz. Najważniejszy prompt, jaki kiedykolwiek napiszesz, to prompt pierwszy. Jeśli dopytujesz w trakcie („to nie tak, chciałem inaczej”), jakość spada, a koszty wymykają się spod kontroli. Poświęć czas na dopracowanie pierwszego promptu i specyfikacji — możesz nawet przygotować je innym modelem, a potem wystrzelić to jak strzałę prosto w cel.
  5. Strategia myślenia. Większość ogólnych, gawędziarskich pytań rób na ustawieniu „low” — jest lepsze niż „extra high” na Opus 4.8. To ważne.
  6. Deleguj do sub-agentów hałaśliwe, drobne rzeczy — sprawdzanie, do którego nie potrzebujesz największego rozumu — żeby oszczędzać tokeny.

Orkiestracja kontra delegowanie: „Ministerstwo Agentów”

Zanim wejdą reklamy w komentarzach — czym różni się to od „Ministerstwa Agentów”? (Informacja dodatkowa: autor żartobliwie nazywa „Ministerstwem” to, co bywa określane jako „mixture of agents” — mieszanka/rada agentów.)

Na przykładzie harnessu Hermes: masz agenta-orkiestratora, który pyta Fable 5 o coś w rodzaju „w jakim kraju najlepiej byłoby mi żyć?”. Fable 5 zadaje to samo pytanie wszystkim modelom pod sobą, nie wie, kto co odpowiedział, porównuje notatki, syntezuje je i oddaje ci najlepszą złożoną odpowiedź. Widać nawet, jak poszczególne modele wypadają. To fundamentalnie inna, kluczowa strategia, którą warto wdrażać.

Uzupełnij to o recenzję kodu przez Codex. Nigdy niczego nie wysyłam, dopóki Codex i inny model nie przejrzą całego kodu. Modele potrafią zaklinać się, że wszystko jest idealne — a gdy dograsz Codex, ten znajduje coś krytycznego. Zdarza się to zaskakująco często.

Pamiętaj: „smak tygodnia” w kwestii modeli będzie się zmieniał, ale umiejętności z tego materiału zostaną z tobą na zawsze. Znajomość najlepszych modeli i strategii to jedno — ale jeśli nie wiesz, jak wykorzystać Fable 5 we własnym agentowym systemie operacyjnym, zostawiasz na stole zbyt dużo wartości.

10 najważniejszych takeaways — z kontekstem zastosowania

1.To nie model, tylko sposób jego użycia

Na czym polega: Największa różnica w wynikach bierze się nie z wyboru modelu, lecz ze strategii promptowania i doświadczenia operatora. Najlepszy model w rękach nowicjusza przegrywa ze słabszym w rękach eksperta.

Jak stosować: Zanim wydasz więcej na droższy model, dopracuj prompt, kontekst i proces. Traktuj naukę strategii jako inwestycję ważniejszą niż sam upgrade modelu.

Na co uważać: Nie tłumacz słabych wyników „za słabym modelem” — najpierw sprawdź własny prompt i higienę kontekstu. To wygodna wymówka, która kosztuje pieniądze.

2.Benchmarki nie mówią, jak model zachowa się u ciebie

Na czym polega: Rankingi zawsze wskazują Fable 5 jako najlepszy, ale nie uwzględniają twojego sposobu pracy ani alternatywnych strategii. Autor ocenia modele po realnych wynikach, nie po tabelkach.

Jak stosować: Zrób własne, praktyczne testy na swoich typowych zadaniach (e-mail, strona, dashboard) i porównaj wyniki „na ślepo”, bez wiedzy, który model co zrobił.

Na co uważać: Ślepy test wymaga odseparowanych środowisk — inaczej podświadomie faworyzujesz „droższy” model. Jedna próba to za mało na wniosek.

3.Ten sam efekt może kosztować kilkadziesiąt dolarów albo kilka

Na czym polega: Te same 2 mln tokenów wejścia i 0,5 mln wyjścia to 45 dolarów na Fable 5, 3,36 na GLM 5.2 i około 1,30 na DeepSeek. Różnice w koszcie są rzędów wielkości.

Jak stosować: Świadomie mapuj zadania do modeli według wartości. Rutynę i wolumen kieruj do tanich modeli, a najdroższy zostaw na wąskie, wysokowartościowe momenty.

Na co uważać: Łatwo „przepalić” budżet na banały — jak autor, który wydał na pytanie o jogurt więcej niż kosztował jogurt. Pilnuj, do czego naprawdę odpalasz najdroższy model.

4.Przy zadaniach tekstowych różnica bywa niezauważalna

Na czym polega: W teście e-maila sprzedażowego Fable 5 i Opus 4.8 dały porównywalne wyniki; przewaga Fable była subtelna i dotyczyła raczej logiki i pozycjonowania niż samego copy.

Jak stosować: Do tworzenia i edycji tekstu śmiało używaj tańszego Opus 4.8 (lub innych modeli). Fable 5 zostaw tam, gdzie liczy się strategiczne „ustawienie” treści.

Na co uważać: „Porównywalne” nie znaczy „identyczne” — przy tekstach o wysokiej stawce marketingowej różnica w pozycjonowaniu może mieć znaczenie. Testuj na swoich realnych przypadkach.

5.Firecrawl i higiena kontekstu tną koszty tokenów

Na czym polega: Firecrawl podaje modelowi czysty tekst zamiast HTML, a usunięcie zbędnych plików, MCP i wywołań umiejętności odchudza okno kontekstu. To bezpośrednia oszczędność.

Jak stosować: Krok 1 — wytnij balast z kontekstu i podawaj oczyszczone dane. Krok 2 — zapytaj siebie, czy to zadanie w ogóle wymaga najdroższego modelu.

Na co uważać: Rozdmuchany plik konfiguracyjny i długie pliki „w tle” są przebudowywane przy każdej wiadomości i potrafią kosztować dziesiątki tysięcy tokenów, zanim zaczniesz właściwą pracę.

6.Do projektowania używaj Fable 5, do wykonania — tańszych modeli

Na czym polega: W testach stron i dashboardów Fable 5 wyraźnie prowadził jakością wizualną i wyczuciem konwersji. To jego najmocniejsza domena.

Jak stosować: Niech Fable 5 zrobi wstępny projekt i „ciężkie” decyzje projektowe, a co najmniej o połowę tańsze modele wykonają resztę na jego podstawie.

Na co uważać: Nie odwracaj ról — oddanie samego projektu tanim modelom da efekt „każdy design wygląda tak samo”. Przewaga Fable jest właśnie na etapie koncepcji.

7.Dogrywanie drugiego modelu do cross-referencji to realny hack

Na czym polega: Opus 4.8 z dogranym Gemini, DeepSeek i ChatGPT wyłapał problemy z optymalizacją mobilną i copy, których sam by nie znalazł. Cross-referencja podnosi jakość niezależnie od głównego modelu.

Jak stosować: Wbuduj w proces krok „drugiej pary oczu”: inny model recenzuje copy, sprawdza mobile i pyta „czego brakuje, jak to poprawić”.

Na co uważać: Do tego potrzebny jest inteligentny orkiestrator. Puszczony luzem rój tanich modeli „wali w klawisze” i sieje chaos zamiast poprawiać.

8.Reguła doboru: smak, strategia, drzwi jednokierunkowe, debug

Na czym polega: Fable 5 warto płacić, gdy liczy się smak, przy pracy strategicznej, przy decyzjach nieodwracalnych („drzwiach jednokierunkowych” Bezosa) i przy debugowaniu, gdy nic innego nie pęka.

Jak stosować: Odpuść Fable przy pracy masowej, edycjach w istniejącej strukturze i tam, gdzie tanie modele wyłapią błędy. Praktycznie ~5% decyzji trafi do Fable 5.

Na co uważać: Pamiętaj, że Opus 4.8 masz już w subskrypcji, a za Fable płacisz za tokeny po wygaśnięciu dostępu — dogrywaj go tylko przy jasnym zwrocie z inwestycji.

9.Pierwszy prompt jest najważniejszy — specyfikacja najpierw

Na czym polega: Dopytywanie w trakcie („to nie tak, chciałem inaczej”) pogarsza jakość i lawinowo zwiększa koszty. Najważniejszy prompt to ten pierwszy.

Jak stosować: Poświęć czas na specyfikację przed uruchomieniem — możesz przygotować ją innym modelem — a potem wystrzel zadanie „jak strzałę w cel”. Po ukończeniu zadania otwieraj nowe okno.

Na co uważać: Iteracyjne poprawki w tym samym oknie kumulują kontekst i koszt. Dodatkowo ogólne, gawędziarskie pytania rób na ustawieniu „low” — bywa lepsze niż „extra high” na Opus.

10.Orkiestracja (rada modeli) i obowiązkowa recenzja Codex

Na czym polega: W modelu orkiestracyjnym Fable 5 zadaje to samo pytanie wielu modelom, nie wie, kto co odpowiedział, i syntezuje najlepszą odpowiedź. To coś innego niż zwykłe delegowanie zadań. Osobno: autor nie wysyła kodu, dopóki Codex i drugi model go nie przejrzą.

Jak stosować: Do trudnych, otwartych pytań używaj rady modeli zamiast pojedynczej odpowiedzi. Do kodu zawsze dokładaj niezależną recenzję (np. Codex) przed wdrożeniem.

Na co uważać: Modele potrafią zapewniać, że „wszystko jest idealne”, a Codex i tak znajduje błąd krytyczny. Nie ufaj samoocenie pojedynczego modelu — konkretne narzędzia się zmienią, ale sama zasada weryfikacji zostaje.