I spent $1,486 on Fable tokens so you don't have to

O czym jest ten film

1. Autor przepalił blisko 1500 dolarów na tokeny modelu Fable, żeby wypracować optymalne strategie ograniczania ich zużycia w Claude Code.
2. Wszystkie opisane metody mają — jego zdaniem — znikomy wpływ na jakość, a potrafią zredukować zużycie tokenów o co najmniej 50%.
3. RTK (Rust Token Killer) minifikuje wejścia i wyjścia wywołań narzędzi, usuwając powtarzalne, zbędne dane.
4. Kompresja semantyczna skraca prompty systemowe i pliki pamięci bez utraty znaczenia.
5. Zamiana logów na bazę SQLite pozwala odpytywać dane zamiast czytać ogromne pliki linijka po linijce.
6. Blokowanie wielkich odczytów zmusza model do próbkowania i celowanego wyszukiwania zamiast czytania całości.
7. Promptowanie po angielsku jest gęstsze informacyjnie i tańsze tokenowo niż większość innych języków.
8. Wpisanie zasady „oszczędności kontekstu” do promptu systemowego ogranicza zaglądanie do niepotrzebnych zasobów (kosztem części jakości).
9. Regularne sprawdzanie /context ujawnia ukryte zjadacze kontekstu, np. rozmnożone instancje MCP.
10. Ograniczenie poziomu „myślenia” (domyślnie niski, wysoki tylko na żądanie) daje 30–40% oszczędności bez utraty wyniku.

Redakcyjne tłumaczenie

Wstęp: dlaczego wydałem 1486 dolarów

Jak wiecie, Fable został nam cudownie przywrócony. W ciągu pierwszych czterech godzin od premiery wydałem ponad 1400 dolarów. Przez kolejne 24 godziny — jeszcze około 1000. Nie robiłem tego dlatego, że uwielbiam przepalać pieniądze, lecz po to, żeby ustalić, jakie są najlepsze i najbardziej optymalne strategie redukcji zużycia tokenów. Zakładam bowiem, że Fable i inne modele o bardzo wysokiej inteligencji jeszcze przez jakiś czas będą kosztowne obliczeniowo.

(Informacja dodatkowa: „Fable” to nazwa jednego z topowych modeli Claude; jego uruchamianie jest drogie, stąd cały film o oszczędzaniu tokenów. Claude Code to narzędzie CLI, w którym model działa jak agent, wywołując narzędzia w wewnętrznym terminalu.)

W tym materiale chcę pokazać wszystkie istotne metody ograniczania zużycia tokenów. Mają one praktycznie zerowy wpływ na jakość, a potrafią zmniejszyć całkowite zużycie o co najmniej 50%, a w niektórych przypadkach jeszcze więcej.

1.RTK — Rust Token Killer

Pierwsza strategia nazywa się RTK, czyli Rust Token Killer. Bierze ona wszystkie wejścia i wyjścia wywołań narzędzi w Claude Code i minifikuje oraz redukuje wszystko, co nie jest jawnie niezbędne do działania modelu.

Jeśli to nic wam nie mówi — spokojnie, mam demo. Chcę pokazać, jak wygląda wywołanie narzędzia, które Claude wykonuje wewnętrznie, z RTK i bez RTK. Dla niewtajemniczonych: Claude ma zwykle własny mały wewnętrzny terminal i za jego pomocą wysyła oraz odbiera żądania.

Bez RTK — udając, że to jakieś wewnętrzne wywołanie narzędzia — widać, że powtarzamy mnóstwo informacji. Standardowe wyjście, standardowe wyjście, standardowe wyjście, ustawianie fikstur, hydratacja mocków — w kółko to samo. Niestety Claude nie zna różnicy, a wasz rachunek za tokeny też nie. Gdy wysyłacie te wewnętrzne wywołania narzędzi — które Claude nieustannie wykonuje, setki, jeśli nie tysiące razy w typowej sesji — musi on czytać mnóstwo nieistotnych, powtarzających się informacji. To oczywista nieefektywność, którą można wyciąć.

RTK bierze wszystkie te dane i nakłada na nie nowy format, który daje dokładnie te same informacje potrzebne modelowi do wykonania zadania, ale przy znacznie mniejszej liczbie zmarnowanych tokenów. Zamiast wydawać, powiedzmy, 612 linii na jedno wywołanie — a to jest jeszcze przycięte — wydajemy tylko cztery linie. Zamiast 36 700 znaków — jedyne 177. Różnica przed i po zastosowaniu RTK to dosłownie 99% redukcji zużycia tokenów przy tym samym efekcie.

