I Tested Opus 5 vs. Fable 5. What You Need to Know.

2026-07-25 Nate Herk | AI Automation AI zagraniczne analiza waga 4/5 16 min czytania

Praktyczne porównanie Opusa 5 i Fable 5 na realnych zadaniach: Opus częściej trafniejszy i tańszy w pracy technicznej, Fable lepszy wizualnie. Dla osób dobierających model do zadania.

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

O czym jest ten film

  1. Autor przepuszcza Opusa 5 i Fable 5 przez serię własnych, realnych zadań, zamiast wierzyć samym benchmarkom.
  2. Wszystkie testy prowadzi głównie w Claude Code (ten sam „harness”), więc zmienną są same modele.
  3. Mierzy trzy rzeczy: koszt w dolarach, czas i zużycie tokenów — a nie tylko „jakość na oko”.
  4. Zadania są przekrojowe: diagramy, przeszukiwanie kodu pod kątem błędów, montaż wideo, landing page, post na LinkedIn, analiza społeczności, prezentacje, computer use i symulator konstrukcji.
  5. Główny wniosek techniczny: Opus 5 bywa dokładniejszy w „podążaniu za instrukcją” i weryfikacji, a przy tym często tańszy.
  6. Główny wniosek estetyczny: Fable 5 nadal wygrywa na polu kreatywności i designu.
  7. Opus 5 potrafi zużywać znacznie więcej tokenów — gdy wychodzi drożej mimo o połowę niższej ceny za token, znaczy to, że był mniej oszczędny.
  8. Modele są niedeterministyczne — dwa uruchomienia tego samego promptu na tym samym modelu dały drastycznie różne wyniki.
  9. Kluczowe nie jest samo „który model lepszy”, tylko jak go instruujesz, jak podajesz kontekst i jak definiujesz warunek zakończenia (weryfikację).
  10. Rekomendacja: dobieraj inteligencję modelu do trudności zadania — do wielu prac codziennych wystarczy nawet starszy Sonnet, a Fable może pełnić rolę orkiestratora delegującego pracę.

Redakcyjne tłumaczenie

Wstęp: benchmarki kontra rzeczywistość

Claude Opus 5 jest już dostępny i benchmarki są naprawdę ciekawe. Okazuje się, że w wielu obszarach, na których mi zależy, wypada lepiej niż Fable — i kosztuje o połowę mniej. Fable 5 pozostaje najmocniejszym, najbardziej imponującym modelem Anthropic. Ale zauważyłem, że przy pracy umysłowej — kiedy tworzę filmy, prowadzę research czy cokolwiek innego — Opus daje mi więcej mocy, niż w ogóle potrzebuję.

Na niektórych wykresach — jak Frontier Bench, Cursor Bench czy indeks agentów kodujących — Opus faktycznie wyprzedza Fable, i to taniej. To mnie zaskoczyło. Do takich rzeczy podchodzę jednak z rezerwą. Fajnie na to patrzeć, ale naprawdę wartościowe jest dopiero przepuszczenie modeli przez własne, prawdziwe zadania. Dlatego w tym materiale rozkładam na czynniki pierwsze serię eksperymentów: Opus 5 kontra Fable 5, z podziałem na koszt, czas i tokeny — żebyś wiedział, gdzie w swoich procesach sięgać po który model.

(Informacja dodatkowa: „harness” to warstwa oprogramowania spinająca model z narzędziami i pętlą działania agenta — tu jest nią Claude Code. Utrzymanie tej samej warstwy sprawia, że porównywane są same modele.)

Prawie wszystkie testy prowadziłem w Claude Code, więc porównujemy modele przy stałym harnessie. Zrobiłem też kilka prób bezpośrednio w czacie Claude, bez otoczki narzędziowej, żeby poczuć, jak modele „się zachowują” same z siebie.

Rozgrzewka: diagram wyszukiwania semantycznego

