Anthropic: "How To Maximize Your Claude Code"

O czym jest ten film

1. Autor streszcza artykuł Anthropic o maksymalizowaniu efektywności sesji Claude Code i wybiera z niego sześć najważniejszych wniosków.
2. Wnioski dzielą się na trzy kategorie: zarządzanie kontekstem, efektywność zasobów i redukcja szumu.
3. Komenda /clear między zadaniami to według autora najprostszy i najbardziej niedoceniany sposób na oszczędzanie tokenów.
4. /compact warto uruchamiać, zanim minie godzina od ostatniej wiadomości — po tym czasie cache wygasa i kompaktowanie kosztuje więcej, niż daje.
5. Komenda /context pokazuje, ile tokenów ładuje się do sesji, zanim jeszcze cokolwiek napiszesz — u autora było to 47 tysięcy na Opusie 5.
6. Główne źródło tego obciążenia to nagromadzona pamięć, serwery MCP, skille i własni agenci instalowani globalnie i zapominani.
7. Zmiana modelu lub poziomu wysiłku w trakcie sesji unieważnia cache — lepiej zlecić zadanie subagentowi.
8. Wzmianka pliku przez @ jest tańsza niż kazanie modelowi szukać pliku po katalogach.
9. Hałaśliwe komendy CLI warto uruchamiać w subagentach, które zwrócą tylko wyciąg zamiast całego wyjścia.
10. Uzasadnienie ekonomiczne: obecne plany ryczałtowe są mocno dotowane, więc rozrzutność nie boli — ale przy modelach open source i własnych agentach zacznie.

Redakcyjne tłumaczenie

Wstęp

Anthropic opublikował właśnie artykuł o tym, jak maksymalizować skuteczność sesji w Claude Code. Tekst jest dość długi, więc wyciągnąłem z niego sześć najważniejszych wniosków — i to właśnie omówimy w tym krótkim materiale.

1.Czyść kontekst między zadaniami

Pierwsza rzecz, której moim zdaniem wciąż zbyt mało osób używa naprawdę intensywnie: /clear między zadaniami. Mówimy tu o komendzie w terminalu, która czyści kontekst.

Wartość jest prosta: usuwasz w ten sposób cały kontekst, którego już nie potrzebujesz. Jeśli przeskakujesz do czegoś, gdzie nie jest ci potrzebna cała historia tego, co przed chwilą robiłeś, powinieneś wyczyścić kontekst do zera.

To jeden z powodów — przynajmniej w kontekście programowania — dla których lubię narzędzia oparte na specyfikacjach. Zapisują każdy etap do artefaktu, który zawiera cały potrzebny kontekst, dzięki czemu można czyścić sesję cały czas.

(Informacja dodatkowa: „narzędzia oparte na specyfikacjach” to podejście, w którym plan pracy i jej wyniki trzymane są w plikach w repozytorium, a nie w pamięci rozmowy — sesję można wtedy resetować bez utraty postępu.)

Zawsze mnie dziwi, gdy ludzie narzekają, że nieustannie kończą im się tokeny na planach typu Claude Max. Mnie to się po prostu nie zdarza — i sądzę, że właśnie dlatego, że bardzo dużo czyszczę.

2.Kiedy naprawdę używać komendy compact

Kolejna sprawa: kiedy właściwie sięgać po /compact? Wydaje mi się, że wiele osób używa jej w sytuacjach, w których w dłuższej perspektywie kosztuje ich to więcej tokenów, a nie mniej.

Rzecz w tym: jeśli od twojej ostatniej wiadomości w sesji minęła więcej niż godzina, a potem uruchamiasz /compact, to w praktyce straciłeś cały cache.

Jeśli nie wiesz, jak to działa: modele językowe cache’ują wysyłane wiadomości. Ten cache jest istotny, bo zamiast wysyłać cały kontekst raz za razem, dostawca ma go już zapisany — Claude go zna i ma do niego dostęp, ale nie musi przetwarzać tych samych informacji od nowa za każdym razem.

Jeśli więc uruchomisz /compact po upływie godziny, wymuszasz ponowne przeczytanie wszystkiego, co tam było, tylko po to, żeby wykonać samo kompaktowanie.