Nie każde wywołanie narzędzia tak wygląda. Część z nich nie jest nieefektywna, ale zdecydowana większość jest mniej wydajna, niż mogłaby być. Realistycznie zaoszczędzicie więc gdzieś między 30 a 50%.

2.Kompresja semantyczna

Druga metoda to kompresja semantyczna. Polega ona po prostu na wzięciu zdania i przepisaniu go tak, aby użyć jak najmniejszej liczby słów, nie usuwając przy tym znaczenia.

Pokażę demo — plik claude.md. Mamy tu prompt systemowy, który ktoś stworzył. Może nadyktował go głosowo, więc jest mniej wydajny niż zwykle. „Instrukcje projektowe i wytyczne dla asystenta AI. Cześć, bardzo dziękujemy za pomoc przy tym projekcie. Naprawdę doceniamy całą wykonaną pracę. Ten dokument zawiera wszystkie ważne instrukcje, wytyczne, zasady i konwencje, których prosimy przestrzegać…”. To jest umiejętność, której się uczy, ale w istocie wszystko powyżej ma zerową wartość informacyjną. Można przepisać ten sam akapit i zamiast „cześć, dziękujemy” i tak dalej napisać po prostu „Instrukcje projektowe i wytyczne dla systemu AI” — a wartość semantyczna pozostanie ta sama.

Kompresja semantyczna bierze więc wszystkie wasze prompty systemowe, pliki pamięci i cały pozostały kontekst w CLAUDE.md, po czym ściska to, usuwając rzeczy zbędne i nadmiarowe.

W praktyce uruchamiam instancję Claude na modelu Sonnet 5. Czyta ona wcześniej pokazany plik i przepisuje go z maksymalną gęstością informacji — czyli właśnie stosuje kompresję semantyczną. Następnie pokazuje liczbę słów przed i po. Wcześniej mieliśmy 865 słów, w większości śmieciowych. Po kompresji — 211. W przeliczeniu na tokeny zeszliśmy z 1125 do 274. To podejście można zastosować w całym projekcie, żeby znacząco obniżyć zużycie tokenów, a przy okazji poprawić zwięzłość i jakość odpowiedzi. Robię tak w każdym projekcie. Wszystkie te narzędzia rozdaję za darmo — linki w opisie.

3.Logi do SQLite

Trzecia metoda to zamiana logów na SQLite. Nie dotyczy każdego przypadku, bo Claude nie zawsze czyta logi, ale to przydatny trik, gdy z jakiegoś powodu musi sięgnąć do pliku logu. Logika jest podobna jak w RTK. Zamiast przekopywać się przez ogromny plik w poszukiwaniu tego, czego szukamy, używamy jego mocno skompresowanej formy w SQLite — czyli bazy danych zawierającej informacje o lokalizacji, miejscu i całej reszcie. Następnie abstrahujemy funkcję wyszukiwania do prostego polecenia wysyłanego do bazy, która robi to za nas.

W demie logującym Claude Code klient pisze: „Płatność nie przeszła dziś rano. Znajdź przyczynę źródłową w app.log. Uwaga: ma 5000 linii. Nie czytaj tego logu bezpośrednio. Zamiast tego użyj scripts/logq.py bez argumentów, żeby zobaczyć sposób użycia. Podaj przyczynę źródłową dotkniętego zamówienia i zacytuj numery linii”. Wcześniej musielibyśmy potraktować to jak gigantyczny blok tekstu i przeczytać każdą linię. Teraz po prostu odpytujemy bazę w SQLite. To niezwykle proste. Dostajemy oś czasu, konkretną linię, w której znajduje się każdy z logów, i wszystkie potrzebne informacje.

Tę samą logikę można zastosować do dowolnej bazy danych — arkusza Google, pliku CSV, czegokolwiek. Zadbajcie o to, żeby model nie przeszukiwał tego jako czystego tekstu, tylko korzystał z jakiejś funkcji bazodanowej, która filtruje za niego.

4.Blokowanie wielkich odczytów

Kolejna strategia to blokowanie ogromnych odczytów. W skrócie: niektóre zasoby są po prostu bardzo długie i nie wszystkie trzeba czytać od początku do końca. Zamiast wykonywać cały odczyt — podobnie jak przy SQLite — przekazujemy zadanie funkcji wyszukiwania, która wykonuje większość mechanicznej, ciężkiej pracy, a inteligencję Claude, OpenAI czy Codeksa wykorzystujemy tylko do poprawnego ustawienia filtrów.