Poprosiłem Fable 5 i Opusa 5 o wygenerowanie diagramu w Excalidraw, który trafnie i wizualnie tłumaczy, jak działa wyszukiwanie semantyczne z wektoryzacją na dużym zbiorze danych dla agentów AI. Ciekawe jest to, że model nie miał tu żadnych „skills”, żadnego kontekstu o mnie ani sposobu, by cokolwiek zweryfikować — po prostu wypluł plik JSON, który wkleiłem do Excalidraw.

(Informacja dodatkowa: „skills” w ekosystemie Claude to spakowane zestawy instrukcji i zasobów, które model może uruchomić do konkretnego rodzaju zadania.)

Fable pokazał pipeline indeksowania, dużą bazę, wektoryzację — choć przy okazji przekręcił jedno słowo, bo nie miał jak się sprawdzić. A jak wie każdy, kto budował pętle agentowe, weryfikacja jest absolutnie kluczowa. Merytorycznie było jednak trafnie: duży zbiór dzielimy na fragmenty, wektoryzujemy modelem osadzeń, dostajemy embeddingi (liczbową reprezentację danych), wrzucamy do bazy wektorowej i możemy szukać po podobieństwie — bliskie punkty znaczą podobne znaczenie, dalsze tworzą osobne klastry. Zapytanie użytkownika ląduje w przestrzeni i wyciągamy najbliższych sąsiadów.

Układ Opusa wydał mi się bardziej uporządkowany i bardziej szczegółowy, choć Fable był może bardziej „wizualny”. To ocena mocno subiektywna — i takich w tym materiale będzie dużo. Gdybym miał kogoś uczyć, wybrałbym wersję Opusa 5.

Test 1: szukanie błędów w dużym repozytorium

Dałem obu modelom duże repozytorium z zadaniem: przejrzyj kod, znajdź błędy, sprawdź oczekiwane zachowanie i instrukcje. Wynik obu przekazałem do oceny Codeksowi.

(Informacja dodatkowa: „Codex” to konkurencyjne narzędzie/agent kodujący; autor używa go jako niezależnego sędziego.)

Fable zajął około 11 minut i kosztował 5,30 $, Opus 13 minut, ale taniej — 4,22 $. Oba zaliczyły praktycznie wszystko. Codex uznał, że wygrywa Fable, bo jego łatka odpowiadała jeden do jednego oficjalnej poprawce z upstreamu i była czystsza oraz od razu gotowa do przeglądu. Ostatecznie wyniki były podobne, z lekką przewagą Fable na czytelności.

Test 2: to samo zadanie, inne repozytorium

Ten sam typ zadania, ten sam prompt, to samo repo. Tym razem Opus zajął około 20 minut i kosztował 6,50 $, a Fable 12 minut i 8,73 $. Werdykt Codeksu odwrócił się: Opus zaliczył cztery z czterech, Fable dwa z czterech, jeden zostawiając nierozwiązany. Ocena techniczna Opusa: 93 na 95, Fable: 66 na 95 — i to przy Opusie tańszym w tym przebiegu. Oba dobrze poruszały się po repozytorium i niezależnie znalazły kluczowy problem architektoniczny, ale to Opus dostarczył dokładniejszą, gruntownie przetestowaną implementację przechodzącą benchmarki.

W blogu premierowym Anthropic podkreślało, że Opus 5 jest znacznie mocniejszy w weryfikowaniu własnej pracy i cierpliwym iterowaniu, aż osiągnie cel. To dziś jedna z najważniejszych rzeczy dla agentów: powiedzieć „nie kończ, dopóki nie spełnisz warunku” i jasno zdefiniować, jak sprawdzić, czy zadanie faktycznie jest zrobione. Przy kryteriach twardych może to być „10 na 10 punktów spełnione”, a przy miękkich — pętla, w której podagenci spierają się i debatują, aż osiągną konsensus. Sedno: żeby AI potrafiło zaprojektować test „czy to już gotowe/dobre” i iterować, aż test przejdzie.