Jeżeli naprawdę korzystasz z tej komendy — ja używam jej rzadko, wolę /clear — powinieneś uruchamiać ją nieco regularniej. Myśl w kategoriach: „minęła godzina, chcę zdążyć z compactem, zanim to nastąpi”.

To nie jest coś, co da ci szaloną poprawę jakości działania. To rzecz, która po prostu porządkuje twoje koszty w czasie i sprawia, że zarządzanie zużyciem tokenów staje się dużo znośniejsze.

3.Komenda /context — zobacz, co ładuje się przed pierwszą wiadomością

Kolejna rzecz to komenda /context. Jeśli jej jeszcze nie używałeś: wejdź do dowolnego swojego projektu i ją uruchom. Pokaże ci, co dokładnie ładuje się do sesji, zanim jakakolwiek wiadomość zostanie w ogóle wysłana — w tym wypadku do Anthropic.

U mnie widać na przykład, że w oknie kontekstowym Opusa 5 ładuje się 47 tysięcy tokenów, zanim cokolwiek napisałem. To dość szalone, jeśli się nad tym zastanowić. Kto pamięta czasy vibe codingu i pierwszych agentowych workflowów, gdy okna kontekstowe były naprawdę małe, ten wie, że próbowało się wtedy pisać całe bloki kodu mieszczące się w mniejszej liczbie tokenów niż to. A dziś to jest domyślny narzut, który ładuje się, zanim cokolwiek wyślemy.

Jeśli nigdy nie uruchomiłeś tej komendy, gorąco polecam — choćby po to, żeby zobaczyć, co się dzieje, zanim cokolwiek się zacznie.

W moim przypadku widać na przykład 11 tysięcy tokenów przypisanych do pamięci. Można wtedy uruchomić komendę /memory i przejrzeć, co właściwie jest zapisane: czy to pamięć użytkownika, czy pamięć konkretnego projektu, czy może dzieje się coś jeszcze, co powoduje tak wysoką wartość. Realnie rzecz biorąc, to bardzo dużo tokenów jak na rzeczy, które potencjalnie mogą w ogóle nie dotyczyć tego projektu.

Jeśli ta liczba jest u ciebie naprawdę wysoka, wejdź tam i zacznij to przycinać. Jest też komenda doctor, która częściowo w tym pomaga.

Najczęściej dzieje się tak: jeśli śledzisz cały ten trend narzędzi AI, gdzie wszystko jest nieustannie „przełomowe”, i regularnie te narzędzia instalujesz, łatwo zapomnieć, jakie serwery MCP masz zainstalowane. Wiele z tych skilli, które ostatnio poszły wiralowo — Graphify i tym podobne — dostarczane są razem z serwerami MCP, własnymi agentami i własnymi skillami. Czasem instalują się globalnie. I to puchnie, puchnie, puchnie, aż nagle twoje sesje ładują sto tysięcy tokenów, zanim w ogóle zaczniesz pracę. A to jest problem z wielu różnych powodów.

Podsumowanie kategorii pierwszej: zarządzanie kontekstem

Te trzy pierwsze punkty należą do kategorii zarządzania kontekstem. Czyli: czyszczenie między zadaniami — to bardzo ważne i bardzo łatwe do wdrożenia. Jeśli używasz /compact, to w oknie pierwszej godziny. I regularne przeglądy — powiedziałbym, że raz w tygodniu; można sobie na to ustawić przypomnienie i sprawdzać, jak wygląda aktualny kontekst.

Ta sesja, którą przed chwilą sprawdziłem, to dobry przykład: wyczyściłem to jakieś dwa–trzy tygodnie temu i zszedłem do mniej więcej 20 tysięcy tokenów, a jestem już z powrotem na 40 tysiącach. To znaczy, że muszę tam wejść i posprzątać, bo to zwykły balast, który wyląduje w absolutnie każdej mojej sesji.

4.Zmiana modelu i poziomu wysiłku unieważnia cache

Przechodzimy do drugiej kategorii: efektywności zasobów.

W Claude Code masz możliwość ustawienia modelu i poziomu wysiłku (Informacja dodatkowa: „effort level” to regulacja tego, jak dużo model „myśli” nad odpowiedzią). Wielu z was to zna — wybór modelu jest oczywisty, poziom wysiłku bywa mniej znany początkującym, a jest naprawdę użytecznym pokrętłem.

