Pierwszy działający efekt pokazuję zwykle w 2-4 tygodnie. Zamiast slajdów i obietnic dostajesz rozwiązanie, które od razu możesz przetestować u siebie w firmie.

Ile kosztuje współpraca?

Szybki start produktu to od 15 000 PLN jednorazowo. Później dostępna jest opieka na abonament (od 5 000 PLN/mies) na rozwój i utrzymanie, oraz pakiet automatyzacji (od 3 000 PLN/mies) na kolejne usprawnienia. Dokładną wycenę podaję po 30-minutowej rozmowie.

Nie znam się na technologii, dam radę?

Tak. Rozmawiamy po ludzku, bez żargonu. Ty mówisz, co Cię uwiera w firmie, a ja zajmuję się całą techniczną stroną i dostarczam gotowe do użycia narzędzie.

Dla kogo jest ta oferta?

Dla firm, które tracą godziny na powtarzalną, ręczną pracę (wyceny, raporty, odpowiedzi, obsługa zamówień) i chcą to usprawnić bez budowania własnego zespołu programistów.

Jak zacząć współpracę?

Umów bezpłatną rozmowę na https://bartoszgaca.pl/rozmowa/. Opowiadasz, co chcesz usprawnić, a Ty dostajesz konkretny plan: co da się zrobić, ile to zajmie i ile kosztuje.

Optymalizacja tokenów w Claude Code — kompletny przewodnik

Rachunek za jeden weekend — i dlaczego to nie była wina Claude

Moja pierwsza sesja z Claude Code, która naprawdę zrobiła na mnie wrażenie, skończyła się rachunkiem rzędu kilkuset dolarów za jeden weekend pracy. Refaktor średniego projektu, kilkadziesiąt iteracji "no jeszcze tylko jedna rzecz", kilkanaście razy "zacznijmy od początku", gdy kontekst się rozjechał. Wtedy myślałem: ten model jest po prostu drogi.

Kilka miesięcy później podobny zakres pracy kosztuje mnie kilka razy mniej. Nie zmieniłem subskrypcji. Nie przeszedłem na tańszy model. Nauczyłem się, jak Claude liczy tokeny — i jak nie wystawiać go niepotrzebnie na pełną stawkę.

Ten artykuł zbiera w jednym miejscu to, czego nauczyłem się o optymalizacji tokenów. Konkretne wzorce i pułapki. Liczby traktuj jako orientacyjne — zależą od projektu i aktualnego cennika.

Tokeny — krótka matematyka

Ceny Anthropic API dla rodziny Claude (rzędy wielkości aktualne w 2026, USD za milion tokenów — przed wdrożeniem sprawdź aktualny cennik Anthropic, bo modele i stawki się zmieniają):

Claude Haiku 4.5 — $1 input / $5 output
Claude Sonnet 4.6 — $3 input / $15 output
Claude Opus 4.7 — $5 input / $25 output

Wygląda niewinnie. Pułapka: output jest 5× droższy od input, a sesje "napisz mi cały komponent" generują dużo output. Do tego każda iteracja "no nie tak, zrób inaczej" wysyła cały dotychczasowy kontekst jako input — dla prompta rzędu 50 tys. tokenów przy stawkach Opus to około $0.25 za iterację, a przy kilkudziesięciu iteracjach robi się z tego kilka–kilkanaście dolarów tylko za samo "słuchanie" przez Claude.

Trzy dźwignie potrafią mocno obciąć koszty:

Prompt caching — prefiks odczytany z cache kosztuje 0.1× ceny input. Ten sam prompt rzędu 50 tys. tokenów to wtedy około $0.025 zamiast $0.25 (mniej więcej 10× taniej).
Dobór modelu — Haiku do klasyfikacji, Sonnet do większości pracy, Opus tylko do najtrudniejszych decyzji.
Skracanie kontekstu — plan mode + /compact + subagenty = mniej tokenów na każdym etapie.

Reszta artykułu pokazuje jak każda z nich działa. Zaczynamy od najważniejszej — caching.

Prompt caching — fundament wszystkiego

Anthropic API liczy cache jako prefix match. To jedno zdanie, ale ma ogromne konsekwencje. Każda zmiana w jakimkolwiek miejscu prefiksu unieważnia cache wszystkiego co po niej.

Prompt jest renderowany w kolejności: tools → system → messages. Cache breakpoint na końcu sekcji system cache'uje razem tools + system. Breakpoint w środku messages cache'uje wszystko do tego punktu.