Z moich testów wynika jednak coś jeszcze: model ma znaczenie, ale jeszcze bardziej liczy się to, jak go instruujesz i jak podajesz kontekst. Warto szukać najlepszego modelu — ale najlepszego pod konkretne zastosowanie — a potem nauczyć się z nim rozmawiać.

Test 3: montaż krótkiego wideo

Poleciłem: „zbuduj 10-sekundowe, dynamicznie zmontowane, wiralowe wideo zapowiadające nasze wydarzenie AI Live” i pozwoliłem przeszukać cały komputer w poszukiwaniu potrzebnych informacji.

Opus zrobił dwie wersje — pionową i poziomą. Efekt: nieźle, ale nie rewelacyjnie, trochę „komputerowo”, niezbyt profesjonalnie — przy 10 sekundach materiału trudno o więcej. Zajęło to 40 minut i kosztowało 11,19 $.

Fable zrobił jedną wersję, z innymi efektami i muzyką. Część danych była nieaktualna — ale to nie wina modelu, tylko mojego nieodświeżonego kontekstu. Gdyby model był lepszy w weryfikacji — gdyby zajrzał głębiej do wątków w mojej społeczności, do postów na LinkedIn — pewnie wyłapałby, że część prelegentów ostatecznie nie wystąpiła. Modele mają wyraźnie różny gust: przy identycznym promptcie Opus zrobił dwa warianty, Fable jeden. Fable kosztował około 7 $ i 7 minut 49 sekund — mniej więcej połowę kosztu Opusa, choć Opus zrobił dwa razy więcej materiału.

Test 4: landing page programu certyfikacyjnego

Poprosiłem o jednostronicowy landing dla programu „certyfikowanego konsultanta AI”, z wolną ręką i poleceniem „zrób jak najbardziej efektownie”.

Wersja Opusa: nagłówek „Nie kolejny kurs AI — poświadczenie, od którego kupuje rynek MŚP”, dynamiczny element 3D w tle, wyciągnięte moje logo, przycisk „aplikuj”, nawigacja do sekcji, dziewięć filarów. Wyglądało trochę generycznie, ale trzymało brand guidelines — kolory, logo, przyciski — a wszystkie informacje były zgodne z moimi nagraniami spotkań i wewnętrznymi dokumentami. Bardzo rozwlekłe, ale bardzo dokładne.

Wersja Fable: bardzo podobna, z ładną kartą (mamy realnie taką w projekcie), tym samym nagłówkiem, dziewięcioma filarami, „54 przeanalizowane ogłoszenia o pracę”, „50 miejsc założycielskich”, ładną animacją. Też pobrała logo i brand guidelines. Obie wymagałyby ręcznych poprawek i żadna nie wygrywała jednoznacznie.

Koszt: Fable 20,50 $ i 22 minuty, Opus 35,83 $ i prawie godzina. Tu Fable był tańszy, szybszy i może odrobinę lepszy. Wstępny wniosek: Fable wciąż wygrywa na polu kreatywności i designu, a Opus 5 ma dziś przewagę w faktycznym podążaniu za instrukcją i weryfikacji — i w większości przypadków będzie tańszy.

Test 5: post i karuzela na LinkedIn

Chciałem post na LinkedIn z karuzelą, świadomie podnosząc stawkę: gdyby wyszło coś oczywiście „wygenerowanego przez AI”, byłoby źle. Temat wybierał sam model.

Opus napisał o tym, że „AI dramatycznie poprawiło się w kodowaniu, a zaufanie do niego spadło”. Karuzela — spójna z brandingiem, ale trochę „meh”, niezbyt profesjonalna. Post miał realne statystyki i odwołania do karuzeli.

Fable użył innego stylu karuzeli — bardziej „tweetowego” — który podobał mi się znacznie bardziej: „Agenty AI weszły do mainstreamu. Zaufanie nie”. Research podobny, wnioski zbliżone, sama treść postów porównywalna. Fable dał mi lepszy deliverable. To zresztą przykład zadania, w którym nawet Opus 5 to przesada — dobry post napisze i Sonnet 4.5.

