O czym jest ten film
- Autor przejrzał oficjalną dokumentację Anthropic i wyciągnął z niej cztery zasady skutecznej pracy z modelem Fable 5.1 — wraz z autentycznymi cytatami.
- Pierwsza zasada: opisz efekt końcowy i intencję, a nie listę zadań — model sam zaplanuje kroki, o ile cel jest jasny.
- Skille i prompty pisane pod starsze modele bywają zbyt rozpisane w detalach i mogą nowemu modelowi po prostu zawadzać; warto je przebudować.
- Druga zasada: domyślny poziom wysiłku „high” to często przesada — większość zadań wystarcza wykonać na „medium” albo „low”.
- Fable 5.1 na „low” wypada mniej więcej jak Fable 5 na „medium” czy „high”, a przy tym kosztuje mniej; porównywana bywa do Opusa.
- Poziom wysiłku można zmieniać w trakcie rozmowy — na Fable 5.1 osobno dla każdej wiadomości, bez utraty cache promptów.
- Trzecia zasada: każ modelowi weryfikować własną pracę podagentami, żeby dostawać dopracowaną „wersję dziesiątą” zamiast surowego szkicu.
- Wyniki, których nie da się zmierzyć obiektywnie, wymagają od ciebie definicji „co znaczy dobrze” — model działa wtedy jak sędzia według twoich kryteriów.
- Czwarta zasada: deleguj — Fable jako strateg i orkiestrator podagentów, zamiast samodzielnego wykonawcy, to największa oszczędność tokenów.
- Równoległe podagenty i grupowane wywołania narzędzi skracają pracę i pozwalają nie czekać na najwolniejsze ogniwo.
Redakcyjne tłumaczenie
Cztery sposoby od Anthropic na wydajną pracę z Fable 5.1
Mam dziś dla was cztery metody pochodzące od samego Anthropic: jak wyciągnąć z Fable 5.1 więcej, jak pracować z nim sprawniej i jak rozciągnąć tygodniowy limit wykorzystania tak daleko, jak się da. Nie traćmy więc czasu i od razu do rzeczy.
Zanim przejdę do konkretów, jedno wyznanie: Fable 5.1 bardzo mi się podoba. Szczerze mówiąc, ostatnio znacznie częściej sięgałem po Codex niż po Claude Code, ale Fable 5.1 sprawdza się naprawdę dobrze. Działa szybko i oszczędnie — pod warunkiem że nauczysz się nim posługiwać, bo widziałem zatrzęsienie osób narzekających, że błyskawicznie roztrwonili limity sesji. Właśnie o tym dziś rozmawiamy.
(Informacja dodatkowa: Codex to narzędzie do pracy z kodem napędzane modelami OpenAI; Claude Code jest jego konkurencyjnym odpowiednikiem od Anthropic.)
Skąd te porady: prosto z dokumentacji Claude
Wszystko, o czym mówię, znalazłem wprost w dokumentacji platformy Claude, w przewodniku o promptowaniu Fable 5.1. Kryje się tam mnóstwo złota. Dokument opisuje każdy model osobno — bo to faktycznie różne modele, o odmiennych cechach i trochę innym sposobie odbierania informacji — więc zawsze warto do niego zaglądać. To bardzo długi tekst z masą scenariuszy. Ja go przekopałem i wyciągnąłem to, co moim zdaniem naprawdę musicie wiedzieć, żeby już dziś zacząć pracować inaczej.
Pierwsza zasada: powiedz modelowi, co znaczy „gotowe”
Chodzi o to, żeby nie zlecać modelowi zadań, tylko wskazać mu metę — i pozwolić Fable 5.1 samodzielnie dojść do tego, jakie kroki muszą się złożyć na wynik. Boris Chernoy, twórca Claude Code, powtarzał to już chyba sto razy: daj tym modelom ambitny cel i zejdź im z drogi. Powiedz Fable, jaki ma być efekt, dlaczego ma znaczenie, co znaczy „zrobione” i czy obowiązują jakieś twarde ograniczenia.
Zamiast pisać coś rozwlekłego, wystarczy poprosić: „Skróć to wszystko do jednego celu głównego, bez rozpisywania pojedynczych zadań”. I gotowe — mamy: „Stwórz atrakcyjny landing page z ofertą rozwiązań voice-agentowych skrojonych pod naszą grupę docelową”. Resztę model wykombinuje sam.
Przy każdej z tych rad pokażę autentyczne cytaty i dowody z dokumentacji, z której je wziąłem. Najpierw jednak jedno zastrzeżenie: część materiału pochodzi z przewodnika o Fable 5, a dokument o Fable 5.1 dopina się do niego jako uzupełnienie. Sami to zaznaczają: „Istniejące prompty napisane pod Claude Fable 5 powinny działać dobrze także na Fable 5.1 bez żadnych zmian, ale kilka różnic w zachowaniu warto znać”.
Pierwszy cytat: „Claude Fable 5 radzi sobie lepiej, gdy rozumie intencję stojącą za prośbą. Kontekst pozwala mu powiązać zadanie z istotnymi informacjami, zamiast samemu zgadywać, o co chodzi”. Dlatego tłumacz modelowi, po co o coś prosisz — zwłaszcza przy agentach pracujących długo i na wielu frontach naraz. To zresztą jeden z powodów, dla których tak wiele daje własny „system operacyjny” dla AI, w którym zapisany jest twój kontekst, cele i tło: przy modelach tej klasy robi on ogromną różnicę.
Kolejny fragment: „Przebuduj istniejące prompty i skille”. Umiejętności napisane pod starsze modele bywają dla Fable 5 i 5.1 zbyt rozpisane w detalach. Jeżeli wasze skille wyglądają jak lista przykazań — zrób to, potem tamto, potem jeszcze to — to kiedyś właśnie tak uczono je budować, ale dziś taki rozkład może modelowi wręcz zawadzać: obniża jego sprawność i stawia mu barierki. I stwierdzenie, że skille trzeba na nowo stroić pod każdy model, to realna sprawa. Pokażę wam wpis Petera Yanga, który dziś trafił mi na oczy: „Jeśli testujecie Fable 5.1, bardzo polecam odpalić /claude api prompt audit na waszych skillach. Wyłapuje całą masę nadmiarów i reguł do usunięcia przy najnowszych modelach”. Spróbujcie.
Ostatni fragment tej części dotyczy domykania całości: „Claude Fable 5.1 potrafi wykonywać bardzo długie zadania niemal bez wskazówek co do metody — zwłaszcza gdy cel jest jasny”. I to jest klucz: cel musi być naprawdę jasny. Stąd pierwsza rada — powiedz, co znaczy „gotowe”, i nie wysypuj na model lawiny pojedynczych kroków.
Druga zasada: dopasuj poziom wysiłku do zadania
Ilu z nas odpala Claude’a i nawet nie dotyka suwaka wysiłku, tylko zostaje na „high”? Tymczasem po kliknięciu nazwy modelu można przełączyć poziom: od domyślnego dla 5.1 „high”, przez „medium” i „low”, aż po „xhigh”, „max” czy tryb „ultra code”.
Zerknijcie na benchmarki, bo pokazują coś ciekawego. Porównajmy wersje bez narzędzi: Fable 5.1 i Fable 5. Nie chodzi mi o to, że 5.1 jest o niebo lepsza od piątki. Chodzi o to, że poziomy wysiłku robią ogromną różnicę. Fable 5.1 na „low” to zupełnie inny zwierz niż Fable 5.1 na „max”. Piątka-jeden na „low” wypada mniej więcej tak, jak Fable 5 na „medium” czy „high” — a przy tym kosztuje mniej. Słyszałem zresztą, że ludzie porównują 5.1 na „low” do Opusa albo naprawdę dobrego Soneta.
Morale z tego takie: większość pracy, jaką wykonujecie w Fable 5.1, nie wymaga trybu „high” — to zwykle armata na wróbla. Krąży taki mem na Twitterze: facet zapala papierosa palnikiem propanowym, z podpisem „używam Fable 5.1 do porządkowania folderu Pobrane”. Bo zwykłe, dzisiejsze modele — Sonnet, GPT 5.5 — wciąż są bardzo dobre. Pamiętacie czasy, gdy Sonnet 3.7 był szczytem możliwości? Nadal jest solidnym modelem; po prostu mamy dziś narzędzia tak mocne, że nie zawsze to one muszą być wyborem domyślnym.
Wniosek praktyczny: nie puszczaj wszystkiego z automatu na maksa ani na „high”. Zacznij od „high”, sprawdź, czy „medium” wykona to samo zadanie równie dobrze — a jeśli tak, zejdź na „low”. „Xhigh” i „max” zostaw na naprawdę wielkie przedsięwzięcia albo zadania wymagające głębokiego namysłu. I liczcie się z tym, że takie sesje więcej kosztują.
A teraz dowody. Po pierwsze: „Rozważ wszystkie poziomy wysiłku”. Mniej więcej to, co powiedziałem — zacznij od domyślnego „high”, a potem testuj pozostałe poziomy. Ale wyłącznie względem własnych testów porównawczych, bo jedni mówią: „jeżdżę cały czas na xhigh i u mnie ideał, wszystko poniżej jest gorsze”. Może wykonują głęboką inżynierię oprogramowania i scalają piętnaście PR-ów na minutę — to faktycznie może wymagać „xhigh”. A ty może tworzysz dokumenty i arkusze — wtedy ani „xhigh”, ani „high” nie jest ci potrzebne. Ocena musi wynikać z twoich zadań, nie z cudzych.
(Informacja dodatkowa: evals, czyli testy porównawcze, to powtarzalna seria własnych zadań, na których mierzy się, który model albo ustawienie radzi sobie lepiej.)
Po drugie: „Wyszukiwanie przy niskim wysiłku”. Na „low” Fable 5.1 rzadziej niż Fable 5 sięga po narzędzia wyszukiwania i pobierania danych, a chętniej odpowiada z pamięci. To otwiera sporo sensownych zastosowań dla „low”: gdy chcesz zachować charakter 5.1, ale nie potrzebujesz ciągłego odpytywania narzędzi — na przykład przy burzach mózgów czy wstępnym eksplorowaniu pomysłów.
Po trzecie: „Zmiana wysiłku w trakcie rozmowy”. Kolejne tury jednej rozmowy można prowadzić na różnych poziomach — i są na to dwa sposoby. W Fable 5.1 wystarczy zmienić poziom przy pojedynczej wiadomości, a cache promptów zostaje zachowane. W innych modelach trzeba wystawić nowe żądanie z nowym parametrem najwyższego poziomu. W praktyce 5.1 pozwala przełączać się między pytaniami — całkiem zmyślne.
(Informacja dodatkowa: cache promptów pozwala ponownie wykorzystać raz przetworzony kontekst rozmowy. Dzięki temu zmiana trybu nie wymusza liczenia całej sesji od zera i nie podbija kosztu.)
Trzecia zasada: każ modelowi udowadniać swoją pracę
Moja ulubiona rada w ogóle — nie tylko do 5.1, ale do pracy z AI w każdym wydaniu. Pomyśl: jak sprawdziłbyś ten wynik, gdyby przyniósł ci go człowiek? Obejrzałbyś stronę? Zobaczył film? Sięgnął do źródeł i zweryfikował fakty? Poklikał po interfejsie? Cokolwiek byś zrobił — nałóż na to swój gust i osąd, ale najpierw pozwól to samo zrobić modelom.
Cała idea polega na tym, że nie chcesz dostawać surowego szkicu. Chcesz dostać wersję piątą albo dziesiątą — już sprawdzoną przez gromadkę podagentów od weryfikacji i poprawianą pięć, sześć, może dziesięć razy, bo przy każdym przeglądzie ktoś znajduje błąd, prostuje go i patrzy jeszcze raz.
Trudność w tym, że nie każdy wynik da się sprawdzić obiektywnie. Gdy optymalizujesz coś tak, żeby X wyszło dziesięć — to da się udowodnić. Ale wiele efektów wymaga oceny subiektywnej, czyli zbudowania własnego modelu-sędziego: i tak musisz włożyć w prompt swoje rozumienie tego, co znaczy „dobrze”. Zdefiniuj cel, ale równie mocno zdefiniuj kryteria dobrej roboty i sposób, w jaki je testować. To nie doprowadzi cię do celu w stu procentach — ale wolisz dojść dziewięćdziesiąt siedem procent drogi niż siedemdziesiąt, nieprawdaż?
Dowody z dokumentacji. Po pierwsze: „Włącz samoweryfikację wprost w promptach do długich zadań” — i dosłownie w przykładzie: „zweryfikuj swoją pracę podagentami względem specyfikacji”. Kawałek dalej inny wariant: „zweryfikuj swoją pracę, jak uważasz”. A jeszcze dalej: „Zanim zgłosisz postęp, skonfrontuj każde twierdzenie z wynikiem narzędzia z tej sesji. Raportuj wyłącznie pracę, którą możesz poprzeć śladem w danych. Jeżeli czegoś jeszcze nie zweryfikowano — powiedz o tym wprost”.
Na koniec kawałek o wzroku, bo wiem, że wielu z was buduje strony, prezentacje i inne rzeczy wymagające sprawdzenia na oko. Fable 5.1 ma lepsze możliwości wizyjne od razu po uruchomieniu, a przy złożonych obrazach — na przykład gęstych wykresach — daje z siebie najwięcej wtedy, gdy może iteracyjnie analizować, przybliżać fragmenty i na bieżąco potwierdzać wzrokowo to, co widzi.
Czwarta zasada: dziel zadanie i zlecaj równolegle
Ostatnia zasada: rozbij duże zadanie na niezależne części. To, że proces jest jeden, nie znaczy, że jeden agent musi go wykonywać. Możesz mieć jeden proces, w którym osiemdziesiąt agentów łapie po kawałku — jak na taśmie montażowej: podają sobie robotę albo każdy robi swoją część równocześnie, a na końcu wszystko składa się w całość. Nie każde zadanie nadaje się do zrównoleglenia, ale bardzo wiele — jak najbardziej.
Co na tym zyskujesz? Szybsze ukończenie. Lepszy fokus i precyzję, bo każdy agent dostaje jedno wąskie zajęcie, a w wąskich zadaniach radzi się najlepiej. Szersze pokrycie tematu. Wreszcie oszczędność kontekstu — główna sesja zostaje czysta i możesz spokojnie rozmawiać z modelem, który tymczasem rozdaje pracę dalej.
To najskuteczniejsza zmiana, jaką wprowadziłem, żeby wycisnąć z Fable 5.1 więcej. Obecnie w większości pracy mówię mu wprost: „Nie buduj. Nie koduj. Nie badaj. Uruchamiaj podagenty, prowadź strategię, interpretuj to, co ci przynoszą, i uruchamiaj kolejne”. W ten sposób inteligencja Fable pracuje tam, gdzie jest najcenniejsza — nad kierowaniem całością — a my oszczędzamy góry tokenów. Serio, spróbujcie takich promptów, a różnicę poczujecie natychmiast.
Uwaga jednak: to nie zwalnia Fable z odpowiedzialności za wynik. Jeśli efekt jest słaby, to wina Fable 5.1, nie podagentów. Model musi pamiętać, że wciąż należy uruchamiać agentów-weryfikatorów, a czasem na samym końcu — w ostatnim przebiegu, nim odda ci robotę — samemu pobrudzić sobie ręce.
Dowody. Po pierwsze, delegowanie i współpraca: „Claude Fable 5 jest wyraźnie pewniejszy w wysyłaniu i utrzymywaniu agentów równoległych oraz niezawodnie prowadzi komunikację z długodziałającymi podagentami i agentami równorzędnymi”. Po drugie, grupowanie niezależnych wywołań narzędzi: „Fable 5.1 zwykle wykonuje wywołania równolegle, jak trzeba. Gdy w żądaniu pada kilka rzeczy do pobrania, odpala wszystkie odpytania naraz, żeby pracowały jednocześnie, zamiast tracić czas kolejno”. I wreszcie: „Równoległe podagenty oszczędzają czas i koszty dzięki odczytom z cache i pozwalają nie czekać na najwolniejsze ogniwo”. Bo wyobraźcie sobie taśmę, na której agent numer trzy grzęźnie w miejscu — a cztery, pięć, sześć, siedem, osiem, dziewięć i dziesięć stoją bezczynnie. Jeśli coś da się zrobić równolegle — róbcie równolegle.
Na koniec
To był spory ładunek wiedzy, więc wszystko — wraz z całą dokumentacją i cytatami — spisałem w prostym przewodniku, dostępnym zupełnie za darmo. Wejdźcie do mojej bezpłatnej społeczności (link w opisie filmu), kliknijcie „Classroom”, a potem „All YouTube resources” — tam zawsze oddaję za darmo wszystkie dokumenty, skille, repozytoria i poradniki, jakie przygotowuję.
To wszystko na dzisiaj. Mam nadzieję, że dowiedzieliście się czegoś nowego — jeśli tak, zostawcie łapkę w górę, bardzo mi to pomaga. Dziękuję, że dotrwaliście do końca. Do zobaczenia w następnym odcinku.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Cel zamiast listy zadań
Na czym polega: Modelom klasy Fable 5.1 lepiej wychodzi samodzielne planowanie kroków niż wykonywanie rozwlekłych instrukcji. Zadanie zaczyna się od mety i intencji.
Jak stosować: W prompcie opisz wynik, powód, dla którego jest ważny, definicję „gotowe” i twarde ograniczenia. Jeśli masz notatkę pełną mikro kroków, poproś model: „streść to jako jeden cel główny, bez pojedynczych zadań” — i od tego zacznij.
Na co uważać: „Jasny cel” to warunek konieczny — gdy definicja efektu jest mglista, model może błądzić nawet przy pełnej swobodzie. Nie myl wolności działania z brakiem wymagań.
2.Dokarmiaj model kontekstem i intencją
Na czym polega: Dokumentacja wprost mówi, że model działa lepiej, gdy rozumie, po co o coś prosimy — kontekst jest lepszy niż zgadywanie.
Jak stosować: Przy każdym zleceniu dodawaj jedno–dwa zdania o celu szerszym niż samo zadanie, zwłaszcza przy agentach działających długo i na wielu wątkach. Warto trzymać cele i tło projektu w stałych plikach, po które model sam sięga.
Na co uważać: Kontekst też kosztuje tokeny — trzymaj go zwięźle i na bieżąco aktualizuj, zamiast dokładać kolejne warstwy historii.
3.Zrewiduj stare skille pod nowy model
Na czym polega: Umiejętności pisane pod starsze generacje bywają nadmiernie restrykcyjne i zamiast pomagać, stawiają nowemu modelowi barierki.
Jak stosować: Po zmianie modelu przepuść swoje skille przez audyt promptów (autor cytuje polecenie /claude api prompt audit sugerowane przez Petera Yanga) i usuń reguły oraz powtórzenia, które nowa wersja wykryje jako zbędne.
Na co uważać: Nie tnij ślepo wszystkiego — zostaw reguły dotyczące formatu wyniku, bezpieczeństwa i integracji, bo ich naruszenie kosztuje najwięcej. Zmiany weryfikuj na własnych zadaniach.
4.Świadomie używaj suwaka wysiłku
Na czym polega: Domyślny „high” to często przerost formy nad potrzebą: Fable 5.1 na „low” wypada mniej więcej jak Fable 5 na „medium” czy „high”, a kosztuje mniej.
Jak stosować: Zacznij od „high” jako punktu odniesienia, potem sprawdź na tych samych zadaniach „medium” i „low”. Jeżeli wynik się nie pogarsza — zostań na niższym poziomie na stałe.
Na co uważać: Ocena musi opierać się na twoich testach, nie na cudzych opiniach: ktoś łączący dziesiątki PR-ów godzinę naprawdę potrzebuje „xhigh”, ale tworzenie dokumentów i arkuszy nie. Pamiętaj też, że na „low” model rzadziej sam sięga po wyszukiwanie i częściej odpowiada z pamięci.
5.Zmieniaj poziom wysiłku w trakcie rozmowy
Na czym polega: W Fable 5.1 można ustawić poziom wysiłku osobno dla pojedynczej wiadomości, zachowując cache promptów — rozmowa nie zaczyna się od zera.
Jak stosować: Burzę mózgów i luźne pytania prowadź na „low”, a dopiero konkretne wykonanie podnieś do wyższego poziomu — w obrębie tej samej sesji.
Na co uważać: To specyfika Fable 5.1; przy innych modelach zmiana wymaga nowego żądania z nowym parametrem, co może oznaczać utratę cache i wyższy koszt.
6.Samoweryfikacja wpisana wprost w prompt
Na czym polega: Model potrafi sam sprawdzać swoją pracę podagentami względem specyfikacji i raportować wyłącznie to, co da się poprzeć dowodem z sesji.
Jak stosować: Do promptów dłuższych zadań dodawaj zdania w rodzaju: „zweryfikuj swoją pracę podagentami względem specyfikacji” albo „raportuj tylko efekty, które możesz poprzeć wynikiem narzędzia; jeśli czegoś nie zweryfikowano, powiedz to wprost”.
Na co uważać: Każda runda sprawdzania to dodatkowe tokeny i czas — nie każ weryfikować trivialnych zadań, bo stracisz dokładnie to, co chciałeś oszczędzić.
7.Zdefiniuj, co znaczy „dobrze”
Na czym polega: Wyników, których nie da się zmierzyć obiektywnie, nie sprawdzi żaden automat — ocenia je model w roli sędziego według kryteriów, które mu dasz.
Jak stosować: Obok celu opisz wzorcowy efekt (jak wygląda, co zawiera, czego unika) i sposób testu. Każ modelowi iterować: przegląd, poprawa, kolejny przegląd — aż do spełnienia kryteriów.
Na co uważać: Takie oceny dowiozą cię może w 97 procentach, nie w stu — zostaw sobie końcowy przegląd wzrokiem, zanim uznasz robotę za skończoną.
8.Niech model patrzy na swoje efekty
Na czym polega: Fable 5.1 ma dobry wzrok i przy gęstych wykresach oraz złożonych grafikach pracuje najlepiej, gdy może iteracyjnie analizować, przybliżać fragmenty i na bieżąco potwierdzać to, co widzi.
Jak stosować: Przy stronach, slajdach i wykresach pozwól modelowi wyrenderować albo zrobić zrzut ekranu własnego efektu i poprawiać go, dopóki nie przejdzie wzrokowej kontroli.
Na co uważać: Generowanie i analiza obrazów podnoszą koszt i czas iteracji — stosuj tam, gdzie wygląd naprawdę ma znaczenie, a nie przy każdym drobiazgu.
9.Deleguj zamiast wykonywać
Na czym polega: Największa oszczędność limitów według autora: Fable jako strateg i orkiestrator — uruchamia podagentów, interpretuje ich wyniki i zleca dalej — zamiast samemu kodować, budować i badać.
Jak stosować: Wpisz wprost w prompt rolę: „nie buduj, nie koduj, nie badaj; twórz podagentów, prowadź strategię, interpretuj rezultaty i twórz kolejnych”. Główna sesja zostaje lekka, a ciężka robota idzie na boczne tory.
Na co uważać: Odpowiedzialność za wynik pozostaje na modelu-koordynatorze — przypominaj mu o uruchamianiu weryfikatorów i o własnym, końcowym przebiegu przed oddaniem pracy.
10.Równoległość tam, gdzie się da
Na czym polega: Niezależne podzadania wykonane równocześnie skracają pracę i pozwalają nie czekać na najwolniejsze ogniwo; Fable 5.1 dobrze zarządza równoległymi agentami i grupuje wywołania narzędzi.
Jak stosować: Zanim zlecisz duże zadanie, podziel je na kawałki, które nie zależą od siebie nawzajem, i każ je rozdać równolegle. Korzystaj z faktu, że model sam odpala serie odpytań jednocześnie.
Na co uważać: Nie wszystko da się zrównoleglić — zadania sekwencyjne, w których każdy krok potrzebuje wyniku poprzedniego, trzeba zostawić w kolejce. Wielu agentów trudniej też diagnozować, gdy coś pójdzie nie tak.