Jak to wygląda w kodzie

const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 16000,
  system: [
    { type: "text", text: largeSystemPrompt,
      cache_control: { type: "ephemeral" } }  // 5-min default TTL
  ],
  messages: [{ role: "user", content: userQuestion }]
});

Pierwsze wywołanie: pełna cena za largeSystemPrompt plus narzut 1.25× za zapis do cache (przy domyślnym 5-minutowym TTL). Drugie wywołanie z tym samym prefiksem: 0.1× ceny input. Próg opłacalności wypada już po dwóch wywołaniach — od trzeciego oszczędzasz.

Limit to maksymalnie 4 punkty cache (breakpoints) na żądanie. Minimalny prefiks, który w ogóle trafi do cache, zależy od modelu — Opus 4.6/4.7 i Haiku 4.5 wymagają minimum 4096 tokenów, Sonnet 4.6 i Haiku 3.5 — 2048, Sonnet 4.5 i starsze — 1024. Krótsze prompty po cichu nie trafiają do cache (bez żadnego błędu, po prostu cache_creation_input_tokens: 0).

Ciche unieważnienia cache — najczęstsze pomyłki

Tych pięć rzeczy zawsze unieważnia cache, mimo że wyglądają niewinnie:

Znacznik czasu w system prompcie — "Today is " + new Date(). Każde wywołanie ma inny prefiks. Rozwiązanie: wstrzyknij datę jako pierwszą wiadomość użytkownika, nie do system.
UUID/request_id wcześnie w treści — to samo. Późno = OK, wcześnie = całkowity brak trafienia.
Niedeterministyczny JSON — JSON.stringify(obj) bez sort_keys, iteracja po Set, Map w różnej kolejności. Bajty się różnią → cache miss.
Tablica tools w innej kolejności — narzędzia są na pozycji 0 prefiksu. Dodanie, usunięcie albo przesortowanie unieważnia wszystko. Sortuj po nazwie, jeśli generujesz je dynamicznie.
Sekcje warunkowe w system prompcie — if (flag) system += "...". Każda kombinacja flag to osobny cache. Lepiej trzymać jeden stały system prompt, a tryby przekazywać jako wiadomość.

Jak weryfikować że cache faktycznie działa

Każda odpowiedź ma response.usage:

cache_creation_input_tokens — ile tokenów zapisano do cache (cena 1.25×)
cache_read_input_tokens — ile odczytano z cache (cena 0.1×, to jest to, o co gramy)
input_tokens — ile zapłaciłeś pełną cenę (reszta spoza cache)

Całkowity rozmiar promptu = suma tych trzech. Jeśli po pięciu identycznych wywołaniach cache_read_input_tokens wciąż wynosi 0 — masz ciche unieważnienie cache. Porównaj bajty wyrenderowanego promptu między wywołaniami i znajdź źródło.

Dobór modelu — Haiku/Sonnet/Opus

Najczęstszy błąd: ustawić Opus jako domyślny model i nigdy nie zmienić. Drugi najczęstszy: ustawić Haiku do wszystkiego i frustrować się "czemu to nie działa".

Tabela decyzyjna oparta na kilku miesiącach codziennej pracy z tymi modelami:

Haiku 4.5 ($1/$5 za 1M)

Idealny do:

Klasyfikacji — czy ten komentarz na LinkedIn to spam, troll czy realne pytanie? W tego typu zadaniach mocniejszy model bywa nieco dokładniejszy, ale różnica jakości jest zwykle niewielka, a różnica w cenie za milion tokenów — kilkukrotna.
Parsowania danych strukturalnych — wyciągnięcie e-maila, nazwy, firmy z tekstu. Ścisły schemat narzędzia (strict tool schema) + Haiku sprawdza się bardzo dobrze.
Subagenta czytającego pliki — przejrzenie 20 plików kodu i zwrócenie podsumowania. Opus 4.7 to tu przesada.
Zadań wrażliwych na opóźnienie — bota, który ma odpowiedzieć w <500 ms. Haiku zwykle jest zauważalnie szybszy od Sonneta.

Słaby do:

Wielokrokowego rozumowania ze złożonymi zależnościami — myli się.
Pisania nowego kodu od zera w nieznanym kontekście — gubi konwencje.
Przeglądu kodu — przepuszcza subtelne błędy.

Sonnet 4.6 ($3/$15 za 1M)

Złoty środek dla większości pracy w Claude Code:

Pisanie funkcji w istniejącym projekcie — czyta CLAUDE.md, łapie konwencje, generuje kod, który wygląda jak reszta repozytorium.
Refaktor — z output_config: {effort: "medium"} robi konkretne zmiany bez przekombinowania.
Przegląd kodu przy znanych konwencjach — wyłapuje większość błędów, które sam bym znalazł.
Computer use — Sonnet 4.6 bywa tu praktyczniejszy od Opus 4.7 (mniejszy narzut).

Sonnet 4.6 wprowadził ważną zmianę: domyślny effort to high. Jeśli migrowałeś z Sonnet 4.5 i nic nie dostroiłeś, rachunki mogły wyraźnie wzrosnąć. Dla większości przypadków ustaw output_config: {effort: "medium"} jawnie.

Opus 4.7 ($5/$25 za 1M)

Najmocniejszy z tej trójki — i łatwo go nadużyć. Włączaj świadomie:

Długodystansowa praca agentowa — sesje po 2+ godziny z dziesiątkami narzędzi. Opus 4.7 trzyma się planu lepiej niż Sonnet.
Decyzje architektoniczne — projekt nowego systemu, przegląd projektu, kompromisy.
Kod z subtelnymi niezmiennikami — kod współbieżny, systemy rozproszone, bezpieczeństwo.
Zadania mocno oparte na obrazie — Opus 4.7 to pierwszy Claude z obsługą obrazów w wysokiej rozdzielczości (do 2576 px na dłuższej krawędzi) i współrzędnymi 1:1 względem pikseli. Computer use na 1080p ma teraz solidną podstawę.

Opus 4.7 wymaga rekonfiguracji vs Opus 4.6:

budget_tokens jest usunięty (błąd 400). Przejdź na thinking: {type: "adaptive"}.
temperature, top_p, top_k są usunięte. Zachowanie modelu sterujesz promptem, nie samplowaniem.
Doszedł nowy poziom effort "xhigh" — między high a max. To najlepsze ustawienie do kodowania i pracy agentowej w 4.7.
Liczenie tokenów różni się od 4.6 — zrób nowy pomiar przez count_tokens(), zanim wyciągniesz wnioski o zmianie kosztów.

Pattern: subagent z tańszym modelem

Najsilniejszy wzorzec optymalizacji w Claude Code: główny agent na Opus, subagenty na Haiku.

W praktyce: Claude Code ma agenta Explore, który czyta kod (wyszukiwanie plików, grep, odczyt). Domyślnie odpalany na Haiku 4.5. Główny agent dostaje od niego podsumowanie, a nie surową treść. Dzięki temu koszt eksploracji dużego repozytorium spada z rzędu dolarów do rzędu kilku centów.

Ten sam pomysł zastosowałem w moim projekcie linkedin-mcp-server (przykład, nie zmierzony benchmark). Zamiast klasyfikować każdy komentarz na Opusie, wstępną klasyfikację robi tańszy model, a Opus generuje odpowiedź tylko dla tych kilku procent komentarzy, które zasługują na coś więcej niż reakcję. Efekt: koszt tego procesu spadł u mnie orientacyjnie o rząd wielkości, bez pogorszenia jakości odpowiedzi.

Adaptive thinking + effort — koniec ery budget_tokens

Stara składnia thinking: {type: "enabled", budget_tokens: 8000} jest deprecated na Sonnet 4.6 i Opus 4.6, oraz usunięta na Opus 4.7 (400 error). Zastąpiło ją thinking: {type: "adaptive"} w połączeniu z output_config: {effort: ...}.

Co to zmienia w praktyce

Adaptive thinking = Claude sam decyduje, kiedy myśleć i jak długo. Nie ustawiasz sztywnego budżetu, model alokuje go dynamicznie. Zaleta: nie marnujesz tokenów na łatwe pytania. Wada: tracisz górny limit kosztu myślenia.

Effort kontroluje głębokość myślenia i ogólne zużycie tokenów. Pięć poziomów (Opus 4.7):

low — krótkie, wąsko określone zadania, wrażliwe na opóźnienie
medium — rozsądny domyślny wybór, gdy zależy Ci na koszcie
high — większość zadań wymagających „inteligencji", zrównoważony domyślny wybór
xhigh (Opus 4.7+) — kodowanie i praca agentowa, złoty środek, używany w Claude Code domyślnie
max (tylko poziom Opus) — gdy poprawność jest ważniejsza niż koszt

Sonnet 4.6 obsługuje low/medium/high (a także max). Haiku 4.5 nie obsługuje effort w ogóle.