Koszt: Fable 6,17 $ i około 7,5 minuty, Opus 8,22 $ i dłużej. Znowu Fable taniej i szybciej — co jest zaskakujące, bo skoro token Opusa kosztuje o połowę mniej, to gdyby oba zużyły tyle samo tokenów, Opus wyszedłby dokładnie o połowę taniej. Skoro wyszedł drożej, znaczy to, że był znacznie mniej oszczędny w tokenach. To trochę niepokojące.

Test 6: analiza społeczności i pomysł na produkt

Poleciłem przejść na mój kanał YouTube, wyciągnąć komentarze, przeszukać wątki w mojej społeczności i ustalić, co mówi moja widownia, jakie ma bolączki, jaki jeden produkt najlepiej je rozwiąże i jaki jeden film najbardziej trafi w tę widownię.

Opus przeanalizował około 2200 komentarzy z YouTube i 480 postów ze społeczności. Wygenerował HTML (font trochę „maszynopisowy”, tani wizualnie, choć zgodny z brandingiem) z uszeregowanymi bolączkami: wycena i zakres projektu, udowodnienie, że automatyzacja zadziałała, i inne. Produkt numer jeden: „offer engine” — pakiet skilla do Claude Code plus szablony, który z rozmowy dyskoveryjnej robi wycenioną ofertę z warstwą pomiaru. Najlepszy film: „Sprzedałem system AI prawdziwej firmie w 7 dni. Prawdziwy klient, prawdziwa faktura”.

Fable przejrzał mniej postów. Bolączki podobne, choć nie identyczne. Produkt numer jeden: „AI consultant kit” — kompletny system dostarczania dla klientów, który przeprowadza członka od „umiem budować automatyzacje” do „firma mi zapłaciła”. Film: „Pracowałem jako konsultant AI dla prawdziwej firmy — prawdziwy klient, prawdziwe liczby”. Wyniki bardzo zbieżne, więc pytanie brzmi, któremu bardziej ufasz i który przekopał więcej danych.

Koszt: Fable 10,60 $ i prawie 11 minut, Opus 8,34 $ i 20 minut. Znowu Opus mniej wydajny czasowo, ale w sumie tańszy.

Test 7: konspekt wideo i prezentacja

Zadanie: stwórz konspekt filmu na YouTube i prezentację w stylu Excalidraw, przeszukując poprzednie posty z LinkedIn, posty ze społeczności, filmy i sesje Q&A z AI Live. Dodatkowa instrukcja: jesteś product managerem zarządzającym agentami — sam nic nie robisz, tylko delegujesz i recenzujesz.

(Informacja dodatkowa: oba przebiegi ruszały w całkowicie „świeżym” katalogu, bez dostępu do normalnie działającego środowiska autora — to tłumaczy, dlaczego jeden model lepiej odnalazł jego skille i style.)

Opus zrobił konspekt „context engineering dla agentów” (cold open, co się zmieniło, tryby awarii kontekstu, pisanie/selekcja/kompresja/izolacja) i slajdy z hasłem „Twój agent AI nie jest głupi — głupi jest twój kontekst”. Prezentacja jednak nie wyglądała tak markowo jak zwykle jego prezentacje.

Fable stworzył konspekt, slajdy i notatki — bardzo podobny temat i struktura, ale efekt znacznie bliższy temu, co autor zwykle robi: 29 slajdów, mocna historia, ładne wizualizacje („context rot — gubi się w środku”). Zdaniem autora Fable lepiej odnalazł właściwe skille w innym projekcie i zrobił wyraźnie lepszą prezentację.

Koszt: Fable około 8 minut i prawie 41 $, Opus godzina 15 minut i 33 $. Mimo wyższej ceny autor uznał, że Fable wygrywa — był bardziej wydajny tokenowo i szybszy.

Test 8: computer use i przypadkowa lekcja o niedeterminizmie