W przykładzie każę Claude przeczytać wielki zrzut danych i sprawdzić, czy coś jest z nim nie tak. Zauważcie, że teraz mówi: „Plik ma 618 kilobajtów, czyli 20 000 linii — za duży, żeby bezpiecznie przeczytać go w jednym podejściu. Najpierw go spróbkuję, żeby zrozumieć jego strukturę”. Zamiast czytać całość, przeczyta początek, może koniec, a potem zastosuje własną logikę: „Czy potrafię dopasować którykolwiek z tych wzorców, żeby dużo efektywniej przeszukać te dane?”. Następnie zamiast tworzyć olbrzymie obciążenie tokenowe i czytać wszystkie 20 000 linii, tworzy jedną małą funkcję sed i podaje dokładny indeks miejsca, do którego chce zajrzeć. Zamiast 20 000 linii czytamy może 20 lub 30. To ogromne oszczędności na wywołaniach obejmujących bardzo długie zasoby. Nie robicie tego przy każdym wywołaniu, ale tam, gdzie czytacie duże zasoby, oszczędzicie jakieś 99%.

5.Prompotowanie po angielsku

Następna metoda jest prosta i większość z was już to robi, ale gorąco polecam prompotowanie po angielsku. Angielski jest po prostu znacznie gęstszy informacyjnie niż na przykład japoński, francuski czy niemiecki. Dzięki temu zwykle uzyskacie od 20 do nawet 80% (lub więcej) redukcji całkowitego zużycia tokenów. Warto też pamiętać, że większość tych modeli jest trenowana na angielskim.

Co ciekawe, jeśli używacie chińskich klas modeli, one również świetnie działają po angielsku. Ale sam mandaryński jest bardzo wydajny tokenowo, bo w dużej mierze jest językiem symbolicznym.

W przykładzie z prostym zapytaniem: po angielsku zużywa ono tylko 51 tokenów, po włosku 87, po niemiecku 118 (2,31×), a po japońsku około 74 (1,45×). Ta wskazówka jest mniej „nakazowa” — większość z was i tak pracuje po angielsku — ale miejcie to na uwadze, jeśli realizujecie projekty w innych językach.

(Informacja dodatkowa: dla polskiego użytkownika oznacza to, że instrukcje techniczne i prompty systemowe warto pisać po angielsku, nawet jeśli sama rozmowa z modelem toczy się po polsku.)

6.Oszczędność kontekstu w prompcie systemowym

Kolejny trik to wbudowanie w prompt systemowy jakiejś formy oszczędności kontekstu. Pokazaliśmy już optymalizację promptów przez kompresję semantyczną — skracanie zdania przy zachowaniu znaczenia. To jest podobne, tyle że wstawiamy regułę wysokiego poziomu: model sięgnie po zasób tylko wtedy, gdy jawnie go wskażemy.

Zaznaczam, że to jedna z tych sztuczek, które mogą istotnie obniżyć jakość. Fable i inne modele mają już solidne wbudowane schematy wyszukiwania — dzięki statystycznemu dopasowywaniu wzorców rozumieją, gdzie szukać. Ta reguła utrudni im znalezienie tego, czego chcecie, jeśli nie będziecie bardzo precyzyjni. Zakładam jednak, że jesteście gotowi być bardziej konkretni w zamian za lepsze zużycie.

Mam demo frugal-claude.md. Zadanie brzmi: „Klienci zgłaszają, że 10-procentowy kupon odejmuje przy płatności dziesięć razy za dużo. Znajdź błąd i zaproponuj jednoliniową poprawkę”. W kontekście umieściliśmy CLAUDE.md, który mówi: „Czytaj tylko pliki bezpośrednio istotne dla zadania. Pytaj przed rozszerzeniem zakresu ponad trzy pliki. Preferuj glob lub grep, żeby zlokalizować, a potem czytaj tylko dany fragment, nie cały katalog. Podsumuj dotychczasowe ustalenia, zanim zdecydujesz się czytać więcej. Nigdy nie czytaj plików generowanych, blokowych ani fikstur, chyba że wprost o to poproszono”.

W efekcie model zastosował grep i celowane wyszukiwania zamiast czytania całości. Wiele z tych taktyk sprowadza się do tego samego: zamiast czytać wszystko linia po linii, użyj inteligencji modelu do zbudowania mechanizmu filtrowania albo skryptu, który to zrobi. Fable i inne modele są w tym już nieźle, ale ta reguła mocno je do tego skłania.