Trzeba jednak wiedzieć jedno: jeśli zmienisz to w trakcie sesji, całkowicie unieważnisz swój cache. Załóżmy, że masz w sesji już 100 tysięcy tokenów rozmowy i teraz zmieniasz model — z Fable na Sonnet, z Opusa na Fable, cokolwiek — albo zmieniasz poziom wysiłku. Cache przestaje obowiązywać, więc przy następnej wiadomości wszystko musi zostać przeczytane od nowa. To, co było zbuforowane, przestaje być dla ciebie ważne. A to oznacza wyższe koszty i szybsze przepalanie tokenów.

Jeśli więc naprawdę potrzebujesz, żeby coś obsłużył model innego poziomu, najprostsze rozwiązanie, jakie znalazłem, to po prostu odpalić subagenta i zlecić mu to zadanie.

5.Używaj @-wzmianek zamiast kazać szukać plików

Druga rzecz z tej kategorii — i to akurat coś, o czym nie wiedziałem, że działa w ten sposób — to używanie symbolu @ do wskazywania plików.

Wielu z nas wie, że można tak robić; to dziś dość oczywiste. Wpisujesz @ i nazwę pliku, a model wie, że ma z niego skorzystać. Ale okazuje się, że jest to wyraźnie lepsze niż kazanie mu poszukać pliku, o którym wiesz, że istnieje.

Przykład: chcę odwołać się do pliku ze smoke testami. Jeśli wpiszę @, przewinę do smoke tests i wskażę ten plik, to sam plik zostaje dołączony do wysyłanego zapytania. Efekt: mniej wywołań narzędzi, mniej operacji, które zżerają tokeny. Mniej odczytów, mniej operacji wyszukiwania.

Myślę, że wiele osób wpada tu w tryb leniwy: „hej, znajdź plik o takiej nazwie” — i model rusza go szukać po wszystkich katalogach. A wtedy musi te katalogi faktycznie przeszukać, a odczytywanie wyników tych wyszukiwań kosztuje tokeny. Całość robi się coraz bardziej nieefektywna.

Tam, gdzie to możliwe i rozsądne, użycie prawdziwej @-wzmianki będzie dla ciebie dużą oszczędnością zasobów.

6.Redukcja szumu: filtruj hałaśliwe komendy i wypychaj je do subagentów

Ostatnia kategoria to redukcja szumu. Wchodzą tu dwie rzeczy.

Pierwsza to używanie flag lub innych mechanizmów do filtrowania hałaśliwych komend. Wyobraź sobie projekt z mnóstwem nieśledzonych zmian w gicie. Jeśli pozwolisz modelowi wywołać dowolne polecenie CLI, żeby sprawdził, jaki jest stan rzeczy, będzie musiał przeczytać wszystko, co się wypisze. Uruchamiasz git status, a tam siedzi kupa rzeczy, które nie mają prawa tam być — i model musi to przeczytać. Po pierwsze, zamuliłeś sobie okno kontekstowe, bo to wszystko wylądowało w informacjach, którymi model dysponuje. Po drugie, kosztuje cię to pieniądze, bo te tokeny trzeba faktycznie przeczytać i przetworzyć.

Druga rzecz — i to jest to, co zwykle robię ja — to uruchamianie wszystkiego, o czym wiesz, że wygeneruje mnóstwo szumu, w subagentach. Odpalasz subagenta na Sonnecie, albo nawet na Haiku, zależnie od potrzeb. Niech pójdzie, wykona te komendy, wyodrębni tylko tę część wyniku, która jest naprawdę potrzebna, i przekaże ją z powrotem do modelu głównego.

To bardzo proste w użyciu. W terminalu wystarczy powiedzieć coś w rodzaju: „odpal subagenta na Haiku, żeby sprawdził aktualny status gita na naszej gałęzi”. Można się spierać, czy akurat w tym przypadku to nie przesada — ale będzie mnóstwo sytuacji, w których wiesz z góry, że wygeneruje się bardzo dużo kontekstu, że nie będziesz go potrzebował w całości, a interesuje cię tylko konkretny fragment. Właśnie tam takie podejście naprawdę się opłaca.

