O czym jest ten film
- Od 12 lipca Fable 5 wychodzi z abonamentu Claude i każdy token liczony jest według stawek API: 10 USD za milion tokenów wejściowych i 50 USD za milion wyjściowych.
- Sama cena za token jest myląca — liczy się koszt ukończonego zadania, bo różne modele „spalają” różną liczbę tokenów, by wykonać tę samą pracę.
- Na trzech realnych workloadach widać, że Fable jest droższy, ale często kończy zadanie „na gotowo”, podczas gdy tańsze modele wymagają dużo ręcznej dopracówki.
- Fable warto używać tam, gdzie output nie jest tokenożerny, a dźwignia duża: planowanie i przeglądy kodu — nie do implementacji ani scrapowania danych.
- Wzorzec 1: planuj na Fable, buduj na Sonnet (ręczne przełączanie modelu, bo brak gotowego aliasu).
- Wzorzec 2: Fable jako recenzent — prosty sub-agent wymuszający review kodu bez pisania kodu, tylko zwracanie ustaleń.
- Wzorzec 3: zadania z jasnym celem i kryterium weryfikacji (np. rekoncyliacja księgowa), gdzie model sam rozwiązuje setki niejednoznaczności.
- Ustawienia obniżające koszt: domyślny model na Sonnet, tańszy model dla sub-agentów, odchudzenie CLAUDE.md.
- Blokowanie „śmieciowych” odczytów (.claudeignore + twarde uprawnienia deny) oraz odłączanie nieużywanych serwerów MCP.
- Dodatkowo:
enableToolSearch, wyłączenie auto-memory (jeśli masz własny system pamięci) i miesięczny limit wydatków jako zabezpieczenie.
Redakcyjne tłumaczenie
Fable 5 przestaje być „w cenie abonamentu”
Do większości tego, co robisz, Fable 5 nie jest ci potrzebny. Od tego tygodnia ma to realne znaczenie, bo Fable 5 znika z twojej subskrypcji Claude 12 lipca — i od tej chwili każdy token rozlicza się według stawek API. To 10 USD za milion tokenów wejściowych i zdumiewające 50 USD za milion tokenów wyjściowych. I nie jest to wyłącznie kierunek Claude — podobnie robią inni dostawcy. Czasy, gdy jeden płaski abonament pokrywał wszystko, co w niego wrzucisz, dobiegają końca.
W tym materiale pokażę dokładnie, które zadania są warte pieniędzy wydanych na Fable 5, które nie, a następnie każde ustawienie, które warto wyłączyć, żeby rachunek nie zaczął po cichu uciekać w górę, kiedy już zdecydujesz się na ten model.
Jedno „Hi” potrafi kosztować dziesiątki tysięcy tokenów
Sam byłem zaskoczony, gdy zobaczyłem to po raz pierwszy. Jeśli otworzysz Claude Code i wpiszesz po prostu „Hi” albo „Jakiego koloru jest niebo?” — tak jak zrobił to pewien użytkownik na GitHubie — to jedno słowo czy jedno zdanie może cię kosztować dziesiątki tysięcy tokenów. Widać tam: prompt „Hi” — 31 000 tokenów; prompt „What color is the sky?” — 19 000 tokenów.
Sprawdzam to na własnym repozytorium. Po komendzie /context widzę dokładnie, ile tokenów zużyła ta prosta wiadomość. „Hi” — 37 200 tokenów, czyli 4% mojego okna kontekstu poszło na jedną prostą wiadomość. Widać też przybliżony podział: 5 tys. w prompcie systemowym, dalej sterta narzędzi, własne agenty, pliki pamięci, skille, a także wcześniejsze wiadomości.
Gdybym używał Fable, pierwsza wiadomość to jakieś 30–40 centów. Ponieważ te dane są cache’owane, kolejne zapytanie w tej samej rozmowie kosztuje już około 3–4 centów. To dodatkowy koszt doklejany do każdego pojedynczego zapytania — a im więcej kontekstu dokładasz, tym bardziej to rośnie.
Kluczowe: dzieje się tak nie dlatego, że Claude napisał nam elaborat w odpowiedzi, lecz z powodu wszystkiego, co ładuje się, zanim wpiszesz choć jeden znak. Masz prompt systemowy, pliki CLAUDE.md, pliki pamięci, każde narzędzie MCP ładowane automatycznie, wszystkie własne agenty (np. GSD), wszystkie skille. Przy MCP wczytuje się cały schemat narzędzia — i to wszystko zjada kontekst.
Po komendzie usage widać, że skoro jesteśmy na Opus 4.8, a nie na Fable, dotychczas kosztowało to około 15 centów w tokenach API. Na abonamencie tego nie płacisz — ale na Fable już tak. To zresztą daje ważne wskazówki: w moich serwerach MCP serwer „Claude in Chrome” zużywa 45% tokenów przypadających na MCP. Są więc metody, żeby wyciąć sporą część tego bazowego kosztu, gdy zdecydujesz się na Fable. Zapamiętaj komendy context i usage — wrócimy do nich na końcu i porównamy tę samą wiadomość „Hi” po wyłączeniu wszystkich tych ustawień.
Nie liczy się koszt tokena, lecz koszt ukończonego zadania
Fable 5 to około 10 USD za milion tokenów wejściowych i 50 USD za milion wyjściowych. Przy tak inteligentnym modelu cena za token jest jednak myląca, bo różne modele spalają różną liczbę tokenów, by wykonać w praktyce tę samą pracę. Jednostką, która ma znaczenie, nie jest koszt za token, tylko koszt za ukończone zadanie.
Pewien zespół opublikował swoje realne pomiary na trzech workloadach — i to dobrze oddaje sedno sprawy.
Workload pierwszy — szybki przegląd kodu, PR na 200 linii. Fable kosztował tu około 10 centów, prawie osiem razy tyle co Sonnet, bo zużywa trzykrotnie więcej tokenów wyjściowych. W zamian daje jednak bardziej wnikliwe rozumowanie i wyłapuje przypadki brzegowe, które mniejsze modele często przeoczają.
Workload drugi — zbudowanie pełnej strony z cennikiem w Next.js. Wersja Sonnet kosztowała około 25 centów, wersja Fable — 4,18 USD, ale była gotowa do wdrożenia. To istotne rozróżnienie: Fable kosztował tu 17 razy więcej niż Sonnet, ale faktycznie skończył zadanie. Output Sonnet trzeba było jeszcze przez dwie godziny dopracowywać z człowiekiem, żeby nadawał się do wdrożenia. Jeśli twój czas wart jest, powiedzmy, 50 USD za godzinę, to Fable 5 wychodzi taniej: jego wersja kosztowała cię 4–4,20 USD, a wersja Sonnet — 100 USD, bo kosztem alternatywnym jest czas.
Workload trzeci — najbardziej złożony, i tu różnica jest największa: wielogodzinny, wieloagentowy build kompletnej aplikacji CRUD od początku do końca. Sonnet w ogóle nie startuje w tym wyścigu, bo traci spójność w tak długich sesjach — porównujemy więc Opus 4.8 i Fable 5. Opus skończył za 5,40 USD z chropowatościami. Fable skończył za 23,70 USD i 450 000 tokenów wyjściowych, ale z testami i dokumentacją — gotowy do merge’a.
Widać wzorzec: premia za tokeny jest w pełni widoczna, Fable 5 w każdym scenariuszu kosztował najwięcej. Ale trzeba zadać sobie pytanie: czy będziesz musiał to poprawiać, jeśli za pierwszym razem nie wyjdzie? I ile cię to będzie kosztować w czasie albo pieniądzach za pracę? To prowadzi do oczywistego pytania — na których zadaniach faktycznie warto używać Fable?
Trzy wzorce, w których Fable 5 ma sens
Chcę, żebyś rozważył trzy sposoby korzystania z Fable 5. Używaj go na etapach, gdzie output nie jest tokenożerny, ale możesz uzyskać dużo większą dźwignię — na przykład przy planowaniu i przy przeglądach kodu. Nie używaj go do implementacji, gdzie tokenów wyjściowych będzie mnóstwo (płacisz 50 USD za milion), ani tam, gdzie musisz scrapować dane z sieci, bo płacisz za ilość danych wchłanianych do kontekstu.
Wzorzec 1: planuj na Fable, buduj na Sonnet
Claude Code ma wbudowany alias „Opus Plan”. Wpisujesz /model Opus Plan i model planuje na Opus, a implementuje na Sonnet. Na razie nie ma odpowiednika dla Fable, więc zbuduj go sam — trwa to dosłownie 10 sekund.
Najpierw przełączam model na Fable 5. Następnie proszę: zaplanuj komponent cennika w Next.js dla mojej aplikacji. Chcę uprościć obecny system cen: 79 USD bazowo za 30 artykułów generowanych przez AI, które pomagają w pozycjonowaniu w SEO, a potem zniżkę za dodatkowe obserwowane marki. Kontekst: mamy dziś trzy plany — starter, growth i premium — ale to nie jest wystarczająco proste. Chcę przekształcić to w praktycznie jeden plan (30 artykułów miesięcznie pod SEO) i doradzać klientom właśnie ten plan, a jeśli ktoś chce pozycjonować więcej marek, dajemy zniżkę ilościową.
Wchodzę w tryb planowania (Shift+Tab cyklicznie przełącza tryby) i puszczam to. Zrobiłem to w całkowicie osobnym drzewie roboczym (Informacja dodatkowa: git worktree — oddzielna kopia robocza repozytorium, pozwala pracować równolegle bez mieszania zmian), żeby stworzyć ten komponent, a wykonać go już czymś w rodzaju Sonnet.
Planuj na Fable tam, gdzie trzeba przemyśleć logistykę i architekturę, a buduj na Sonnet. Planowanie zużyje mniej tokenów niż wykonanie — dlatego robimy to właśnie w tej kolejności. Planowanie zajęło około 38 000 tokenów, trwało parę minut, model dopytał mnie o przypadki brzegowe — a to właśnie istota używania Fable: jest na tyle inteligentny, żeby przejrzeć pliki i sam ustalić, jakie mogą być te przypadki brzegowe, a potem ułożyć kompletny plan.
Teraz etap, gdzie ręcznie zmieniamy model. Każę Claude zapisać plan do pliku plan.md w folderze projektu i mówię, żeby zrobił tylko to — bo jeśli zacznie wykonywać, automatycznie przejdzie do egzekucji wewnątrz Fable 5. Potem uruchamiam komendę model ponownie i przełączam z powrotem na Sonnet. Za plan płacimy więc stawki Fable, za implementację — stawki Sonnet. Dostajemy inteligencję w planie, a wykonanie robi tańszy Sonnet. Mówię tylko: wykonaj plik plan.md w danym katalogu. To jest przypadek pierwszy.
Wzorzec 2: Fable jako recenzent
Drugi wzorzec wykorzystuje to, że Fable jest stworzony do recenzowania. Fable 5 to model klasy Mythos, który — jeśli pamiętasz — potrafił znaleźć exploity, przez co został zawieszony przez rząd USA. (Informacja dodatkowa: to twierdzenie z narracji autora, prezentowane bez źródła; traktuj jako element opowieści, nie potwierdzony fakt). Znajdowanie tego, co zepsute, to rzecz, w której ten model jest naprawdę dobry — możemy więc użyć go do przeglądów naszego kodu.
Robimy to, tworząc bardzo prostego sub-agenta, który wymusza użycie Fable do konkretnych zadań, np. przeglądów kodu. Wchodzimy do folderu .claude, upewniamy się, że mamy folder agents, i wewnątrz tworzymy code-reviewer.md. Bardzo prosto: recenzent przegląda zmiany w kodzie pod kątem bugów, przypadków brzegowych i kwestii bezpieczeństwa; używać po implementacji. Wskazujemy tu model. Mamy drobny problem z walidacją schematu, ale Claude zapewnia, że tak właśnie powinno być zapisane. To bardzo prosty agent, którego Claude sam wywoła przy określonych zadaniach — tu przy przeglądach kodu — i któremu dajemy dostęp do wybranych narzędzi.
Co ważne, zapisujemy w nim: nie pisz kodu, zwróć tylko ustalenia. Wiemy bowiem, że zwracanie faktycznego kodu kosztowałoby nas sporo. Zaznaczamy więc: trzymaj wynik zwięźle. To prosty dodatek dla wzorca drugiego.
Wzorzec 3: cel plus kryterium weryfikacji („loop engineering”)
Trzeci wzorzec: jeśli już masz go użyć, korzystaj z niego z konkretnym celem, w pętli. Jeśli używasz go do planowania jak we wzorcu pierwszym, gorąco polecam poniższe podejście.
Fable jest zbudowany do długiej, jednorazowej pracy asynchronicznej. Ma wbudowaną pętlę samosprawdzania: potrafi zaplanować, wykonać i zwalidować własny output, a potem sam wprowadzić poprawki. Ale ta pętla zadziała tylko wtedy, gdy dobrze sformułujesz zadanie — jeśli dasz mu dość kontekstu, w tym kryteria weryfikacji.
Świetnie sprawdza się przy kodowaniu, ale też przy zadaniach, gdzie kryterium sukcesu jest dobrze zdefiniowane, lecz nie jest z góry przepisana droga dojścia do niego. Przykład: rekoncyliacja księgowa. Cel: uzgodnij każdy paragon z drugiego kwartału z folderu /receipts z eksportem z banku. Kryterium sukcesu: każda transakcja bankowa dopasowana do paragonu albo wypisana w unmatched.md z twoim najlepszym przypuszczeniem, dlaczego nie ma dopasowania; sumy muszą się zgadzać; wszystko niepewne oflagowane, nic nieprzyjmowane na wiarę. Do tego kryterium weryfikacji: zsumuj dopasowane paragony, zsumuj eksport bankowy, porównaj, potwierdź, że każda linia bankowa pojawia się dokładnie raz. Piętnaście linijek — bardzo proste, świetnie sprawdzalne i nie-preskryptywne.
To właśnie chcemy tu podkreślić. Pojawia się słuszne pytanie: po co kierować najdroższy model na coś tak z pozoru prostego. Ale gdy spojrzysz na samo zadanie, masz tu potencjalnie tysiące transakcji z drobnymi decyzjami. Na przykład masz paragon z Ubera, ale linia bankowa mówi „Uber* trip”, a kilka dni później dochodzi kolejna transakcja, bo daliśmy kierowcy napiwek. Dwie kawy kupione tego samego dnia. Mnóstwo niuansów, które trzeba by rozważyć i opisać.
Powiedzieliśmy już, że Fable jest doskonały w rozumowaniu — więc jeśli damy mu prosty cel z kryteriami weryfikacji, sam wykona myślenie potrzebne do rozwiązania tych setek niejednoznaczności. I tu, jak mówi Anthropic, model naprawdę rozkwita. Dajemy mu cel i kryteria sukcesu i pozwalamy działać: niech planuje, wykonuje i sam sprawdza swoją pracę. Możemy też zmienić układ i kazać mu jedynie stworzyć kryteria sukcesu, a wykonanie zlecić tańszemu modelowi — jak w scenariuszu pierwszym.
Porównaj to z uruchomieniem tego w Sonnet. Prawdopodobnie miałbyś coś takiego: ten sam cel, ale — jak przy starszych modelach — musiałbyś być bardzo preskryptywny, bo inaczej model nie rozumiał niejednoznaczności. Dopasuj najpierw po kwocie, potem po dacie w oknie czterech dni; kwoty w granicach 15% liczą się jako dopasowanie tylko, jeśli zgadza się też sprzedawca; „Uber* trip” kontra „Uber” i tak dalej. To tylko drobna próbka reguł, które trzeba by z czasem dopisywać — i pewnie i tak nie objęłyby nawet powierzchni tego, ile niejednoznaczności i przypadków brzegowych kryje się w czymś tak złożonym jak rekoncyliacja. To znów sprowadza się do zestawienia kosztu i czasu.
Kiedy Fable nie używać
Zasada mówi: nie prowadź z Fable czatu. Jeśli robisz 30 minut wymiany zdań tam i z powrotem, kosztuje to 2–3 USD, podczas gdy rozmowa z Sonnet — wystarczająco inteligentnym, żeby konwersować — to jakieś 15 centów.
Ustawienia, które przestają cię przepłacać
Skoro znasz już przypadki użycia, upewnijmy się, że reszta twojej konfiguracji nie zmusza cię do nadpłacania, gdy faktycznie chcesz go użyć. Przejdźmy przez szybkie wskazówki — łatwe do wdrożenia, a oszczędzające sporo pieniędzy w dłuższej perspektywie.
1. Zmień domyślny model na Sonnet. Wciśnij /model, przejdź do Sonnet 5 lub Sonnet 6 i ustaw go jako domyślny dla nowych sesji. Zespoły, które wprowadziły tę jedną zmianę, ścięły rachunki mniej więcej o połowę bez utraty jakości przy codziennych zadaniach. Na trudniejsze rzeczy zawsze możesz przełączyć.
2. Kontroluj model sub-agentów. Sub-agenty domyślnie dziedziczą model rodzica — kiedyś mnie to zaskoczyło. Wyobraź sobie, że jesteś na Fable, robisz trudne zadanie, a Claude uruchamia pięć równoległych agentów badawczych, wszystkie na Fable — część czyta pliki, zapisuje logi, zużywa tokeny myślenia. Żeby to naprawić, wejdź do folderu .claude w katalogu domowym (Cmd+Shift+G otwiera okno wyszukiwania, wpisz .claude), otwórz settings.json i w sekcji env dodaj zmienną modelu sub-agenta, wskazując np. Hi-Q. (Informacja dodatkowa: w narracji autora „Hi-Q” pełni rolę taniego modelu — odpowiednika Haiku; sprawdź aktualną nazwę zmiennej i modelu w dokumentacji, bo szczegóły się zmieniają). Odtąd każdy odpalony agent domyślnie działa na Hi-Q, niezależnie od tego, że ty pracujesz na Fable 5. Hi-Q to około jednej piątej ceny Sonnet i ułamek ceny Fable. Pamiętaj: ci agenci-robotnicy mają tylko wykonać plan — jeśli myślenie i rozumowanie zrobiłeś z góry i szczegółowo, spokojnie użyjesz tańszych modeli.
3. Odchudź CLAUDE.md. Każda linia w CLAUDE.md ładuje się na starcie sesji i towarzyszy każdej wiadomości, więc na słowo jest to najdroższy plik w projekcie. Zadaj sobie pytanie: czy Claude może wywnioskować którąś z tych reguł z samego kodu? Jeśli tak — możesz ją wyciąć. Ktoś to przetestował: porównał CLAUDE.md o 3847 tokenach z wersją 312-tokenową, okrojoną tylko do tego, czego Claude nie mógł wywnioskować z kodu — 92% redukcji kontekstu bez pogorszenia jakości. Finansowo: przy wydatku 500 USD miesięcznie na API oszczędzasz 460 USD miesięcznie.
Kilka rzeczy nie liczy się do tokenów. Możesz dodawać komentarze HTML inline — na notatki dla zespołu i uzasadnienia, których Claude nie musi wczytywać do kontekstu; to też przydatny sposób na wizualne rozdzielenie pliku. Pamiętaj też, że importy (np. @agents.md wskazujące na inny plik) za każdym razem wciągają całą jego zawartość. Sugestia: zejdź poniżej 200 linii, a jeśli się da — nawet do 60. W CLAUDE.md powinno zostać wyłącznie to, czego Claude nie może wywnioskować z kodu.
4. Blokuj „śmieciowe” odczyty. Chodzi o wczytywanie rzeczy będących po prostu ogromnymi porcjami kontekstu, których nie trzeba czytać — node_modules, wyniki builda i podobne. Robimy to na dwa sposoby i chcesz obu naraz, bo działają inaczej.
Warstwa pierwsza to plik .claudeignore w katalogu głównym. Wklej przykłady: node_modules, dist, build, coverage, pliki lock, vendor. Nie musisz dokładnie rozumieć, co każde robi — ważne, że zawierają mnóstwo znaków, których zwykle nie trzeba wczytywać. Uwaga: .claudeignore jest doradczy, więc może i tak coś wczytać.
Warstwa druga to uprawnienia — te nie są doradcze, tylko egzekwowane. Claude nie może tego przeczytać, nawet gdyby chciał. W settings.json (lokalnie albo globalnie dla wszystkich repozytoriów) w sekcji permissions dodajesz linie odmawiające odczytu node_modules, dist i plików lock — i możesz dodać więcej. Jeśli wrzucisz to do repozytorium na GitHubie, cały zespół dostaje te same reguły i redukujesz kontekst dla wszystkich. Zmierzone wyniki (z bloga Fireclaw) pokazały 85,5% redukcji kontekstu z samego użycia .claudeignore.
5. Odłączaj nieużywane serwery MCP. Każdy podłączony serwer MCP ładuje pełny schemat swoich narzędzi na starcie sesji — niezależnie od tego, czy go w tej sesji użyjesz. To 10–20 tys. tokenów na serwer, wepchniętych w pierwszą wiadomość, potem cache’owanych i towarzyszących każdej kolejnej. Po context widać u mnie naraz Canva, Gmail, Google Calendar, Google Drive, Notion i Claude in Chrome. Po usage widać, że Claude in Chrome zajmuje blisko 50% miejsca na schematy MCP. Nawet cztery–pięć serwerów to 50–70 tys. tokenów narzutu, zanim cokolwiek zrobisz.
Odłączaj więc wszystko, czego nie używałeś od paru tygodni — u mnie to Notion oraz Canva. Mogę poprosić Claude, żeby usunął połączenia z Notion i Canva całkowicie; ponowne podłączenie zajmuje minutę, gdy będzie potrzebne. Zamiast MCP możesz też użyć narzędzia z linii poleceń (CLI) — wtedy nie ładujesz żadnych schematów, a przy sporadycznym wywołaniu to w zupełności wystarczy. MCP jest dobry, bo pokazuje listę funkcji, którymi możesz działać — ma więc sens tylko wtedy, gdy z danej usługi korzystasz często i intensywnie. Możesz też wpisać /mcp — u mnie okazało się, że nie jestem nawet uwierzytelniony przy Canvie i Google Calendar — i wyłączyć je bezpośrednio tutaj. Po ponownym context zostają mi już tylko Google Drive i Claude in Chrome.
6. Włącz ładowanie narzędzi na żądanie. W settings.json, w zmiennych środowiskowych, dodaj enableToolSearch: true. Definicje narzędzi będą się wtedy ładować dopiero wtedy, gdy Claude faktycznie po któreś sięgnie, zamiast trzymać wszystkie w kontekście.
7. Wyłącz auto-memory (jeśli masz własny system pamięci). Uruchom /memory i wyłącz automatyczną pamięć. Mało kto wie, że gdy rozmawiasz z Claude, Claude Code forkuje cały ten kontekst do osobnego wywołania w tle, żeby wydobyć wspomnienia o twoim projekcie — płacisz pełną cenę wejściową za wysłanie tego kontekstu. Przez /memory możesz przełączyć auto-memory na wyłączone. Polecam to jednak tylko, jeśli masz własny system pamięci działający w tle, żebyśmy nie dublowali pracy i tokenów.
8. Ustaw miesięczny limit wydatków. To zabezpieczenie na poziomie konta na wypadek, gdyby coś poszło nie tak i zespół wydał więcej kredytów, niż zakładasz. W interfejsie webowym Claude.ai wejdź w ustawienia, potem w „usage” — jeśli masz włączone kredyty, możesz ustawić miesięczny limit wydatków albo kupić kredyty z góry. Ten miesięczny pułap to twardy sufit, którego Claude nie przekroczy — chroni przed katastrofalnym rachunkiem. Jeśli dużo korzystasz z Fable, koniecznie tu zajrzyj.
Podsumowanie z małą wpadką
Wróćmy do context teraz, gdy wdrożyliśmy wszystkie wskazówki. Wpisuję znowu „Hi”, potem context — i ironicznie widać, że liczba tokenów… wzrosła. Ważne: używam teraz Sonnet 5, więc coś musiało jeszcze zostać w pamięci i podbić zużycie. Wychodzę przez to na głupka, ale zapewniam, że wszystkie metody wdrożone dzisiaj w dłuższym okresie zmniejszą liczbę zużywanych tokenów — zwłaszcza jeśli sięgniesz po Fable 5, gdzie trzeba być naprawdę selektywnym.
Omówiliśmy więc konteksty, w których warto sięgnąć po Fable 5 — trzy wzorce — oraz sposoby ograniczania zużycia tokenów, gdybyś jednak chciał go użyć: przez ustawienia środowiskowe, usuwanie MCP, porządki w katalogu i tym podobne. Choć zużyliśmy tu odrobinę więcej tokenów kontekstu, jestem przekonany, że na przyszłość ograniczyłem liczbę tokenów na turę i na sesję. A jeśli nic więcej z tego nie wyniosłeś, to przynajmniej przełączyłeś się na tańszy model domyślny.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Fable 5 wychodzi z abonamentu i przechodzi na stawki API
Na czym polega: Od 12 lipca każdy token Fable 5 rozlicza się po 10 USD za milion na wejściu i 50 USD za milion na wyjściu, poza płaskim abonamentem.
Jak stosować: Zanim uruchomisz cokolwiek na Fable, świadomie zdecyduj, czy zadanie jest tego warte; traktuj ten model jak płatne narzędzie premium, nie jak domyślne.
Na co uważać: To nie tylko polityka Claude — podobny kierunek biorą inni dostawcy. Ceny i daty się zmieniają, więc zweryfikuj aktualne stawki, zanim zaplanujesz budżet.
2.Liczy się koszt ukończonego zadania, nie koszt tokena
Na czym polega: Różne modele spalają różną liczbę tokenów na tę samą pracę; drogi model, który kończy zadanie „na gotowo”, bywa tańszy niż tani model wymagający godzin poprawek.
Jak stosować: Wyceniaj swój czas i dolicz koszt reworku do porównania. Jeśli godzina twojej pracy warta jest 50 USD, a Fable oszczędza dwie godziny dopracówki, jego wyższa cena tokenów się zwraca.
Na co uważać: Ta kalkulacja działa tylko przy zadaniach, gdzie tani model faktycznie wymaga sporo poprawek. Przy prostych zadankach premia za Fable to czysta strata.
3.Używaj Fable tam, gdzie output jest lekki, a dźwignia duża
Na czym polega: Najlepszy zwrot dają etapy z małą liczbą tokenów wyjściowych, ale dużym wpływem na całość — planowanie i przeglądy kodu.
Jak stosować: Rezerwuj Fable na myślenie, architekturę i review. Do implementacji i scrapowania danych używaj tańszych modeli, bo tam output (płatny 50 USD/mln) i wchłaniany kontekst eksplodują.
Na co uważać: Nie odpalaj Fable na zadania generujące masę tekstu wyjściowego — to najszybszy sposób na uciekający rachunek.
4.Wzorzec „planuj na Fable, buduj na Sonnet”
Na czym polega: Fable planuje (mało tokenów, dużo inteligencji), a tańszy Sonnet wykonuje plan (dużo tokenów, prosta robota).
Jak stosować: Przełącz na Fable, poproś o zapisanie planu do plan.md i tylko to; potem przełącz na Sonnet i każ wykonać plik. Ręczne przełączenie zajmuje sekundy.
Na co uważać: Jeśli nie zatrzymasz Fable na etapie planu, sam przejdzie do wykonania — i zapłacisz jego stawki za implementację. Wyraźnie zaznacz „tylko zapisz plan”.
5.Fable jako wymuszony recenzent kodu
Na czym polega: Prosty sub-agent (.claude/agents/code-reviewer.md) z przypiętym modelem Fable, który przegląda kod pod kątem bugów, przypadków brzegowych i bezpieczeństwa.
Jak stosować: W definicji agenta zapisz wprost „nie pisz kodu, zwróć tylko ustalenia” i „trzymaj wynik zwięźle”, żeby uniknąć drogiego outputu. Claude sam wywoła agenta przy przeglądach.
Na co uważać: Autor wspomina o problemie z walidacją schematu — sprawdź aktualny format pliku agenta w dokumentacji, zamiast kopiować na ślepo.
6.Zadania z celem i kryterium weryfikacji zamiast sztywnych reguł
Na czym polega: Dla zadań o jasnym kryterium sukcesu, lecz bez jednej ścinki dojścia (np. rekoncyliacja księgowa), Fable sam rozwiązuje setki niejednoznaczności.
Jak stosować: Podaj cel, kryteria sukcesu i sposób weryfikacji, i poproś o oflagowanie wszystkiego niepewnego zamiast zgadywania. Krótki, sprawdzalny, nie-preskryptywny brief działa lepiej niż długa lista reguł.
Na co uważać: Bez kryteriów weryfikacji wbudowana pętla samosprawdzania Fable nie zadziała. Zawsze weryfikuj wyniki wrażliwe (np. finansowe) i traktuj oflagowane pozycje poważnie.
7.Ustaw Sonnet jako domyślny model, a tani model dla sub-agentów
Na czym polega: Domyślny Sonnet obcina rachunki mniej więcej o połowę bez utraty jakości na co dzień; sub-agenty domyślnie dziedziczą model rodzica, co potrafi mnożyć koszt.
Jak stosować: Ustaw domyślny model na Sonnet przez /model, a w settings.json (sekcja env) wskaż tani model dla sub-agentów, żeby równoległe agenty nie działały na Fable.
Na co uważać: Sprawdź aktualną nazwę zmiennej środowiskowej i taniego modelu — nazewnictwo z filmu („Hi-Q”) może odbiegać od bieżącej dokumentacji.
8.Odchudź CLAUDE.md do tego, czego nie da się wywnioskować z kodu
Na czym polega: CLAUDE.md ładuje się przy każdej wiadomości, więc na słowo jest najdroższym plikiem; usunięcie reguł, które Claude i tak wyczyta z kodu, dało 92% redukcji kontekstu bez straty jakości.
Jak stosować: Zejdź poniżej 200 linii (idealnie ~60). Notatki dla zespołu wrzucaj w komentarze HTML (nie liczą się do tokenów) i pamiętaj, że importy wciągają cały wskazany plik.
Na co uważać: Nie wycinaj reguł, których Claude naprawdę nie odgadnie z kodu — inaczej stracisz na jakości. Tnij tylko to, co redundantne wobec kodu.
9.Blokuj śmieciowe odczyty dwiema warstwami: .claudeignore + uprawnienia deny
Na czym polega: .claudeignore (doradczy) i twarde reguły deny w permissions (egzekwowane) razem powstrzymują wczytywanie node_modules, buildów i plików lock — samo .claudeignore dało 85,5% redukcji kontekstu.
Jak stosować: Dodaj .claudeignore w katalogu głównym oraz reguły deny w settings.json; wrzuć oba do repozytorium, żeby cały zespół zyskał te same oszczędności.
Na co uważać: Sam .claudeignore bywa ignorowany, bo jest tylko doradczy — bez warstwy uprawnień Claude może i tak coś przeczytać.
10.Wytnij narzut MCP i ustaw miesięczny limit wydatków
Na czym polega: Każdy serwer MCP ładuje pełny schemat (10–20 tys. tokenów) na starcie sesji, niezależnie od użycia; miesięczny limit to twardy sufit chroniący przed katastrofalnym rachunkiem.
Jak stosować: Odłączaj serwery nieużywane od kilku tygodni (albo zastąp je CLI), włącz enableToolSearch: true dla ładowania narzędzi na żądanie, a w ustawieniach Claude.ai ustaw miesięczny limit; jeśli masz własny system pamięci, wyłącz auto-memory przez /memory.
Na co uważać: Auto-memory wyłączaj tylko wtedy, gdy masz działający własny system pamięci — inaczej stracisz kontekst projektu. I pamiętaj: efekty oszczędności widać w dłuższym okresie, a nie po jednym „Hi”.