7.Regularne sprawdzanie kontekstu (/context)

Zaawansowani użytkownicy pewnie się skrzywią, ale warto okresowo używać /context, żeby zobaczyć, co niepostrzeżenie zabiera wam kontekst. Kilka dni temu, korzystając z Fable, zorientowałem się, że mam uruchomionych jednocześnie kilkanaście instancji Chrome MCP — każda załadowana pełnym kontekstem. Wydałem przez to znacznie więcej, niż musiałem. Do tego Claude był przeciążony i mylił się, której instancji użyć. To zdarza się nawet doświadczonym weteranom.

(Informacja dodatkowa: MCP — Model Context Protocol — to standard podłączania modelu do zewnętrznych narzędzi i danych; każda instancja może dokładać sporo tokenów do okna kontekstu.)

Tak to mniej więcej wygląda: widzimy całe okno kontekstu modelu. Sonnet 5 ma prawie milionowe okno tokenów, co jest świetne. Sam prompt systemowy zjada około 10 000 tokenów, czyli 1%. Narzędzia, do których model ma dostęp — grep, glob, sed i tak dalej — to 16 400 tokenów. Moje pliki pamięci to około 10 700 tokenów. Umiejętności — około 7000. A wiadomości, które wymieniliśmy (każda liczona jako jedna wiadomość) — osiem tokenów. Łącznie zużyłem już około 8% budżetu.

Szybki trik: uruchomcie kolejną instancję Claude na innym, nieużywanym pulpicie i zapętlcie ją. Wpiszcie /loop i ustawcie obserwatora, który raz dziennie sprawdza, czy w waszym kontekście pojawiło się coś, czego nie było 24 godziny temu. Zrobi szybki zrzut wszystkich plików i rzeczy obecnych w kontekście. Dzięki temu dostaniecie okresowe powiadomienie, jeśli coś się wkradnie — jakiś MCP, duży zestaw umiejętności czy sterta danych — i będziecie mogli utrzymać kontekst naprawdę mały. Bo w gruncie rzeczy całe zarządzanie tokenami to zarządzanie kontekstem.

8.Ograniczenie „myślenia”

Ostatnia duża zmiana to ograniczenie myślenia. Claude potrafi myśleć na różnych poziomach. Myślenie to po prostu przepuszczanie tokenów przez pętlę w kółko, żeby coraz jaśniej zrozumieć problem i znaleźć lepsze rozwiązanie — podobnie jak przy burzy mózgów na kartce: tysiąc słów da wam większą jasność niż dziesięć.

Problem z adaptacyjnym myśleniem Claude — czyli takim, w którym model sam ustala sobie budżet myślenia — jest taki, że zwykle zużywa go znacznie więcej, niż faktycznie potrzeba. A przy naprawdę inteligentnych modelach jak Fable nie trzeba wcale dużo myśleć, żeby odpowiadać na pytania i rozwiązywać problemy. Dlatego zamiast domyślnie ustawiać bardzo wysokie myślenie — jak robi większość z was — powinniście domyślnie ustawiać bardzo niskie i włączać wyższe tylko wtedy, gdy naprawdę tego potrzebujecie. To ma ogromne znaczenie: poprawa rzędu 30–40%.

W demie stopniuję wysiłek na dwóch trybach myślenia. Pierwszy to niski. Zadaniem Claude jest znalezienie prostego błędu w bazie kodu, nic szczególnego. Pierwsze podejście na niskim wysiłku zajęło siedem tur, kosztowało 1028 tokenów, pochłonęło 18 sekund i 16 centów. Zapętliło się siedem razy — to mniej więcej limit dla trybu niskiego. Dla porównania tryb X-high, czyli najinteligentniejszy: dziewięć tur, 1363 tokeny wyjściowe, 21 sekund i jakieś 3 centy więcej.

Zaznaczę, że Claude potrafi sam regulować, ile myślenia poświęca różnym problemom. Mimo że mógł ograniczyć liczbę tur, nie zrobił tego — zużył więcej tur, żeby osiągnąć dokładnie ten sam wynik. Ten sam błąd znaleziony w obu przypadkach. X-high zużył około 1,3× więcej tokenów wyjściowych, dziewięć tur zamiast siedmiu. Gdybym powtórzył to jeszcze kilkanaście razy, różnica byłaby pewnie nieco większa — w moich testach zwykle bliżej 1,5×.