Chciałem pokazać „computer use” — sterowanie przeglądarką. Przez pomyłkę oba przebiegi puściłem na Opusie (jeden opisałem jako Fable). I dobrze, bo to najlepiej ilustruje pointę.

(Informacja dodatkowa: „computer use” to zdolność modelu do sterowania komputerem/przeglądarką — tu przez Playwright CLI.)

Zadanie: wejdź w Google, zagraj w grę w węża, rozegraj dokładnie pięć partii, zrób zrzut wyniku każdej i podaj średnią. Ten sam prompt, ten sam model (Opus), dwa uruchomienia — drastycznie różne wyniki. Pierwszy przebieg trwał prawie 2 godziny, kosztował 18 $ i wymknął się spod kontroli: zamiast pięciu partii model rozegrał ich około 30, seriami po pięć, próbując „się maksymalizować”, i wyszła średnia 63. Drugi przebieg: godzina 10 minut, 10 $, grzecznie pięć partii i znacznie lepsze wyniki. Dobitne przypomnienie, że modele są całkowicie niedeterministyczne — nie wiadomo z góry, co zrobią.

Test 9: symulator konstrukcji

Ostatnie, dłuższe zadanie: symulator, w którym widać budynki i pojazdy, można je testować pod różną pogodą, dokładać obciążenia i projektować własne konstrukcje.

Pierwsza wersja: dużo się dzieje, trochę przytłaczający interfejs. Widać węzły i belki, można dokładać ciężary, sprawdzać, co przechodzi, a co nie, dodawać śnieg i deszcz, regulować grawitację i podmuchy — elementy zmieniają kolor pod nadmiernym obciążeniem. Jako ni-inżynier autor nie ręczy za dokładność fizyczną, ale jako narzędzie do wychwytywania miejsc pod naciskiem — sensowne. UI przytłaczający, choć autor o to nie prosił.

Druga wersja: znacznie przyjaźniejsza, prostsza, choć wyglądająca bardziej „AI-owo”, trochę jak stare oprogramowanie. Łatwo dodać wiatr, śnieg czy trzęsienie ziemi, przełączyć się na wieżowiec, szkołę albo pojazd, prosto zaprojektować własną konstrukcję z węzłów i połączeń.

Zaskoczenie: druga, przyjaźniejsza wersja to Opus, a pierwsza, przeładowana — Fable. Koszt: Fable zaledwie 7 minut i 73 $ (pokazuje, jak szybko Fable potrafi „przepalić” sesję, jeśli nie uważasz), Opus 2 godziny 26 minut i 112 $. Opus najwyraźniej wpadł w inną pętlę albo inaczej zinterpretował kryteria weryfikacji i puścił znacznie więcej podagentów oraz stress-testów. Być może to właśnie owo „Opus jest mocniejszy w cierpliwym weryfikowaniu i iterowaniu” w praktyce.

Co ważne: Fable z pewnością mógł zbudować coś dużo lepszego — widziałem, jak robi rzeczy o wiele bardziej imponujące — ale z jakiegoś powodu po prostu uznał, że skończył. To kolejne przypomnienie, że modele są niedeterministyczne, a Opus 5 interpretuje polecenia inaczej niż Opus 4.8 i inaczej niż Fable 5.

Zbiorcze wyniki i wnioski końcowe

Dlatego pierwsze, co zrobiłem po dostaniu Opusa 5, to puściłem swoje skille i zwykłe workflow — żeby poczuć model. Benchmarki traktuję z rezerwą, bo dużo bardziej liczy się, jak z modelem rozmawiasz, jak go promptujesz pod weryfikację i jak „się czuje” w pracy.

Zbiorczo (przez pomyłkę wyszło 10 przebiegów na Opusie i 8 na Fable zamiast po 9): Opus wydał więcej, co znaczy, że był mniej oszczędny tokenowo — bo per token jest o połowę tańszy od Fable, więc wyższy koszt oznacza znacznie większe zużycie tokenów. Łączny output: 2 mln tokenów dla Opusa i 832 tys. dla Fable. Aktywny czas Opusa: 630 minut, czyli średnio godzina na sesję; Fable średnio około 25 minut. Rozkład kosztów na obu był podobny — dużo przypada na odczyt z cache, potem zapis do cache, output i minimalny input, bo zadania polegały głównie na generowaniu.

