O czym jest ten film
- Omówienie oficjalnego artykułu Anthropic „Maksymalizacja wartości twojej sesji w Claude Code” z 14 sierpnia 2026 roku, rozłożonego na czynniki pierwsze.
- Wyjaśnienie, dlaczego to samo zadanie w narzędziu agentowym raz kosztuje więcej, a raz mniej — inaczej niż w klasycznej subskrypcji.
- Dwa mnożniki ceny tokena: wybór modelu i poziom rozumowania (effort), oraz fakt, że output jest kilkukrotnie droższy od inputu.
- Mechanika cache’u promptu (w filmie: „zakładki”) — zapis kosztuje trochę więcej, odczyt jest około dziesięciokrotnie tańszy.
- Lista działań, które unieważniają cache: zmiana modelu, zmiana efortu, przełączenie trybu szybkiego, kompresja czatu i upływ czasu.
- Obalenie dwóch mitów: że tryb
opusplanzawsze oszczędza oraz że cache i tak wygasa po pięciu minutach. - Analiza „wirtualnego plecaka” sesji: CLAUDE.md, skille, serwery MCP, subagenci, system prompt — i jak sprawdzić ich wagę komendą
/context. - Trzy poziomy kosztu tej samej prośby o plik: samodzielne szukanie, podanie ścieżki, dołączenie pliku małpą lub przez „attach as context”.
- Różnica między
/clear(darmowe, do nowego zadania) a/compact(zawsze kosztuje, do kontynuacji tego samego zadania) plus komenda/rewind. - Zasady pracy z pętlami (
/loop), celami (/goal) i subagentami — kiedy realnie oszczędzają, a kiedy generują czysty narzut.
Redakcyjne tłumaczenie
Wstęp: od karnetu na siłownię do taksometru
Jeszcze do niedawna praca z narzędziami AI wyglądała zupełnie inaczej. Płaciłeś za wybrane narzędzie, wpisywałeś swojego prompta, a wykonanie zadania w teorii kosztowało cię zawsze tyle samo. Wszystko zmieniło się, gdy do gry weszły narzędzia agentowe — takie jak Claude Code — w których wykonanie tego samego zadania raz może cię kosztować więcej, a raz mniej. Wszystko zależy od tego, w jaki sposób z narzędzia korzystasz. Na dodatek wraz z nowymi narzędziami pojawiły się limity: miesięczne, tygodniowe i pięciogodzinne.
Dlatego dziś po pierwsze rozbijemy całą tę tokenomię na czynniki pierwsze, a po drugie omówimy najlepsze praktyki od twórców Claude Code, dzięki którym wyciśniesz z narzędzia maksimum, a przy okazji oszczędzisz na limitach.
Materiał opiera się na oficjalnych wskazówkach, które 14 sierpnia 2026 roku udostępniła firma Anthropic — twórca Claude Code. Artykuł nosi tytuł „Maksymalizacja wartości twojej sesji w Claude Code”. Na górze ma sześć punktów, które streszczają całą resztę. Problem w tym, że samo przeczytanie tych punktów nic ci nie da, dopóki nie zrozumiesz, jak w narzędziach tego typu działa tokenomia. Dlatego zaczniemy od podstaw.
W dużym uproszczeniu: jeszcze kilka lat temu korzystanie z narzędzi AI przypominało zakup karnetu na siłownię. Kupowałeś karnet miesięczny albo roczny — czyli subskrypcję — i płaciłeś dokładnie tyle samo niezależnie od tego, czy przyszedłeś raz, czy dwadzieścia razy. Agent, z którym pracujesz dziś, przypomina raczej taksówkę z taksometrem. Trasa może być ta sama, ale rachunek będzie się różnił w zależności od tego, jak jedziesz.
Żeby zrozumieć, dlaczego licznik czasem bije szybciej, musisz poznać kilka rzeczy, które w ogóle wpływają na cenę — a tym samym na zużycie limitów.
Punkt pierwszy: cena tokena, czyli model i poziom rozumowania
Pierwsza rzecz, która ma znaczenie, to wybór silnika — modelu AI, którego użyjesz do danego zadania. To pierwszy mnożnik całego rachunku.
Sprawa wygląda tak: większy i mocniejszy model, na przykład Fable 5, świetnie nadaje się do złożonych, wieloetapowych zadań i trudnych, niejednoznacznych problemów. Mniejszy model, na przykład Sonnet 5, wybierasz do zadań rutynowych i prostszych. Nie ma tu żadnej większej filozofii: im potężniejszy model, tym z reguły zjada więcej tokenów, a przez to limity przepalają się znacznie szybciej.
I teraz rzecz ważna. Przeczytanie strony tekstu zajmuje nam, ludziom, chwilę. Napisanie całej strony tekstu ręcznie zajmuje o wiele dłużej. W przypadku modeli AI działa to bardzo podobnie. Model najpierw czyta wszystko, co mu dałeś — instrukcje systemowe, plik CLAUDE.md, twoje polecenie i całą dotychczasową rozmowę — a dopiero potem na tej podstawie tworzy odpowiedź. W skrócie: model w pierwszej kolejności zawsze zaczytuje kontekst.
I stąd wynika rzecz kluczowa: to, co model pisze — dane wyjściowe, output — jest o wiele droższe od tego, co model czyta, czyli od danych wejściowych, inputu. Weźmy tabelkę z cennikiem modeli Anthropic. Przy pozycji Claude Fable 5 widzimy, że input kosztuje 10 dolarów za milion tokenów, a output 50 dolarów za milion tokenów. Płacimy więc pięć razy więcej za to, co model pisze, niż za to, co czyta. To fakt, który będzie nam towarzyszył przez cały ten materiał — zdecydowanie warto go zapamiętać.
Kolejnym elementem wpływającym na cenę, a tym samym na zużycie limitów, jest poziom rozumowania — tak zwany effort level — który zmieniasz suwakiem w Claude Code. Do wyboru masz: low, medium, high, extra, max i ultra code.
(Informacja dodatkowa: nazewnictwo poziomów efortu bywa zmieniane między wersjami narzędzia — warto sprawdzić, jakie opcje faktycznie widzisz u siebie w suwaku.)
Najłatwiej pomyśleć o tym tak: model zapisuje swoje myśli na brudno, zanim ci odpowie. A skoro wiesz już, że zapisywanie — czyli output — jest w przypadku Fable 5 pięć razy droższe niż input, wniosek jest prosty. Suwak poziomu rozumowania zmienia to, ile model gada sam do siebie, zanim w ogóle ci odpowie. Im wyższy poziom rozumowania, tym dłuższy dialog wewnętrzny modelu. Model zapisuje o wiele więcej, co przekłada się na większą liczbę zużytych tokenów wyjściowych, a więc realny koszt — ale często również na lepszą jakość odpowiedzi. Coś za coś: dajesz wyższy effort do bardziej złożonych zadań, dzięki czemu model poradzi sobie lepiej, ale zapłacisz za to więcej, a na subskrypcji limit zejdzie ci szybciej.
Podsumowując punkt pierwszy: na cenę tokenów wpływa wybór modelu plus wybór poziomu rozumowania. I zostawię cię tu z jedną przekminą, do której za chwilę wrócę: to, kiedy zmieniasz model albo poziom rozumowania, może cię kosztować znacznie więcej niż to, na co je zmieniasz.
Punkt drugi: cache promptu, czyli zakładka w książce
To właśnie ten temat sprawił, że w ogóle usiadłem do przygotowania tego poradnika. Chodzi o cache promptu, który będziemy nazywać zakładką. Co ciekawe, prawie nikt na polskim YouTubie tego nie tłumaczy — przynajmniej ja takich materiałów nie znalazłem — a moim zdaniem to rzecz kluczowa.
Wyobraź sobie, że serwer Claude Code zostawia zakładkę — taką jak ta, którą zostawiasz w książce — w miejscu, w którym skończył czytać twoją rozmowę. To mechanizm pamięci podręcznej, czyli cache promptu. Claude zarządza nim samodzielnie.
Musisz zrozumieć dwie rzeczy. Po pierwsze, samo zostawienie zakładki kosztuje trochę więcej niż zwykłe czytanie — ale robisz to raz. Wysłałem wiadomość „cześć” dwadzieścia pięć minut temu. Wtedy uruchomiłem tę naszą zakładkę i ją zostawiłem. Cache się zapisał, kontekst się zaczytał. Widzimy, że mamy tu 9% wykorzystania: załadowała się wiadomość, pliki z pamięcią, narzędzia systemowe, skille i inne rzeczy — do tego jeszcze przejdziemy.
Po drugie, odczyt z już włożonej zakładki kosztuje jakieś dziesięć razy mniej niż zwykłe czytanie i korzystasz z niego przy każdym kolejnym zapytaniu. Kiedy wpisałem „jak możesz mi pomóc”, nie powstała nowa zakładka — Claude skorzystał z tej, która już była. Mówiąc po ludzku: płacisz raz odrobinę drożej na starcie, żeby potem za każdym razem płacić dużo taniej.
Gdy poprosisz Claude’a o naprawienie jednego testu albo zrobienie jakiejś rzeczy, najpewniej zobaczysz, że twoja jedna prośba to w środku kilka osobnych żądań wysłanych do serwera — i każde z nich niesie ze sobą całą rozmowę od początku sesji. Napisałem „jak możesz mi pomóc”, a Claude wysłał kilka żądań i dopiero potem odpisał. Wniosek, który chciałbym, żebyś z tej części zapamiętał: twoja jedna wiadomość w okienku Claude Code to tak naprawdę nie jest jedna wiadomość. Jeśli korzystasz z subskrypcji, nie widzisz tych cen na żywo, ale to dokładnie te same żądania, które zjadają twój limit.
Co unieważnia zakładkę
Zakładka działa dopóty, dopóki nie zmienisz początku książki. Jeśli dopiszesz coś na końcu — tak jak przy zwykłym kolejnym promptcie — zakładka zostaje.
Realnie na cache wpływają: zmiana modelu; zmiana poziomu rozumowania w trakcie rozmowy (to akurat mnie zaskoczyło i było powodem nagrania tego materiału); włączenie bądź wyłączenie trybu szybkiego, tak zwanego fast mode; /compact, czyli kompresja czatu; oraz zwykły upływ czasu.
Bez technicznego bełkotu: zmiana modelu w środku pracy — na przykład z Opus 5 na Fable 5, Sonnet albo Haiku — bądź zmiana poziomu rozumowania sprawia, że cała rozmowa czytana jest od nowa, przez co limit zużywa się szybciej. Co ciekawe, Claude Code czasami w aplikacji desktopowej pokazuje powiadomienie ostrzegające w trakcie rozmowy, że zmiana modelu czy poziomu rozumowania spowoduje ponowne przeczytanie całego kontekstu.
Ważna rzecz do zapamiętania: model i poziom rozumowania dobierasz przed pracą, a nie w trakcie. A jeśli w środku sesji naprawdę potrzebujesz innego modelu do jednego konkretnego fragmentu — nie przełączaj się. Zamiast tego odpal osobnego subagenta, czyli poproś o to Claude’a: „Hej, odpal mi subagenta, który zajmie się X, Y, Z”. On zrobi to na swoim modelu, a twoja zakładka zostanie nietknięta.
Mit pierwszy: opusplan zawsze oszczędza
W sieci możesz natrafić na radę, żeby włączyć sobie globalnie tryb opusplan. Robisz to, wpisując /opusplan w aplikacji desktopowej, w terminalu albo w IDE. Działa to tak, że gdy wchodzisz w tryb planowania — Shift+Tab, albo w aplikacji zmieniasz tryb na „plan” — Claude domyślnie przełącza się ze słabszego modelu, Sonnetu, na mocniejszy, czyli Opusa. A gdy z trybu planowania wychodzisz i zaczyna się prawdziwa robota, Claude wraca na tańszy model.
Wszystko super — w końcu drogi model jest wykorzystywany tam, gdzie faktycznie trzeba pomyśleć. Ale pamiętasz, o czym rozmawialiśmy przed chwilą? Każdy model ma swoją własną zakładkę. W momencie, gdy Claude Code przeskakuje z jednego modelu na drugi, ten drugi twojej zakładki nie ma. W rezultacie cała dotychczasowa rozmowa, cały kontekst, czytany jest przez niego od nowa.
Komenda opusplan przełącza model dwa razy przy każdym planowaniu: raz przy wejściu, raz przy wyjściu. Wyobraź sobie, że w ciągu dnia planujesz coś kilkanaście razy — wtedy kilkadziesiąt razy płacisz za przeczytanie tej samej rozmowy. Wniosek: ustawienie sprzedawane jako oszczędność w praktyce może ci zjeść limit dokładnie w tym momencie, w którym chcesz go oszczędzić.
Nie demonizujmy tego jednak. Uważam, że korzystanie z silniejszych modeli do planowania, a ze słabszych do wykonywania, to bardzo dobra praktyka — trzeba tylko robić to z głową i świadomie, mając z tyłu głowy, że każda zmiana modelu to nowy cache, nowa zakładka, przez co rozmowa wczytuje się od nowa, a limity schodzą szybciej.
Mit drugi: zakładka i tak wypada po pięciu minutach
Najpierw sama mechanika. Zakładka nie żyje wiecznie. Serwer trzyma ją tylko przez określony czas od twojej ostatniej wiadomości — fachowo nazywa się to czasem życia cache’u, TTL. Gdy ten czas minie, ktoś zamyka książkę i zakładka wypada. Wracasz po przerwie, piszesz wiadomość i cała rozmowa czytana jest od nowa, po pełnej stawce.
(Informacja dodatkowa: TTL to skrót od „time to live” — czas, przez jaki wpis w pamięci podręcznej pozostaje ważny.)
I sedno tego mitu: te pięć minut to prawda, ale wyłącznie dla osób korzystających z klucza API, a więc płacących za każde żądanie osobno. Nie dotyczy to osób, które korzystają z Claude’a w ramach subskrypcji Pro czy Max. Na subskrypcji zakładka żyje całą godzinę. Możesz iść zrobić kawę, odebrać telefon, wrócić po czterdziestu minutach — i sesja dalej jest żywa, dalej jest ciepła. Mówiąc po ludzku: krótka przerwa nic cię nie kosztuje. Kosztuje dopiero dłuższa, powyżej godziny.
Wysłałem tę wiadomość jedenaście minut temu, więc sesja nadal ma wszystko wczytane. Gdybym wrócił za pięćdziesiąt minut i napisał cokolwiek, cały kontekst czytałby się od nowa, co przełożyłoby się na większe zużycie limitów.
Wynika z tego jedna praktyczna rada: jeśli wiesz, że wychodzisz na dłużej, warto zrobić kompresję czatu, czyli /compact — przed przerwą, a nie po niej. Kompresja działa tak, że Claude i tak musi przeczytać całą rozmowę, ale zrobiona przy żywej, ciepłej zakładce czyta ją tanio, z pamięci podręcznej. Zrobiona po godzinie, po powrocie, gdy zakładka już wypadła, sprawia, że Claude czyta wszystko od nowa po pełnej stawce — a więc po prostu drożej. Osobiście nie korzystam zbyt często z /compact, mam na to inny sposób, ale o tym w dalszej części.
Punkt trzeci: wirtualny plecak, czyli kontekst startowy
Musisz wiedzieć, że na starcie każdej nowej sesji, jeszcze zanim Claude przejdzie do realizacji twojego zadania, już dźwiga wirtualny plecak. I żadna z tych rzeczy nie jest wysyłana tylko raz. Każdy plik czy wynik komendy leci ponownie w każdej turze — po każdej nowej wiadomości, nowym promptcie — aż do końca sesji. Oczywiście siedzi to w cache’u, więc jest tanio, ale tanio nie oznacza za darmo, a dodatkowo wszystkie te rzeczy zajmują miejsce w kontekście.
Zobaczmy to na przykładzie projektu Content Drop. Klikając w prawym dolnym rogu, możemy podejrzeć zużycie okna kontekstowego w danej sesji. Sesja jeszcze się nie rozpoczęła, więc mamy zero. Ale gdy wpiszę proste polecenie — na przykład „cześć” — okienko zaczyna się zapełniać: 5%, potem 8%. Przy tak prostym poleceniu sama wiadomość to zaledwie 2,9%, a resztę kontekstu zajmują takie rzeczy jak: narzędzia systemowe, pliki z pamięcią, skille dostępne w projekcie, serwery MCP, system prompt Claude’a, compact buffer oraz custom agents, czyli nasi subagenci działający w ramach projektu.
Jeżeli pracujesz w terminalu albo IDE, możesz wpisać /context — ta komenda działa dokładnie tak samo i pozwala w środku rozmowy podejrzeć, co ile kontekstu zajmuje.
Do zawartości plecaka wchodzi też CLAUDE.md — plik systemowy, który Claude czyta zawsze na starcie każdej sesji. Jest globalny, w głównym folderze Claude’a, ale występuje również per projekt. W moim projekcie Content Drop ten plik ma 116 linijek — i te 116 linijek zawsze na starcie jest wczytywane do kontekstu.
Ciekawie jest ze skillami. Claude ma dostęp do spisu treści skilli, a pełną instrukcję odczytuje dopiero wtedy, gdy faktycznie z nich korzysta. Dzięki temu wie, który skill wybrać, ale nie zaśmieca sobie kontekstu na starcie.
Wniosek jest taki: jeśli chcesz oszczędzić na limitach, nie warto instalować wszystkiego jak leci — mówię tu na przykład o skillach z internetu. Lepiej instalować tylko te rzeczy, które realnie przydadzą ci się w danym projekcie. Jeśli mam projekt YouTube Rob, gdzie trzymam rzeczy związane z YouTubem, to nie potrzebuję tam żadnych skilli do tworzenia stron internetowych. A jeśli mam projekt, w którym tworzę aplikację internetową, to nie potrzebuję tam skilla do pisania scenariuszy na YouTube. To wszystko zajmuje kontekst.
Kolejna rada: plik CLAUDE.md powinien być schludny. Anthropic zaleca chyba 150–200 linii — ja mam 116. Traktuj ten dokument jak spis treści, indeks dla Claude’a, dzięki któremu wie, kiedy i z czego ma korzystać. Nie ma tam zapisanych wprost reguł i procedur — do tego służą skille. U mnie w środku jest struktura repozytorium i opis projektów: gdzie co Claude znajdzie i ewentualnie kiedy ma z tego skorzystać, a nie co ma w nich robić.
Właśnie dlatego warto raz na jakiś czas zrobić porządek w swoich projektach — i pamiętać, że jak posprzątasz raz, to za dwa, trzy, cztery tygodnie znów narobi się bałagan. Traktuj to nie jak jednorazowe sprzątanie, tylko jak cykliczną higienę, niezbędną do tego, żeby Claude działał prawidłowo.
Podsumowanie sekcji: traktuj CLAUDE.md jak indeks, instaluj tylko potrzebne skille i serwery MCP, a wagę sesji sprawdzisz komendą /context.
Trzy poziomy kosztu tej samej prośby
Jest jeszcze druga rzecz, na którą chcę zwrócić uwagę przy kontekście. Wyobraź sobie sytuację: wchodzę do Claude’a, wybieram projekt YouTube Rob i mówię: „Scenariusz najnowszego filmu mi się nie podoba. Popraw go”.
Z pozoru brzmi to jak proste zadanie, ale zanim Claude w ogóle zacznie poprawiać scenariusz, najpierw musi go znaleźć. W tym celu przeszuka mój projekt, otworzy po drodze kilka plików — a wszystko, co otworzy, zostaje w jego kontekście na długo po tym, jak przestało być potrzebne. I tu dochodzimy do rzeczy ważnej: ta sama prośba ma trzy różne poziomy kosztu.
Wariant pierwszy — najdroższy. „Scenariusz najnowszego filmu mi się nie podoba, popraw go”. Claude sam szuka, a wszystko, co po drodze otworzy, zostaje w kontekście sesji.
Wariant drugi — pośredni. Klikam prawym przyciskiem na plik ze scenariuszem, na Macu z wciśniętym Option, i kopiuję ścieżkę. Prompt jest w teorii ten sam, ale wskazałem Claude’owi dokładną lokalizację pliku, dzięki czemu odczyta on ten jeden plik i nie będzie musiał zaczytywać wszystkich scenariuszy. Nadal jednak nie jest to rozwiązanie idealne.
Wariant trzeci — według artykułu Anthropic najtańszy. Zamiast wklejać lokalizację, przechodzisz do plików, znajdujesz właściwy plik, klikasz prawym przyciskiem i wybierasz „attach as context”. To ten sam mechanizm, co wpisanie małpy i oznaczenie pliku. Dzięki temu plik jest wysyłany do Claude’a razem z twoją wiadomością. Claude nie musi go otwierać, szukać ani nigdzie przechodzić — po prostu ma go w twojej wiadomości.
Po ludzku działa to tak, jakbyś prosił asystenta o znalezienie konkretnej informacji w teczce Kowalskiego. W pierwszym wariancie asystent nawet nie wie, gdzie ta teczka leży — musi ustalić miejsce, pójść, poszukać, wrócić i dopiero wtedy zaczyna pracę. W drugim wariancie wskazujesz mu miejsce („teczka jest w archiwum”), więc nadal musi pójść do archiwum, znaleźć teczkę, wrócić — i dopiero wtedy zaczyna pracę. W trzecim wariancie dajesz mu teczkę Kowalskiego do ręki, a on od razu zaczyna szukać informacji.
I tu ważne doprecyzowanie, bo łatwo pomylić to z zakładką z poprzedniego punktu. Wskazanie pliku przez małpę nie ratuje zakładki i nie ma z nią nic wspólnego. Plik zostaje dopisany do rozmowy, do prompta, na samym końcu — a dopisywanie na końcu to przypadek idealny, bo zakładka zostaje na swoim miejscu. To, co małpa realnie oszczędza, to cała jedna tura: bez niej Claude musi najpierw napisać prośbę o otwarcie pliku, a pisanie to output, czyli ta najdroższa stawka. Dopiero potem dostaje plik i zaczyna robotę.
Zapamiętaj więc: małpa nie ratuje cię przed drogim czytaniem od nowa i nie ma wpływu na cache. Ratuje cię natomiast przed niepotrzebną wycieczką po pliki, która generuje tokeny wyjściowe — a te są dużo droższe.
Punkt czwarty: długość sesji
Skoro wiesz już, co siedzi w wirtualnym plecaku, czas na pytanie, jak długo to wszystko w nim zostaje. Odpowiedź jest prosta i krótka: do końca sesji. I właśnie dlatego jedna długa sesja kosztuje więcej niż ta sama robota rozbita na kilka krótszych.
Wyobraź sobie spotkanie, na którym przed każdym nowym punktem agendy ktoś odczytuje na głos wszystkie dotychczasowe ustalenia. Przy czterdziestym punkcie ta osoba czyta trzydzieści dziewięć poprzednich. Przypał, prawda? Dokładnie tak rośnie licznik z każdą kolejną turą, z każdym kolejnym promptem.
Na szczęście mamy dwa narzędzia — i, co najciekawsze, sporo osób używa ich dokładnie odwrotnie, niż powinno.
Pierwsze narzędzie to /clear. Po wpisaniu tej komendy cała sesja zostaje wyczyszczona — nie ma tu żadnej wiadomości. W dużym skrócie kasuje ona całą historię rozmowy: protokół ląduje w koszu, a ty zaczynasz od czystej kartki. I co ważne: samo czyszczenie nic cię nie kosztuje.
Drugie narzędzie to /compact, o którym wspominaliśmy przy okazji zakładki. Po wpisaniu komendy Claude czyta całą dotychczasową rozmowę i przepisuje ją do formy krótkiego streszczenia. Protokół zostaje, ale w wersji skróconej — i dlatego kompresja kosztuje zawsze, bo żeby coś streścić, trzeba to najpierw w całości przeczytać.
Złota reguła, którą łatwo zapamiętać: czyścisz kontekst, gdy zaczynasz zupełnie nowe zadanie. Kompresujesz, gdy wcześniejsza część tego samego zadania jest już skończona, ale dalsza część jej potrzebuje, żeby dokończyć realizację czegoś złożonego.
I tu dochodzimy do asymetrii, o której mało kto mówi: /clear jest niedoceniane, a /compact przeceniane. Ludzie znacznie częściej odpalają /compact z przyzwyczajenia, a bardzo często wystarczyłoby wpisać zwykłe, darmowe /clear.
Dwa triki do zarządzania sesją
Trik pierwszy — działa lepiej w IDE albo terminalu. Jeśli chcesz kiedykolwiek wrócić do danej sesji, polecam przed wpisaniem /clear zmienić jej nazwę komendą /rename. Nadaję sesji nazwę, na przykład „YouTube Rob 24”, kopiuję ją, wpisuję /clear i czyszczę sesję. Potem wystarczy wpisać claude --resume YouTube Rob 24 i widzę dwie różne sesje: tę po kompakcie i tę przed. Klikam tę sprzed — i nadal mam całą sesję, mimo że zrobiłem /clear.
(Informacja dodatkowa: autor pracuje w Warp, które w momencie nagrania było dostępne bezpłatnie; ten sam mechanizm wznawiania sesji działa też w innych terminalach.)
Trik drugi. Kompresja działa lepiej, kiedy opiszesz Claude’owi, co ma zostawić w pamięci — a więc dodasz do /compact krótką notatkę, krótką instrukcję. Osobiście preferuję korzystanie z paczki skilli od Mata Pokoka. Jest tam skill „handoff”, który działa bardzo podobnie do /compact, ale moim zdaniem lepiej: Claude zapisuje te handoffy, możemy je edytować, szybciej podejrzeć, wrócić do nich. To dokładnie ta sama filozofia. Zamiast zdawać się na to, co Claude sam streści, spisujesz stan pracy do pliku razem z nim, czyścisz czat i w nowej sesji podajesz ten plik małpą. W rezultacie masz większą kontrolę nad tym, co dostaje kolejna sesja — ale część pracy przechodzi z modelu na ciebie.
Jest jeszcze trzecia komenda, o której mówi się najrzadziej: /rewind. Dzięki niej możesz cofnąć ostatnie tury w ramach sesji. Jeżeli rozmowa z Claude’em pójdzie w złą stronę, wpisując /rewind albo klikając dwa razy Escape, cofasz się do wiadomości sprzed momentu, w którym zaczęło się źle dziać. Ucinasz końcówkę — a skoro ucinasz końcówkę, wszystko wcześniejsze zostaje w zakładce i nie kosztuje cię nic albo kosztuje bardzo, bardzo mało. Uczciwie: przetestuj to najpierw na drobnym zadaniu, zanim zaczniesz na tym polegać przy czymś ważnym, żeby się niemiło nie zaskoczyć.
Dwie rzeczy, przez które długa sesja zjada limit szybciej
Pierwsza to tury, które dzieją się wtedy, gdy ty nic nie wpisujesz. Przykładem jest pętla — komenda /loop, która powtarza zadanie co ustalony czas. Każde odpalenie pętli działa jak pełna tura w sesji, w której ją ustawiłeś. Claude ciągnie ze sobą całą historię sesji za każdym razem, gdy pętla się uruchomi. I to nie jest sposób na utrzymanie zakładki przy życiu. Wniosek: pętle odpalaj z osobnego, czystego okienka — nigdy w tej sesji, w której pracujesz.
Druga rzecz to bliski kuzyn pętli, czyli /goal. Zamiast powtarzać zadanie co ileś minut, dajesz Claude’owi warunek ukończenia — na przykład: wszystkie opisy filmów w projekcie mają mieć zaktualizowany link — a Claude pracuje tura po turze tak długo, aż warunek zostanie spełniony. Po każdej turze mały, tani model, tak zwany walidator, sprawdza, czy to już.
Po ludzku: pętla to budzik, a cel to lista rzeczy do odhaczenia. Budzik dzwoni co ileś czasu, cel odhacza aż do skutku. Kiedy tego używać? Przy większych zadaniach z mierzalnym końcem. I obowiązuje dokładnie ta sama zasada co przy pętli: każda kolejna tura niesie ze sobą całą historię, więc cel odpalaj z czystej, świeżej sesji, najlepiej zaraz po /clear.
Subagenci
Subagenci to pomocnicy Claude’a z własnym, osobnym oknem kontekstowym. Subagent dostaje własne instrukcje, narzędzia i twój plik CLAUDE.md, ale nie dostaje twojej dotychczasowej rozmowy. Po prostu robi swoje. Do ciebie wraca sama odpowiedź, a cała reszta znika.
Kiedy to się opłaca? Gdy zadanie produkuje górę outputu, której nie musisz trzymać w głównej sesji — na przykład przejrzenie długiego loga, czyli pliku z surową historią działania jakiegoś narzędzia. Claude często sam sięga po subagenta przy takich rzeczach, a jeśli tego nie zrobi, wystarczy poprosić go wprost na czacie: „poproś o to subagenta z modelem X”.
Warto jednak uważać też w drugą stronę: przy małym zadaniu subagent to czysty narzut. Nie zna twojej rozmowy, więc część rzeczy musi przeczytać od nowa, na własny rachunek. I pamiętaj — do głównej sesji wraca tylko to, co subagent uznał za warte zaraportowania.
Podsumowanie
Pierwszy element wpływający na to, jak szybko schodzą twoje limity, to dobór odpowiedniego modelu i poziomu rozumowania jeszcze przed realizacją zadania. Jeżeli będziesz przeskakiwał z jednego modelu na drugi albo z jednego poziomu efortu na drugi w trakcie pracy, limity przepalisz automatycznie szybciej.
Punkt drugi to cache promptu, czyli nasza zakładka. Na starcie zapisywana jest nieco drożej, natomiast odczyt przy każdej turze jest dziesięć razy tańszy. Przy korzystaniu przez API cache trwa pięć minut, przy subskrypcji — godzinę. Jeśli wrócisz do zadania po godzinie, Claude musi zaczytać do kontekstu całą waszą rozmowę, więc zjada więcej limitów. Przypominam też o micie, z którym się rozprawiliśmy: opusplan może wyjść taniej w konkretnych przypadkach, ale w ogólnym rozrachunku wyjdzie znacznie drożej, jeśli nie będziesz korzystać z niego świadomie.
Punkt trzeci to kontekst — plecak, który Claude ładuje na starcie każdej sesji. CLAUDE.md traktujemy jako indeks, a nie jakąś Wikipedię projektu. W projekcie instalujesz tylko potrzebne skille i serwery MCP. Wagę sesji sprawdzisz komendą /context albo klikając w prawym dolnym rogu ekranu w aplikacji desktopowej. Jeśli chodzi o przekazywanie plików, najtaniej wychodzi oznaczanie ich małpą — plik jest wtedy wysyłany razem z twoją wiadomością, a ty oszczędzasz całą turę. Wskazujesz to raz na rozmowę, plik jest załadowany do kontekstu i Claude nie musi go szukać ani przepalać limitów na rzeczy, które wcale nie są potrzebne.
Punkt czwarty to długość sesji. Wiesz już, że każda następna tura czyta poprzednie tury, więc kilka krótszych sesji jest tańszych niż jedna długa. Wiesz też, jak działa /clear i /compact: /clear wpisujesz, gdy przechodzisz do nowego zadania, i jest darmowy; /compact używasz, kiedy skończysz dany fragment zadania, kontekst jest już trochę zapełniony, a ty chcesz przenieść jego wybraną część do nowej sesji — i to oczywiście kosztuje. Wiesz też, że jest /rewind albo dwukrotne Escape — taki darmowy ratunek, gdy Claude zaczyna zbaczać: zamiast męczyć go dalej albo odpalać nową sesję, wracasz do miejsca sprzed awarii. Wiesz, że /loop i /goal — budzik i cel — najlepiej odpalać z czystego okna, z nowej sesji. I wiesz, że subagentom warto oddelegowywać zadania z górą outputu, a nie warto oddawać im zadań miałkich, przy których agent i tak musiałby zaczytać cały kontekst projektu.
Mam nadzieję, że ten materiał otworzył ci nieco oczy na to, jak działa cała ta tokenomia i co realnie wpływa na twoje zużycie limitów w Claude Code.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Output kosztuje wielokrotnie więcej niż input
Na czym polega: Model najpierw czyta cały kontekst (instrukcje systemowe, CLAUDE.md, całą rozmowę), a dopiero potem pisze odpowiedź. W cenniku Fable 5 input to 10 dolarów za milion tokenów, a output — 50 dolarów, czyli pięciokrotnie więcej.
Jak stosować: Optymalizuj przede wszystkim to, ile model pisze, a nie tylko to, ile czyta. Każda oszczędzona tura, w której model musiał napisać prośbę o otwarcie pliku czy rozpisać plan, to realna oszczędność limitu.
Na co uważać: Nie wyciągaj z tego wniosku, że wczytywanie dużych plików jest darmowe — input jest tańszy, ale nie zerowy, a dodatkowo zajmuje okno kontekstowe, które będzie się przenosić przez wszystkie kolejne tury sesji.
2.Model i effort ustawia się przed pracą, nie w trakcie
Na czym polega: Zmiana modelu albo poziomu rozumowania w środku rozmowy unieważnia cache promptu. Cały dotychczasowy kontekst zostaje przeczytany od nowa, po pełnej stawce.
Jak stosować: Zanim wpiszesz pierwszy prompt, zdecyduj: mocniejszy model i wyższy effort do zadań złożonych i niejednoznacznych, słabszy model i niższy effort do rutyny. Potem trzymaj się tego wyboru do końca sesji.
Na co uważać: Do listy rzeczy unieważniających cache należą również przełączanie trybu szybkiego (fast mode) i /compact — nie tylko zmiana modelu. Aplikacja desktopowa czasem ostrzega przed takim przeładowaniem, ale nie zawsze.
3.Jedna wiadomość to nie jedno żądanie
Na czym polega: Jedna prośba w okienku Claude Code rozbija się wewnętrznie na kilka osobnych żądań do serwera, a każde z nich niesie ze sobą całą rozmowę od początku sesji.
Jak stosować: Formułuj prośby tak, żeby model potrzebował mniej tur na ich realizację — podawaj gotowe pliki, konkretny zakres i jasne kryterium ukończenia zamiast ogólników.
Na co uważać: Na subskrypcji nie widzisz tych kosztów na żywo, więc łatwo zbudować fałszywe poczucie, że „napisałem tylko jedno zdanie”. Zużycie limitu jest funkcją liczby tur, a nie długości twojej wiadomości.
4.Cache na subskrypcji żyje godzinę, nie pięć minut
Na czym polega: Pięciominutowy czas życia cache’u dotyczy korzystania przez klucz API, gdzie płacisz za każde żądanie osobno. Na subskrypcji Pro i Max zakładka trzyma się przez godzinę od ostatniej wiadomości.
Jak stosować: Krótkie przerwy — kawa, telefon, spotkanie do czterdziestu minut — możesz robić bez obaw. Sesja pozostaje „ciepła” i wracasz do niej praktycznie za darmo.
Na co uważać: Godzina liczy się od ostatniej wiadomości, nie od początku sesji. Po jej przekroczeniu pierwszy prompt po powrocie przeczyta całą rozmowę po pełnej stawce.
5./compact rób przed przerwą, nigdy po niej
Na czym polega: Kompresja zawsze wymaga przeczytania całej rozmowy. Wykonana przy żywym cache’u czyta ją tanio z pamięci podręcznej; wykonana po wygaśnięciu cache’u — po pełnej stawce.
Jak stosować: Wiesz, że wychodzisz na dłużej niż godzinę? Wpisz /compact zanim zamkniesz laptopa. To ta sama operacja, tylko kilkukrotnie tańsza.
Na co uważać: /compact sam z siebie unieważnia zakładkę, więc nie jest to operacja „przy okazji” — nie odpalaj go nawykowo w środku sprawnie idącej pracy.
6./clear jest niedoceniane, /compact przeceniane
Na czym polega: /clear kasuje historię rozmowy i jest całkowicie darmowy. /compact streszcza rozmowę i kosztuje zawsze. Wiele osób używa /compact z przyzwyczajenia tam, gdzie wystarczyłby /clear.
Jak stosować: Reguła: czyścisz, gdy zaczynasz zupełnie nowe zadanie; kompresujesz, gdy skończony fragment tego samego zadania jest potrzebny do dokończenia reszty.
Na co uważać: Przed /clear warto nazwać sesję komendą /rename — dzięki temu odzyskasz ją później przez claude --resume. Bez nazwy trudniej odnaleźć właściwą sesję na liście.
7.opusplan nie jest darmową oszczędnością
Na czym polega: Każdy model ma osobny cache. Tryb opusplan przełącza model dwa razy przy każdym wejściu w tryb planowania i wyjściu z niego, więc przy kilkunastu planowaniach dziennie kilkadziesiąt razy płacisz za przeczytanie tej samej rozmowy.
Jak stosować: Samą praktykę — mocniejszy model do planowania, słabszy do wykonania — autor uznaje za bardzo dobrą. Rób to jednak świadomie: planuj rzadziej i w większych blokach, zamiast wskakiwać w tryb planowania kilkanaście razy w jednej sesji.
Na co uważać: Nie traktuj tego jako zakazu — to nie jest ustawienie „złe”, tylko takie, którego koszt trzeba mieć z tyłu głowy. W konkretnych układach pracy nadal może wyjść taniej.
8.Trzy poziomy kosztu tej samej prośby o plik
Na czym polega: Najdroższe jest kazać Claude’owi samemu szukać pliku; taniej jest podać ścieżkę; najtaniej — dołączyć plik małpą albo przez „attach as context”, dzięki czemu leci on razem z twoją wiadomością.
Jak stosować: Zanim wyślesz prompta, zadaj sobie pytanie: czy Claude wie, gdzie jest to, o czym mówię? Jeśli nie, dołącz plik bezpośrednio. Oszczędzasz całą turę, w której model musiałby napisać prośbę o otwarcie pliku.
Na co uważać: To nie ratuje cache’u — małpa nie ma z zakładką nic wspólnego. Plik dopisuje się na końcu rozmowy, co jest bezpieczne dla cache’u, ale nie chroni cię przed ponownym czytaniem kontekstu po wygaśnięciu zakładki.
9.CLAUDE.md to indeks, a nie Wikipedia projektu
Na czym polega: Plik CLAUDE.md jest wczytywany na starcie każdej sesji i leci ponownie w każdej turze. Anthropic zaleca — według autora — około 150–200 linii; autor trzyma się 116.
Jak stosować: Zapisuj w nim strukturę repozytorium, opis projektów i wskazówki, kiedy z czego korzystać. Reguły i procedury przenieś do skilli — tych Claude czyta tylko spis treści, a pełną instrukcję dopiero w momencie użycia.
Na co uważać: To nie jest jednorazowe sprzątanie. Po dwóch–czterech tygodniach bałagan wraca, więc traktuj przegląd CLAUDE.md, skilli i serwerów MCP jak cykliczną higienę. Nie instaluj skilli z internetu „na zapas” — każdy zajmuje kontekst w każdej sesji tego projektu.
10./loop i /goal odpalaj z czystej sesji, a subagentów używaj selektywnie
Na czym polega: Każde uruchomienie pętli lub kolejna tura celu ciągnie ze sobą całą historię sesji, w której zostały ustawione. Subagent z kolei ma własne okno kontekstowe i nie widzi twojej rozmowy — do głównej sesji wraca tylko jego odpowiedź.
Jak stosować: /loop i /goal uruchamiaj z osobnego, świeżego okna, najlepiej zaraz po /clear. Subagentom oddelegowuj zadania produkujące górę outputu, którego nie musisz trzymać w głównej sesji — na przykład przeglądanie długich logów. Możesz też poprosić o subagenta zamiast przełączać model w środku sesji.
Na co uważać: Przy małym zadaniu subagent to czysty narzut — nie zna twojej rozmowy, więc część rzeczy musi przeczytać od nowa na własny rachunek. Pamiętaj też, że wraca tylko to, co subagent sam uznał za warte zaraportowania.