Prawdziwy wniosek: ustawcie tryb niski. Wysoki włączajcie tylko wtedy, gdy jest wprost potrzebny do konkretnej funkcji biznesowej. Nie ufajcie ślepo adaptacyjnemu myśleniu — bo, jeśli się zastanowić, to właśnie na tym zarabia Anthropic. Zarabia na całkowitej liczbie zużytych tokenów. Adaptacyjne myślenie jest fajne, ale prawdopodobnie będzie ciągnąć zużycie odrobinę w górę względem tego, co zrobilibyście sami, patrząc na ziejącą dziurę w portfelu.

Zakończenie

Mam nadzieję, że film się przydał. Wszystkie zasoby są w opisie — darmowe do pobrania, darmowa rejestracja. Jeśli lubicie takie treści i chcecie zmonetyzować swoje umiejętności w Claude Code, żeby zdobyć pierwszego klienta, zajrzyjcie do Maker School. To mój rozpisany dzień po dniu plan, w którym osobiście prowadzę was przez proces zdobycia pierwszego klienta na usługę AI — czyli systemy budowane w Claude Code, strony w Codeksie, automatyzacje backendowe w n8n, buildery „przeciągnij i upuść” i tak dalej. Gwarantuję pierwszego klienta w 90 dni albo zwracam pieniądze co do centa. Chętnie odpowiem na pytania w komentarzach.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Minifikuj wejścia i wyjścia narzędzi (RTK)

Na czym polega: Wywołania narzędzi w Claude Code często zawierają powtarzalne, zbędne dane. Reformatowanie ich do gęstszej postaci daje ten sam efekt przy drastycznie mniejszej liczbie tokenów (autor podaje nawet 99% redukcji na pojedynczych wywołaniach).

Jak stosować: Wprowadź warstwę, która czyści i kompresuje wyjścia narzędzi, zanim trafią z powrotem do modelu — usuwaj powtórzone linie standardowego wyjścia, zbędne komunikaty diagnostyczne i szum.

Na co uważać: Nie każde wywołanie jest nieefektywne — realny zysk to raczej 30–50%, nie 99%. Uważaj, by kompresja nie usunęła danych, których model faktycznie potrzebuje do decyzji.

2.Kompresuj semantycznie prompty i pliki pamięci

Na czym polega: Skracanie zdań do minimum słów bez utraty znaczenia. Uprzejmości, wstępy i powtórzenia mają zerową wartość informacyjną i tylko zjadają tokeny.

Jak stosować: Przepuść CLAUDE.md, prompty systemowe i pliki pamięci przez tańszy model (np. Sonnet) z instrukcją „przepisz z maksymalną gęstością informacji”. Autor zszedł z 1125 do 274 tokenów.

Na co uważać: Nie wytnij niuansów i wyjątków, które realnie sterują zachowaniem modelu. Zwięzłość nie może zamienić się w niejednoznaczność — po kompresji zweryfikuj, że wszystkie reguły dalej są jednoznaczne.

3.Odpytuj dane zamiast czytać wielkie pliki (logi → SQLite)

Na czym polega: Zamiast czytać ogromny plik logu linia po linii, ładujesz go do bazy (SQLite) i dajesz modelowi prostą komendę wyszukującą.

Jak stosować: Dla dużych logów/danych przygotuj skrypt (np. logq.py) i w prompcie jawnie zakaż czytania pliku wprost. To samo zadziała dla CSV czy arkuszy Google — filtruj funkcją bazodanową, nie tekstem.

Na co uważać: Wymaga wcześniejszej konfiguracji (import do bazy, skrypt). Nie opłaca się dla małych plików ani jednorazowych odczytów — narzut przygotowania przewyższy oszczędność.

4.Blokuj czytanie ogromnych zasobów w całości

Na czym polega: Model najpierw próbkuje strukturę dużego pliku, a potem sięga tylko po konkretny fragment (np. przez sed z indeksem), zamiast czytać wszystkie 20 000 linii.

Jak stosować: Ustaw regułę/limit rozmiaru, po przekroczeniu którego model ma spróbkować początek i koniec, wykryć wzorce i przeszukiwać celowo zamiast czytać całość.

Na co uważać: Próbkowanie może przeoczyć coś ukrytego w środku pliku, jeśli filtr został źle dobrany. Stosuj tam, gdzie da się wskazać wzorzec — nie przy danych bez struktury, gdzie liczy się każda linia.

5.Prompotuj techniczne instrukcje po angielsku