W efekcie zamiast wysypywać całą tę treść do głównego okna orkiestratora, dostajemy zwięzłą informację: oto nieśledzone zmiany, oto pięć ostatnich commitów, nic nie jest zastage’owane ani zmodyfikowane. I tyle. Wiemy, jak stoimy.

Dlaczego to w ogóle ma znaczenie

Powód, dla którego to wszystko jest istotne, jest taki, że toczy się realna walka o koszt wykonania zadania.

Wszyscy przyzwyczailiśmy się dziś do mocno dotowanych rozwiązań — plan Claude Code Max, plan Codex czy cokolwiek innego — gdzie płacisz stałą opłatę, silnie subsydiowaną przez dostawców modeli, i właściwie nie obchodzi cię, ile tokenów pochłania dana rzecz.

To przestaje działać, gdy pracujesz na przykład z modelami open source, gdzie sam pokrywasz koszt. Pozwalanie modelowi na dowolne, przypadkowe działania bez zwracania uwagi na to, jak je wykonuje, to naprawdę zła praktyka — i będzie cię kosztować znacznie więcej w świecie, który prawdopodobnie zmierza w stronę coraz większego znaczenia takich modeli w naszej codziennej pracy.

Jeśli chcesz zgłębić temat, podlinkuję artykuł pod filmem — jest tam sporo naprawdę dobrych informacji o tym, jak powstają tokeny, jak GPU i serwery faktycznie je przetwarzają i dlaczego przekłada się to na zjawiska, które obserwujemy. Jak naprawdę działa cache’owanie promptów. To są pojęcia, które i tak w końcu trzeba poznać, jeśli chcesz być dobry w budowaniu — zwłaszcza gdy zaczniesz tworzyć własnych agentów, na przykład na Agent SDK, gdzie te same mechanizmy dostajesz jako elementy sterujące do wbudowania we własne aplikacje. Musisz rozumieć, dlaczego są wartościowe, jak działają i jaki mają wpływ na użytkowników.

Link będzie w opisie. To tyle — mówiłem, że będzie krótko. Do zobaczenia w następnym.

10 najważniejszych takeaways — z kontekstem zastosowania

1./clear między zadaniami zamiast ciągnięcia jednej sesji

Na czym polega: Czyszczenie kontekstu przy każdej zmianie zadania usuwa wszystko, czego dalej nie potrzebujesz. Autor twierdzi, że to główny powód, dla którego nigdy nie kończą mu się tokeny na planie Max.

Jak stosować: Traktuj przejście do nowego zadania jako sygnał do /clear. To najtańszy i najłatwiejszy nawyk z całej listy.

Na co uważać: Czyszczenie kasuje też kontekst, który był ci potrzebny — ma sens tylko wtedy, gdy stan pracy jest zapisany gdzieś poza rozmową.

2.Zapisuj stan pracy do artefaktów, żeby móc czyścić bezkarnie

Na czym polega: Autor korzysta z narzędzi opartych na specyfikacjach właśnie dlatego, że zapisują każdy etap do artefaktu zawierającego cały potrzebny kontekst.

Jak stosować: Zanim wyczyścisz sesję, upewnij się, że plan, decyzje i wyniki etapu są w pliku, a nie tylko w historii czatu.

Na co uważać: Artefakty też są ładowane do kontekstu — muszą być zwięzłe, inaczej przeniesiesz problem w inne miejsce.

3./compact tylko wewnątrz godzinnego okna cache’a

Na czym polega: Jeśli od ostatniej wiadomości minęła ponad godzina, cache przepadł, a kompaktowanie zmusza model do ponownego przeczytania wszystkiego.

Jak stosować: Jeśli używasz /compact, rób to regularnie i wcześniej — z założeniem, że masz na to godzinę od ostatniej aktywności.

Na co uważać: To optymalizacja kosztowa, nie jakościowa. Nie oczekuj po niej lepszych wyników pracy modelu.

4.Uruchom /context i zobacz swój prawdziwy narzut startowy

Na czym polega: Komenda pokazuje, ile tokenów ładuje się jeszcze przed pierwszą wiadomością. U autora było to 47 tysięcy na Opusie 5.