Rekomendacja: wejdź w Opusa 5, puść swoje skille, zrób pętle weryfikacyjne i sprawdź, czy pasuje ci jako orkiestrator. Ja wciąż wolę w tej roli Fable — mówię mu wprost, że nie ma sam pisać ani wykonywać kodu, tylko instruować Opusa. To potężnie oszczędza limit sesji: Fable może delegować godzinami, a i tak nie dobije nawet do 300–400 tys. tokenów kontekstu, bo tylko rozdziela pracę.

I najważniejsze: wielu z nas nie docenia, jak potężny jest już starszy model Sonnet — świetnie nadaje się do większości codziennej pracy umysłowej. Czasem i Opus 5, i Fable 5 to przerost formy. Dobieraj inteligencję modelu do inteligencji wymaganej przez zadanie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Nie ufaj benchmarkom — testuj na własnych workflow

Na czym polega: Wyniki na benchmarkach (Frontier Bench, Cursor Bench itp.) mogą sugerować, że tańszy model bije droższy, ale liczy się dopiero to, jak model radzi sobie w twoich realnych zadaniach.

Jak stosować: Po każdej premierze modelu przepuść przez niego swój stały zestaw zadań — te same skille, prompty i procesy, które robisz na co dzień — i oceniaj po efektach, nie po tabelkach.

Na co uważać: Benchmark mierzy uśrednione, wystandaryzowane zadania. Twój przypadek (kontekst, skille, styl promptowania) może dawać zupełnie inne wnioski niż liderboard.

2.Opus 5 wygrywa na „podążaniu za instrukcją” i weryfikacji

Na czym polega: W zadaniach technicznych (szukanie błędów, dokładność implementacji) Opus częściej trafiał w cel i przechodził testy — w jednym teście 93/95 wobec 66/95 dla Fable — i bywał przy tym tańszy.

Jak stosować: Do pracy, gdzie liczy się poprawność i trzymanie się wymagań (kod, analizy, dokładne dostarczanie danych), stawiaj na Opusa 5.

Na co uważać: To ustalenia z pojedynczych przebiegów i częściowo subiektywne. Przewaga nie jest gwarantowana — na innym repo czy zadaniu układ może się odwrócić.

3.Fable 5 wygrywa na kreatywności i designie

Na czym polega: Przy landingach, karuzelach i prezentacjach Fable dawał ładniejsze, bardziej „markowe” i lepiej zaprojektowane efekty, bliższe temu, co autor faktycznie chce publikować.

Jak stosować: Do materiałów wizualnych i kreatywnych — slajdy, grafiki, layouty, treści budujące markę — sięgaj po Fable.

Na co uważać: Fable bywa niedeterministyczny „w dół” — czasem uznaje, że skończył, choć stać go na dużo więcej. Jeśli efekt jest zbyt płytki, poproś wprost o głębszą iterację.

4.Niższa cena za token nie znaczy niższego kosztu sesji

Na czym polega: Opus jest o połowę tańszy za token niż Fable, ale bywał droższy w sesji, bo zużywał znacznie więcej tokenów (2 mln vs 832 tys. w sumie).

Jak stosować: Budżetuj koszt na podstawie realnego zużycia tokenów w twoich zadaniach, a nie samej ceny cennikowej. Mierz koszt całej sesji, nie stawkę za milion tokenów.

Na co uważać: „Tańszy model” potrafi wyjść drożej właśnie przez gadatliwość i długie pętle. Śledź zużycie tokenów, a nie tylko cennik.

5.Weryfikacja i warunek zakończenia to sedno dobrego agenta

Na czym polega: Największą poprawą w Opusie 5 jest cierpliwe sprawdzanie własnej pracy i iterowanie aż do celu. Model działa najlepiej, gdy ma jasny warunek „gotowe”.