Twardy limit — Task Budgets (beta, od Opus 4.7)

Jeśli potrzebujesz limitu na łączne zużycie tokenów w długiej pętli agentowej, użyj task_budget (nagłówek beta task-budgets-2026-03-13):

output_config: {
  effort: "high",
  task_budget: { type: "tokens", total: 128000 }  // min 20k
}

Różnica względem max_tokens: max_tokens to twardy limit na pojedynczą odpowiedź, którego model nie widzi. task_budget to limit łączny na całą pętlę i model widzi jego odliczanie — sam moderuje tempo i kończy pracę porządnie, zanim wyczerpie budżet.

Plan mode + Auto mode + /compact

Trzy wzorce, które redukują zużycie tokenów strukturalnie, a nie tylko w pojedynczym żądaniu.

Plan mode

Standardowy przepływ w Claude Code: jeden agent → eksploracja → projektowanie → implementacja → przegląd. Wszystko w jednym kontekście, wszystkie tokeny na pełnej stawce.

Plan mode dzieli to na fazy z różnymi modelami:

Agent Explore (Haiku 4.5) — czyta repozytorium (wyszukiwanie/grep/odczyt), zwraca podsumowanie. Groszowy koszt nawet dla średniego projektu.
Agent planujący (Sonnet 4.6) — rozpisuje implementację krok po kroku, wskazuje kluczowe pliki.
Główny agent (Opus 4.7) — implementuje. Ma już plan i kontekst, więc nie zużywa tokenów na eksplorację.

Łącznie potrafi to zejść do ułamka kosztu tej samej funkcji zrobionej „na jednego agenta".

Auto mode

W Claude Code tryb auto ogranicza interakcje z użytkownikiem. Model wykonuje operacje od razu, bez zatrzymywania się na "czy mogę zrobić X?". Korzyść finansowa: mniej wstępów. Bez trybu auto każde potwierdzenie to dodatkowa wymiana — wiadomość asystenta ("planuję X..."), odpowiedź użytkownika ("tak"), wiadomość asystenta ("dobra, robię..."). Każda taka runda to kilkaset tokenów na nic.

Kompromis: w trybie auto tracisz punkty kontrolne. Używaj go do powtarzalnych zadań w znanym kontekście, a nie do "zmigruj ten schemat bazy", gdzie pomyłka słono kosztuje.

/compact — ręczne ścinanie kontekstu

Po godzinie pracy kontekst rośnie do 100 tys.+ tokenów, a połowa to stare wyniki narzędzi, które już nic nie wnoszą. /compact to ręczna komenda Claude Code, która prosi model o „podsumuj i zapomnij" — skraca historię rozmowy, zachowując decyzje i stan.

Kompakcja po stronie serwera (nagłówek beta compact-2026-01-12 dla Opus 4.7/4.6 i Sonnet 4.6) automatyzuje to domyślnie przy około 150 tys. tokenów. Działa, ale bywa „agresywna" — czasem kasuje rzeczy, które chciałbyś zachować. Wolę /compact ręcznie, po skończeniu fazy, gdy widzę, co warto zostawić.

Ważne: kompakcja resetuje cache. Pierwsze żądanie po niej zapisuje cache od nowa (narzut 1.25×). Zaletą jest wyraźne obcięcie tokenów input w każdym żądaniu, wadą — reset cache. Na plus wychodzi wtedy, gdy zostaje Ci długa kolejka pracy w tej samej sesji.

Skills + MCP — dynamic loading

Każde narzędzie MCP zarejestrowane w sesji to kilkaset tokenów w bazowym prompcie. Każdy skill to kilkadziesiąt tokenów na jego opis. Mnożone przez każde żądanie.

Pułapka: dynamiczne narzędzia per użytkownik

Najgorszy wzorzec, jaki widziałem: tools = buildToolsForUser(user). Każdy użytkownik ma inną tablicę tools → każdy ma własny prefiks → nikt nie korzysta z cache. W aplikacji z setką aktywnych użytkowników i tysiącami żądań na godzinę to całkowity brak trafień.

Rozwiązania:

Stały zestaw bazowych narzędzi dla wszystkich, a dynamiczne wykrywanie przez tool_search. Tool search dokłada schematy do kontekstu, zamiast podmieniać tablicę tools — dzięki temu zachowuje cache.
Skille zamiast narzędzi dla wiedzy dziedzinowej. Niewielki opis skilla jest w prompcie zawsze, a jego treść ładuje się na żądanie, gdy zadanie tego wymaga.
Jedno narzędzie z parametrami zamiast wielu — jeden db_query z parametrem operation zamiast db_select/db_insert/db_update.