Jak stosować: Uruchom ją raz w każdym aktywnym projekcie — to diagnoza, od której zaczynasz sprzątanie.

Na co uważać: Ten narzut mnoży się przez każdą sesję, więc nawet kilkanaście tysięcy tokenów „na starcie” to realny, powtarzalny koszt.

5.Przejrzyj i przytnij pamięć przez /memory

Na czym polega: Duża pozycja „memory” w /context — u autora 11 tysięcy tokenów — często zawiera treści niezwiązane z bieżącym projektem.

Jak stosować: Uruchom /memory, rozdziel pamięć użytkownika od pamięci projektu i wytnij to, co nie dotyczy aktualnej pracy. Pomocna bywa też komenda doctor.

Na co uważać: Nie tnij w ciemno — część wpisów to celowe instrukcje, których usunięcie zmieni zachowanie modelu.

6.Rób inwentaryzację MCP, skilli i agentów

Na czym polega: Wiralowe narzędzia AI często dowożą przy okazji serwery MCP, własnych agentów i skille, czasem instalowane globalnie. To narasta, aż sesje startują ze stu tysięcy tokenów.

Jak stosować: Ustaw sobie cotygodniowe przypomnienie na sprawdzenie /context i odinstalowanie tego, czego realnie nie używasz.

Na co uważać: Autor po wyczyszczeniu zszedł do ~20 tysięcy tokenów i w dwa–trzy tygodnie wrócił do 40 tysięcy — to nie jest jednorazowa akcja, tylko cykliczna higiena.

7.Nie zmieniaj modelu ani poziomu wysiłku w trakcie sesji

Na czym polega: Każda taka zmiana unieważnia cache. Przy stu tysiącach tokenów rozmowy oznacza to ponowne przetworzenie całości przy następnej wiadomości.

Jak stosować: Ustal model i poziom wysiłku na starcie sesji. Jeśli w trakcie potrzebujesz innego poziomu, odpal subagenta zamiast przełączać model główny.

Na co uważać: Im dalej w sesji dokonasz przełączenia, tym drożej ono wypadnie — najgorszy moment to koniec długiej rozmowy.

8.Wskazuj pliki przez @, nie każ ich szukać

Na czym polega: @-wzmianka dołącza plik bezpośrednio do zapytania. Polecenie „znajdź plik o nazwie X” uruchamia przeszukiwanie katalogów, a odczyt wyników tych wyszukiwań też kosztuje tokeny.

Jak stosować: Zawsze gdy znasz ścieżkę lub nazwę pliku, wskaż go jawnie przez @. Efekt to mniej wywołań narzędzi i mniej odczytów.

Na co uważać: To działa tam, gdzie wiesz, czego chcesz. Przy zadaniach eksploracyjnych szukanie nadal jest potrzebne.

9.Filtruj wyjście hałaśliwych komend

Na czym polega: Nieograniczone wywołania CLI w projekcie z mnóstwem nieśledzonych zmian zasypują okno kontekstowe. Podwójny koszt: zamulony kontekst plus tokeny na przetworzenie tego wszystkiego.

Jak stosować: Używaj flag i innych mechanizmów zawężających wyjście, zanim pozwolisz modelowi je odczytać.

Na co uważać: Raz wczytany szum zostaje w cache’u sesji — nie odzyskasz tego inaczej niż czyszczeniem.

10.Wypychaj hałaśliwe operacje do subagentów

Na czym polega: Subagent — na Sonnecie albo Haiku — wykonuje komendę, wyodrębnia tylko potrzebny fragment i przekazuje go do modelu głównego. Zamiast pełnego wysypu dostajesz zwięzły raport.

Jak stosować: Stosuj tam, gdzie z góry wiesz, że wygeneruje się dużo kontekstu, a potrzebujesz z niego jednego konkretnego elementu. Wystarczy zwykłe polecenie w rodzaju „odpal subagenta na Haiku, żeby sprawdził status gita”.

Na co uważać: Przy naprawdę drobnych komendach to może być przerost formy nad treścią — sam autor przyznaje, że przykład ze statusem gita bywa przesadą. Szerszy powód, by w to inwestować: obecne plany ryczałtowe są mocno dotowane, ale przy modelach open source i własnych agentach koszt tokenów zaczniesz płacić sam.