O czym jest ten film
- Autor przedstawia model Fable 5 firmy Anthropic jako najmocniejszy, jakiego dotąd używał, ale też bardzo drogi i dostępny tylko czasowo w ramach promocji.
- Streszcza oficjalną dokumentację „best practices” do sześciu praktycznych nawyków, których warto trzymać się przy promptowaniu Fable 5.
- Nawyk 1: podawaj model powód i kontekst działania — Fable działa lepiej, gdy rozumie Twoją intencję.
- Nawyk 2: stosuj „negatywne promptowanie” — wyraźnie mów, czego model ma NIE robić.
- Nawyk 3: pozwól modelowi działać, gdy ma już dość informacji — powstrzymaj nadmierne planowanie i dobieraj poziom „effort” do zadania.
- Nawyk 4 (zdaniem autora najważniejszy): każ modelowi udowodnić wynik — wbuduj pętle weryfikacji, żeby raportował tylko to, co potrafi wykazać dowodami.
- Nawyk 5 (specyficzny dla Fable): nie proś Fable o pokazanie własnego rozumowania — może to uruchomić mechanizm bezpieczeństwa i przekierować zadanie do słabszego modelu.
- Nawyk 6: mów mniej, nie więcej — dla tak inteligentnego modelu krótka instrukcja steruje równie dobrze jak długa lista reguł.
- Autor wyjaśnia mechanizm „handoffu”: Fable przy podejrzeniu ryzykownej intencji cicho przekierowuje zapytanie do Opusa 4.8.
- Praktyczna rada nadrzędna: nie używaj Fable 5 do wszystkiego — realnie potrzebujesz go tylko w 5–15% przypadków, resztę oddaj tańszym modelom.
(Informacja dodatkowa: nazwy modeli w tym materiale — „Fable 5”, „Opus 4.8”, „Mythos 5” — to nazewnictwo używane przez autora w nagraniu; „Enthropic” w transkrypcji to firma Anthropic).
Redakcyjne tłumaczenie
Fable 5 wraca — i robi wrażenie
Doczekaliśmy się. Fable 5 w końcu do nas wraca i jest to naprawdę znakomity model. Bez dwóch zdań najmocniejszy, jakiego kiedykolwiek używałem. Budowałem na nim rzeczy w rodzaju mojego „drugiego mózgu” czy własnego systemu operacyjnego opartego na AI, więc siłą rzeczy sporo przy nim spędziłem czasu. Cały czas próbowałem ustalić, jak używać go najlepiej — tak, żeby robić to efektywnie i nie płacić za tokeny bez powodu.
Przejrzałem, co ludzie piszą na X, posłuchałem inżynierów z Anthropic, a także przeczytałem całą dokumentację o najlepszych praktykach promptowania Claude Fable 5. To, co dziś zrobiłem, to zdestylowanie tego wszystkiego do sześciu najprostszych i najskuteczniejszych rzeczy, które powinieneś robić już teraz przy promptowaniu Fable 5, żeby wycisnąć z niego maksimum.
Nie jest to jednak tani model. Kosztuje dwa razy tyle co Opus: 10 dolarów za milion tokenów wejściowych i 50 dolarów za milion tokenów wyjściowych. Do tego nie zawsze będzie dostępny w ramach Twojego planu Claude. Anthropic nazywa to okresem promocyjnym — możesz wykorzystać do 50% swoich tygodniowych limitów na Fable 5 bez dodatkowych opłat. Po przekroczeniu tego progu trzeba przejść na kredyty rozliczane od użycia. Niestety okres promocyjny kończy się 7 lipca, więc mamy jakieś sześć dni, a część z nich przypada na weekend Święta Niepodległości. No cóż.
Model działa praktycznie wszędzie: w aplikacji desktopowej Claude, w VS Code, w narzędziu do kodowania — gdzie tylko chcesz. Właśnie dostałem komunikat, że Fable 5 wrócił, i po wejściu w /model widać, że mam do niego dostęp.
Czym Fable 5 różni się w praktyce
Pierwsza rzecz do zrozumienia jest taka, że Fable 5 jest zbudowany trochę inaczej niż Opus czy GPT — są rzeczy, które robi wyjątkowo dobrze. Lepiej niż starsze modele podąża za krótkimi, jasnymi poleceniami, bo po prostu lepiej rozumuje. Kiedy pobawisz się nim chwilę, masz wrażenie, że gdy prosisz go o coś, on faktycznie wie, o co Ci chodzi, i rozumie to trochę głębiej.
Poniżej opisuję sześć nawyków. Przy każdym zaznaczam, czy dotyczy dowolnego modelu, czy jest specyficzny dla Fable.
Nawyk 1: Daj mu „dlaczego” (dowolny model)
Podawaj kontekst tego, po co coś robisz. Anthropic mówi, że Fable radzi sobie lepiej, gdy rozumie Twoją intencję. Kontekst pozwala mu połączyć zadanie z właściwymi informacjami, zamiast zgadywać, co miałeś na myśli.
Zamiast powiedzieć: „Napisz mi e-mail do klienta w sprawie opóźnienia”, powiedz raczej: „Pracuję nad większym zadaniem, oto dla kogo to jest i czego ta osoba potrzebuje — mając to na uwadze, pomóż mi napisać e-mail do tego klienta o opóźnieniu”. A jeśli masz odpowiednio ustawiony swój „drugi mózg” i cały system AI, taki prompt skłoni model również do przejrzenia konkretnych plików z kontekstem, żeby upewnić się, że ma właściwe informacje i że efekt będzie bardziej dopasowany.
Nawyk 2: Promptuj negatywnie — mów, czego NIE robić (dowolny model)
To rzecz, która ogólnie lepiej działa dla wszystkich modeli. Pomyśl o tym tak: AI jest trenowane na ogromnej ilości danych i w swej istocie próbuje przewidzieć kolejne, najbardziej sensowne słowo. Czasem próbuje być kreatywne i robi rzeczy, o które nie prosiłeś. Bywa, że to dobrze, ale bardzo często nie. Dlatego wyjaśniaj, czego robić nie wolno.
Gdy przejrzysz stronę o promptowaniu Fable 5, zobaczysz, że sama dokumentacja tak robi: „Gdy masz na czym działać — działaj. Nie rób tego a tamtego. Jeśli ważysz jakiś wybór, wydaj rekomendację, ale nie rób tego”. Inny przykład: „Nie dodawaj funkcji. Nie rób tego. Nie rób tamtego. Zrób najprostszą rzecz, która dobrze zadziała”.
Lubię to porównywać do tłumaczenia zadania stażyście — powiedziałbyś mu wprost, czego nie robić, bo jeszcze nie zna procesu. Zamiast więc mówić: „Spójrz na ten problem i się nim zajmij”, powiedz: „Kiedy opisuję problem albo zadaję pytanie, oczekiwanym rezultatem jest Twoja ocena. Zaraportuj, co znalazłeś, i zatrzymaj się. Niczego nie naprawiaj, nie wysyłaj, nie edytuj i nie usuwaj, dopóki nie powiem: działaj”.
Mam wrażenie, że modele trochę się pod tym względem zmieniły. Kiedyś uważałem, że negatywne promptowanie nie działa tak dobrze jak samo bardzo precyzyjne opisanie, co ma robić. Ostatnio jednak im więcej promptuję negatywnie, tym lepsze efekty widzę.
Nawyk 3: Pozwól mu działać, gdy ma już dość (dowolny model)
Powstrzymaj nadmierne planowanie. Sam nie używam już zbyt często trybu planowania w narzędziu do kodowania. Wiem, że kiedyś zawsze powtarzałem: zaczynaj od trybu planu — ale już tego nie robię. Zamiast tego mam własny „tryb planu”, przez który każę modelowi przejść, aż będzie gotowy działać.
Zamiast mówić: „Zbadaj wszystko i zrób pełny plan, zanim cokolwiek zrobisz”, powiedz raczej: „Kiedy masz dość informacji, żeby działać — działaj”. To zresztą mniej więcej pierwszy przykład z dokumentacji Fable 5, bo pojedyncze żądania przy trudnych zadaniach mogą na wyższych poziomach wysiłku trwać wiele minut — zwłaszcza gdy trzeba zebrać kontekst, coś zbudować i samodzielnie zweryfikować.
Ważnym elementem jest tu myślenie o poziomach wysiłku (effort): masz niski, średni, wysoki i ekstra wysoki. Trzeba dopasowywać poziom do zadania. Anthropic zaleca: wysoki jako domyślny dla większości zadań, ekstra wysoki dla najbardziej wymagających zadań, a średni lub niski do rutynowej roboty.
Co ciekawe, gdy porównasz Fable 5 z Opusem 4.8 na różnych poziomach rozumowania i przy różnym koszcie, dochodzisz do obszaru, gdzie wyniki są zbliżone — ale Fable 5 na niskim poziomie, choć podobny do Opusa 4.8 na ekstra wysokim i maksymalnym, jest tańszy. Dlatego eksperymentowanie z poziomami wysiłku i wyczucie, kiedy którego użyć, to bardzo ważna umiejętność — obok ogólnego rozumienia, do jakich zadań który model.
Bo jeśli używasz Fable 5 do wszystkiego, to niemal na pewno przesada — zwłaszcza gdy wchodzisz w rozliczanie kredytami. Realnie po Fable 5 powinieneś sięgać jedynie w jakichś 5–15% przypadków.
Nawyk 4: Każ mu to udowodnić (dowolny model)
To moim zdaniem prawdopodobnie najważniejszy punkt. Jak wspominałem, czasem modele mówią, że skończyły, choć wcale nie skończyły. Albo skończyły, ale niczego nie zweryfikowały. Chodzi o to, że gdybyś dał pracę człowiekowi i wrócił z jakimś wynikiem, i tak musiałbyś go sprawdzić. Chcesz dojść do momentu, w którym ufasz temu modelowi na tyle — bo wbudowałeś w niego pętle weryfikacji — że gdy coś Ci oddaje, wciąż warto to sprawdzić, ale nie masz już takiego przymusu, bo wiesz, że sam sprawdził swoją pracę dwa, trzy, cztery, może pięć razy i przetestował, że wszystko działa jak należy.
Zamiast po prostu pytać: „Czy to gotowe i czy działa?”, powiedz: „Zanim powiesz, że coś jest gotowe, wskaż wynik, który to udowadnia. Raportuj tylko pracę, na którą możesz pokazać dowody. Jeśli czegoś nie zweryfikowałeś, powiedz to wprost, zamiast zgadywać”. To warto wpleść we wszystkie swoje skille, agenty i pliki CLAUDE.md, a nie doklejać na końcu każdego promptu.
Nawyk 5: Przestań prosić Fable o pokazanie rozumowania (specyficzne dla Fable)
Stały nakaz „wyjaśnij swoje rozumowanie”, zwłaszcza w prompcie systemowym, może wywołać odmowę i przekazać Twoje zadanie do Opusa 4.8.
Wyjaśnię to szerzej na końcu, ale w skrócie: ponieważ przy Fable 5 istnieją obawy o jailbreaking, a jest to „słabszy” model względem Mythos 5, trzeba uważać, żeby nie wyzwolić przekierowania do Opusa. W Fable wbudowano bariery bezpieczeństwa, które kierują zapytanie do mniej zdolnego modelu, takiego jak Opus, jeśli mechanizm uzna, że intencja żądania może być złośliwa. Z jakiegoś powodu próba zmuszenia Fable, żeby pokazał swoje rozumowanie, może zdegradować Cię właśnie do Opusa 4.8. Dlatego jest to reguła promptowania specyficzna dla Fable.
Nawyk 6: Mów mniej, nie więcej (specyficzne dla Fable)
Brzmi to trochę nieintuicyjnie, bo zwykle sądziliśmy, że im więcej kontekstu dasz modelowi, tym lepiej. Ale Fable jest teraz tak inteligentny — zwłaszcza gdy osadzisz go w dobrym środowisku z kontekstem, narzędziami i skillami — że krótka instrukcja steruje nim równie dobrze jak wypisywanie po kolei wszystkich reguł.
To nie jest sprzeczne z nawykiem pierwszym (dodaj „dlaczego”). Dodanie kontekstu nadal nie oznacza rozdmuchiwania wszystkiego. Zamiast pisać: „reguła pierwsza — bądź zwięzły, reguła druga — rób to, reguła trzecia — rób tamto”, powiedz raczej: „Zacznij od rezultatu. Nie komplikuj i przerywaj tylko wtedy, gdy praca naprawdę mnie wymaga”. Tak właśnie zaczynasz wplatać wszystkie te triki w swoje pliki systemowe, pliki pamięci, pliki CLAUDE.md, skille i prompty.
Co się dzieje, gdy Fable przekazuje zadanie Opusowi
Na koniec wróćmy do tego, o czym wspomniałem: co się dzieje, gdy Fable przekazuje zadanie Opusowi 4.8 (albo jakiemukolwiek modelowi, do którego będzie kierować w przyszłości). Fable uruchamia szybką kontrolę bezpieczeństwa, zanim odpowie na Twoje żądanie. Jeśli uzna, że zapytanie mieści się w pewnym „koszyku” — coś związanego z hakowaniem, niebezpieczną biologią albo proszeniem modelu o ujawnienie własnego prywatnego rozumowania — może przekazać je dalej.
Gdy tak się dzieje, nie zobaczysz tego wprost: nastąpi ciche przekierowanie do Opusa. Jeśli budujesz na API, odpowiedź wskaże, że to był Opus, ale poza tym możesz tego nie zauważyć. Na szczęście trafia to do Opusa 4.8, więc płacisz mniej niż za Fable — inaczej byłoby to dość przykre. Po prostu miej to na uwadze. Możesz tego uniknąć, stosując wspomniane techniki, a także nie prosząc modelu o rzeczy wyraźnie złośliwe lub podejrzane.
Zajrzyj do tej dokumentacji i przeczytaj ją — jest w niej mnóstwo złota. To by było na tyle. Jeśli chcesz dowiedzieć się więcej o pętlach agentowych i weryfikacji, o których mówiłem, sprawdź osobny materiał, w którym to wyjaśniam na przykładach — sądzę, że ta technika sprawdzi się z Fable 5 znakomicie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Podawaj „dlaczego”, a nie tylko „co”
Na czym polega: Model działa trafniej, gdy zna intencję i odbiorcę zadania — kontekst pozwala mu połączyć polecenie z właściwymi informacjami, zamiast zgadywać.
Jak stosować: Do każdego istotnego polecenia dołącz jedno–dwa zdania o celu i adresacie („robię to w ramach większego zadania X, dla klienta Y, który potrzebuje Z”). W dobrze ustawionym środowisku skłoni to model do sięgnięcia po właściwe pliki kontekstowe.
Na co uważać: „Dlaczego” to nie zaproszenie do rozwlekłości. Podaj intencję zwięźle — nie myl kontekstu z zasypywaniem modelu szczegółami (patrz punkt 8).
2.Promptuj negatywnie — mów, czego NIE robić
Na czym polega: Model przewiduje kolejne słowa i bywa nadgorliwie kreatywny. Wyraźne granice („nie edytuj, nie wysyłaj, nie usuwaj”) ograniczają niechciane działania.
Jak stosować: Traktuj model jak stażystę: wypisz konkretne rzeczy do nierobienia. Np. „Deliverable to Twoja ocena. Zaraportuj i zatrzymaj się. Niczego nie zmieniaj, dopóki nie powiem: działaj”.
Na co uważać: Autor zauważa, że skuteczność negatywnego promptowania rosła z czasem — jeśli kiedyś Ci nie działało, przetestuj ponownie. Nie zastępuj nim jednak pozytywnego opisu celu; oba się uzupełniają.
3.Pozwól modelowi działać, gdy ma już dość informacji
Na czym polega: Domyślnie model potrafi nadmiernie planować i badać, co przy trudnych zadaniach na wysokim wysiłku wydłuża pracę o minuty.
Jak stosować: Zamiast „zbadaj wszystko i zrób pełny plan”, napisz „gdy masz dość informacji, żeby działać — działaj”. Autor porzucił rutynowe zaczynanie od trybu planu na rzecz własnej, sterowanej sekwencji.
Na co uważać: To kompromis — przy zadaniach naprawdę ryzykownych lub nieodwracalnych warto zachować etap planowania i akceptacji przed działaniem.
4.Dobieraj poziom wysiłku (effort) do zadania
Na czym polega: Poziomy niski/średni/wysoki/ekstra wysoki różnią się jakością i kosztem. Wysoki jest sensownym domyślnym, ekstra wysoki dla najtrudniejszych zadań, średni/niski dla rutyny.
Jak stosować: Świadomie schodź w dół tam, gdzie nie potrzebujesz maksimum — Fable 5 na niskim potrafi dorównać droższym konfiguracjom Opusa przy niższym koszcie. Wyrób sobie wyczucie, kiedy który poziom.
Na co uważać: Zbyt niski poziom przy zadaniu wymagającym rozumowania da słabszy efekt — to eksperyment, nie sztywna reguła. Testuj na własnych zadaniach.
5.Każ modelowi udowodnić wynik (pętle weryfikacji)
Na czym polega: Modele bywają przekonane, że skończyły, choć nie zweryfikowały pracy. Wbudowane pętle „udowodnij to” podnoszą zaufanie do wyniku.
Jak stosować: Dodawaj instrukcję: „Zanim powiesz, że gotowe, wskaż dowód. Raportuj tylko to, co potrafisz wykazać. Jeśli czegoś nie zweryfikowałeś — powiedz wprost”. Wpleć to w skille, agenty i pliki CLAUDE.md, zamiast doklejać do każdego promptu.
Na co uważać: Weryfikacja modelu nie zwalnia Cię z własnej kontroli — nadal sprawdzaj wyniki, po prostu rzadziej i z większą pewnością.
6.Nie zawsze potrzebujesz Fable 5 — używaj go oszczędnie
Na czym polega: Fable 5 jest drogi (dwukrotność Opusa) i po przekroczeniu 50% tygodniowego limitu przechodzi na płatne kredyty. Realnie potrzebujesz go w 5–15% zadań.
Jak stosować: Ustal, które zadania faktycznie wymagają najmocniejszego modelu, a resztę oddaj tańszym. Pamiętaj o krótkim oknie promocji (koniec 7 lipca) przy planowaniu testów.
Na co uważać: Ceny i warunki promocji są punktowe w czasie — zweryfikuj aktualny cennik i limity, zanim się na nich oprzesz. (Informacja dodatkowa: podane stawki i daty pochodzą z nagrania z 1 lipca 2026 i mogły się zmienić).
7.Nie proś Fable o pokazywanie własnego rozumowania
Na czym polega: Stały nakaz „wyjaśnij swoje rozumowanie”, szczególnie w prompcie systemowym, może wyzwolić odmowę i ciche przekierowanie zadania do słabszego modelu (Opus 4.8).
Jak stosować: Usuń z promptów systemowych żądania ujawniania toku rozumowania. Jeśli potrzebujesz uzasadnienia, proś o wynik i dowody (punkt 5), a nie o „prywatne” rozumowanie modelu.
Na co uważać: To reguła specyficzna dla Fable, wynikająca z barier bezpieczeństwa — nie przenoś jej bezmyślnie na inne modele, gdzie prośba o rozumowanie bywa użyteczna.
8.Mów mniej — krótka instrukcja steruje równie dobrze
Na czym polega: Przy tak zdolnym modelu, osadzonym w środowisku z kontekstem i narzędziami, zwięzłe polecenie prowadzi tak samo skutecznie jak długa lista reguł.
Jak stosować: Zamiast numerowanej listy oczywistości pisz jedną celną instrukcję: „Zacznij od rezultatu, nie komplikuj, przerywaj tylko gdy praca naprawdę mnie wymaga”. Wplataj to w pliki systemowe i pamięci.
Na co uważać: „Mniej” to nie sprzeczność z punktem 1 — nadal podawaj kluczowe „dlaczego”. Chodzi o wycięcie zbędnych reguł, nie o odcięcie potrzebnego kontekstu.
9.Zrozum mechanizm „handoffu” do Opusa
Na czym polega: Fable uruchamia szybką kontrolę bezpieczeństwa i przy podejrzeniu ryzykownej intencji (hakowanie, niebezpieczna biologia, wydobywanie prywatnego rozumowania) cicho przekierowuje zapytanie do Opusa 4.8.
Jak stosować: Jeśli budujesz na API, sprawdzaj w odpowiedzi, który model faktycznie odpowiedział — inaczej możesz nie zauważyć przekierowania. Formułuj żądania tak, by nie wyglądały na złośliwe czy podejrzane.
Na co uważać: Poza API przekierowanie jest niewidoczne — możesz nieświadomie dostawać odpowiedzi ze słabszego modelu. Diagnozuj tak nietypowe spadki jakości pod kątem handoffu.
10.Wbuduj nawyki w środowisko, nie w pojedyncze prompty
Na czym polega: Największą wartość dają te reguły, gdy trafią do plików systemowych, pamięci, CLAUDE.md i skilli, a nie gdy doklejasz je ad hoc na końcu każdego zapytania.
Jak stosować: Zbierz sprawdzone instrukcje (kontekst, granice, weryfikacja, zwięzłość) w trwałej konfiguracji projektu, tak by działały automatycznie w każdej sesji.
Na co uważać: Reguły w plikach systemowych działają globalnie — uważaj, by nie umieścić tam nakazu „pokaż rozumowanie” (punkt 7), bo będzie wyzwalał przekierowania przy każdym uruchomieniu.