Pomiary — dashboard kosztów

Bez monitoringu wszystkie powyższe optymalizacje to wishful thinking. Co śledzę:

Per-request

Loguję każde response.usage do SQLite z session_id, model, endpoint. Codziennie agreguję:

Łączne tokeny input/output w podziale na model
Współczynnik trafień w cache (cache_read / (input + cache_read + cache_creation))
10 najdroższych sesji — gdzie ucieka budżet

Jeśli współczynnik trafień w cache spada przy stabilnym obciążeniu — wkradło się ciche unieważnienie. Jeśli rośnie udział Opus w miksie — gdzieś Sonnet lub Haiku nie wystarczył, sprawdź dlaczego.

Per funkcja

Oznaczam każde żądanie etykietą funkcji (auto-engage, auto-publish, draft-edition). Co miesiąc sortuję funkcje po koszcie. To potrafi zaskoczyć: drobny proces uruchamiany co kilka minut na pełnym kontekście potrafi zjadać nieproporcjonalnie duży kawałek budżetu. Przeniesienie go na Haiku i zadbanie o wysoki współczynnik trafień w cache potrafi obciąć ten koszt o rząd wielkości.

Liczenie tokenów przed wysłaniem

Anthropic SDK ma client.messages.countTokens() — możesz przed wysłaniem żądania sprawdzić, ile będzie kosztować. Przydatne przy decyzji "czy to mieści się w minimum prefiksu dla cache" (Opus 4.7 to minimum 4096 tokenów, mniejszy prompt po cichu nie trafia do cache).

Konkretny przykład — z mojego stacku

auto-engage.mjs w moim projekcie linkedin-mcp-server to proces, który czyta nowe komentarze pod moimi postami na LinkedIn i klasyfikuje je (reply / like_only / skip_troll / skip_spam), generuje odpowiedź dla tych, które na to zasługują, i dodaje reakcję. Liczby poniżej to model kosztowy, nie zaudytowany benchmark — pokazują rzędy wielkości i kierunek zmiany.

Wersja 1 — naiwna

Każdy komentarz → Anthropic SDK → mocny model z pełnym kontekstem (czyje konto, jakie posty, jaka branża, profil persony, styl pracy, ostatnie komentarze dla kontekstu). Przy takim kontekście każda klasyfikacja to zauważalny koszt, a przy kilkudziesięciu komentarzach dziennie robi się z tego wyraźna pozycja w miesięcznym rachunku — tylko za samą klasyfikację.

Wersja 2 — po refaktorze

Architektura w trzech krokach:

Wstępna klasyfikacja tańszym modelem — ten sam input, ale krótki output (jedno słowo: reply/like/troll/spam) i niższa stawka.
Do mocnego modelu trafia tylko ułamek komentarzy sklasyfikowanych jako reply — te kilka dziennie, które zasługują na pełną odpowiedź.
Cache'owany system prompt z personą i wytycznymi — wysoki współczynnik trafień w cache oznacza, że ten stały fragment płacisz raz, a potem po ułamku ceny.

Efekt: koszt tego procesu spadł u mnie orientacyjnie o rząd wielkości, przy lepszej jakości odpowiedzi — mocny model dostaje pełny kontekst tylko dla tych komentarzy, które przeszły wstępny filtr odsiewający śmieci.

Co dalej

To jest baza. Dla każdego z tych obszarów (caching, dobór modelu, plan mode, architektura MCP) jest głębsza warstwa optymalizacji, którą w tym artykule tylko liznąłem.

Biuletyn bartoszgaca.pl rozwija każdy z tych wątków co tydzień, w oparciu o studia przypadku z moich projektów oraz dane GA4 + GSC z bartoszgaca.pl (tak — pisanie biuletynu opieram na danych; każda edycja odpowiada na konkretne zapytania, które ludzie wpisują w Google, szukając rozwiązań). Pierwsza edycja w środę.

Zapisz się na biuletyn. Claude Code, optymalizacja tokenów, MCP, AI dev workflow. Bez clickbaitu, raz w tygodniu.

— Bartek
kontakt@bartoszgaca.pl

Bartosz Gaca, aplikacje i automatyzacje AI dla firm

Usługi: pierwszy działający efekt w 2-4 tygodnie

Najczęstsze pytania

Ile to trwa?