Jak stosować: W promptach definiuj mierzalny warunek stopu — np. „10/10 kryteriów spełnione” — albo dla zadań miękkich każ podagentom debatować, aż osiągną konsensus. Daj modelowi sposób, by sam sprawdził, czy skończył.

Na co uważać: Zbyt agresywna weryfikacja potrafi wpuścić model w kosztowną, wielogodzinną pętlę (patrz test symulatora: 2,5 godziny i 112 $). Ograniczaj też liczbę iteracji i budżet.

6.Modele są niedeterministyczne — nawet ten sam model, ten sam prompt

Na czym polega: Dwa uruchomienia identycznego promptu na Opusie dały skrajnie różne wyniki: raz grzeczne pięć partii za 10 $, raz 30 partii za 18 $ i prawie 2 godziny.

Jak stosować: Przy ważnych zadaniach rób kilka przebiegów i wybieraj najlepszy; nie wyciągaj wniosków o modelu z jednego uruchomienia.

Na co uważać: Nie zakładaj powtarzalności. Dla zadań krytycznych dodaj twarde limity (liczba akcji, czas, budżet) i kontrolę wyniku, bo model potrafi „pójść w swoją stronę”.

7.Jak instruujesz i podajesz kontekst liczy się bardziej niż wybór modelu

Na czym polega: Autor wielokrotnie podkreśla, że efekt zależy głównie od jakości promptu i kontekstu, a nie od tego, który z topowych modeli wybrałeś.

Jak stosować: Zainwestuj w dobre skille, aktualny kontekst i precyzyjne prompty. To da większy skok jakości niż przeskok między dwoma flagowcami.

Na co uważać: Nieaktualny kontekst zatruwa wynik (w teście wideo model użył przestarzałych danych). Utrzymuj źródła kontekstu w porządku i każ modelowi weryfikować fakty.

8.Fable jako orkiestrator oszczędza limit sesji

Na czym polega: Ustawienie „nie pisz i nie wykonuj kodu, tylko instruuj Opusa” sprawia, że Fable tylko deleguje — potrafi pracować godzinami, nie dobijając nawet do 300–400 tys. tokenów kontekstu.

Jak stosować: Do długich, złożonych zadań użyj mocnego modelu jako „product managera” delegującego pracę wykonawcom (np. Opusowi), by nie przepalać jego okna kontekstu.

Na co uważać: Delegowanie dokłada warstwę koordynacji i punktów, w których może zgubić się kontekst. Pilnuj, by orkiestrator faktycznie tylko zarządzał, a nie wykonywał zadań sam.

9.Dobieraj inteligencję modelu do trudności zadania

Na czym polega: Do wielu prac (np. post na LinkedIn) i Opus 5, i Fable 5 to przerost formy — dobry efekt da nawet starszy Sonnet 4.5, znacznie taniej.

Jak stosować: Dla powtarzalnej, prostszej pracy umysłowej domyślnie sięgaj po tańszy, starszy model; flagowce rezerwuj na zadania naprawdę tego wymagające.

Na co uważać: Nie przepłacaj z automatu za najnowszy model. Ale przy zadaniach wymagających dokładności czy złożonego rozumowania oszczędność na modelu może kosztować jakością.

10.Utrzymuj stały harness, żeby porównywać modele uczciwie

Na czym polega: Autor prowadził testy w tym samym Claude Code, więc jedyną zmienną był model — dzięki temu różnice w koszcie, czasie i tokenach można przypisać modelowi.

Jak stosować: Porównując modele, zamroź całą resztę (narzędzia, prompt, dane, środowisko) i zmieniaj tylko jedną rzecz naraz.

Na co uważać: Świeże, „puste” środowisko potrafi zaniżyć wynik modelu, który nie ma dostępu do twoich skilli i stylów (jak w teście prezentacji). Zadbaj, by porównywane modele miały dostęp do tego samego kontekstu.