Na czym polega: Angielski jest gęstszy informacyjnie i lepiej pokrywa się z danymi treningowymi modeli, co obniża zużycie tokenów (w przykładzie niemiecki był 2,3× droższy).

Jak stosować: Prompty systemowe, reguły i instrukcje narzędziowe pisz po angielsku, nawet jeśli rozmowa merytoryczna toczy się po polsku. Zysk: 20–80%.

Na co uważać: Jakość odpowiedzi w języku docelowym (np. treści dla polskiego odbiorcy) jest ważniejsza niż oszczędność — nie wymuszaj angielskiego tam, gdzie zmienia to sens lub styl finalnego tekstu dla użytkownika.

6.Wbuduj regułę oszczędności kontekstu w prompt systemowy

Na czym polega: Reguła wysokiego poziomu: czytaj tylko pliki jawnie istotne, używaj glob/grep do lokalizacji, pytaj przed rozszerzeniem zakresu, nie czytaj plików generowanych i fikstur.

Jak stosować: Dopisz do CLAUDE.md twarde ograniczenia zakresu (np. „nie więcej niż trzy pliki bez pytania”) i preferencję wyszukiwania nad czytaniem katalogów.

Na co uważać: To realnie obniża jakość — model gorzej „domyśla się”, gdzie szukać. Działa dobrze tylko wtedy, gdy Ty jesteś bardzo precyzyjny w poleceniach. Świadomy kompromis jakość/koszt.

7.Regularnie audytuj kontekst przez /context

Na czym polega: Ukryci zjadacze kontekstu (rozmnożone instancje MCP, zestawy umiejętności, pliki pamięci) niepostrzeżenie podbijają koszty i dezorientują model.

Jak stosować: Okresowo wywołuj /context, żeby zobaczyć rozbicie zużycia. Rozważ osobną instancję z /loop, która raz dziennie robi zrzut i sygnalizuje, co doszło do kontekstu w ciągu 24 godzin.

Na co uważać: Zbyt agresywne przycinanie MCP/umiejętności może pozbawić model narzędzi, których naprawdę potrzebuje. Usuwaj to, co nieużywane, nie to, co akurat drogie.

8.Domyślnie ustawiaj niski poziom myślenia

Na czym polega: Adaptacyjne myślenie zwykle zużywa więcej tokenów, niż trzeba. Przy bardzo zdolnych modelach niski wysiłek często daje ten sam wynik co wysoki — w teście autora ten sam błąd znaleziono i na „low”, i na „X-high”, ale wysoki tryb kosztował ~1,3–1,5× więcej.

Jak stosować: Ustaw domyślnie niski poziom myślenia, a wysoki włączaj świadomie tylko dla trudnych, konkretnych zadań. Oszczędność rzędu 30–40%.

Na co uważać: Przy naprawdę złożonych problemach (architektura, subtelne bugi, długie rozumowanie) niski poziom może dać gorszy wynik — nie stosuj go ślepo tam, gdzie jakość rozumowania jest krytyczna.

9.Traktuj zarządzanie tokenami jako zarządzanie kontekstem

Na czym polega: Wspólny mianownik wszystkich technik: koszt to pochodna wielkości i czystości kontekstu, a nie osobny parametr do „ustawienia”.

Jak stosować: Zamiast szukać jednej magicznej opcji, systematycznie pilnuj, co wchodzi do okna kontekstu — narzędzia, pamięć, wyniki wywołań, prompty — i tnij to u źródła.

Na co uważać: Optymalizacja pojedynczej metody da niewiele, jeśli reszta kontekstu jest rozdmuchana. Patrz na całość budżetu, nie na pojedyncze wywołanie.

10.Pamiętaj o konflikcie interesów dostawcy modelu

Na czym polega: Dostawca (np. Anthropic) zarabia na liczbie zużytych tokenów, więc ustawienia domyślne — zwłaszcza adaptacyjne myślenie — mają tendencję do zawyżania zużycia względem Twojego optimum.

Jak stosować: Traktuj ustawienia domyślne jako punkt wyjścia do audytu, a nie zalecenie. Świadomie dobieraj tryb myślenia, zakres czytania i kontekst pod swój rachunek.

Na co uważać: To nie oznacza, że domyślne ustawienia są złośliwe — bywają wygodne i bezpieczne. Zbyt agresywne oszczędzanie potrafi kosztować więcej czasu i błędów, niż zaoszczędzi na tokenach. Licz koszt całkowity, nie tylko rachunek za API.