Ile kosztowałby Claude Code na API: 30 dni transkryptów, policzone

TL;DR: Wyceniłem 30 dni transkryptów mojego agenta kodującego według publicznych stawek API i wyszło około 4176 USD za miesiąc. To kwota równoważna API, a nie pieniądze, które wydałem: pracuję na stałej subskrypcji (Claude Max 20x, 200 USD miesięcznie), więc cena za zużycie byłaby mniej więcej dwadzieścia razy wyższa od tego, co faktycznie płacę. Ponad 90% tej kwoty to odczyty z cache, bo każda tura długiej sesji czyta ponownie cały kontekst, a 88% wszystkich tokenów wejściowych poszło na tury, w których kontekst przekraczał już 300K tokenów. Wniosek dla context engineering: długie sesje pozostają drogie nawet przy idealnie działającym cache, więc to długość sesji jest dźwignią, która się liczy. Metoda jest na tyle prosta, że powtórzysz ją na własnych logach w jedno popołudnie.

Pytanie, od którego się zaczęło

Codziennie używam Claude Code na subskrypcji, przy kilku produktach, które prowadzę samodzielnie. Wciąż wracało do mnie pytanie: czy nie byłoby taniej płacić za tokeny przez API? Intuicja za tym pytaniem jest rozsądna. Przez większość dni nie mam wrażenia, że generuję aż tyle tekstu, więc rozliczenie za zużycie wydaje się potencjalnie korzystniejsze. Było też pytanie poboczne: czy wariant z API wymaga więcej lokalnego CPU albo pamięci.

Na drugie odpowiedź jest szybka. Nie ma żadnej różnicy. W obu przypadkach model działa na serwerach dostawcy; lokalnie to to samo narzędzie wiersza poleceń, a zmienia się tylko sposób uwierzytelnienia i rozliczenia. Pierwsze pytanie wymagało danych, a te już miałem, bo agent zapisuje każdą sesję do lokalnego pliku z transkryptem, a każda odpowiedź modelu w tym pliku ma blok usage z liczbą tokenów.

Jak zmierzyć, ile naprawdę kosztuje agent kodujący?

Metoda to skrypt przechodzący po transkryptach. Każda wiadomość asystenta w logu zawiera cztery liczby: świeże tokeny wejściowe, tokeny wyjściowe, tokeny zapisane do cache promptu i tokeny odczytane z cache promptu. Prompt caching to funkcja API, dzięki której zapytanie może ponownie użyć już przetworzonego początku rozmowy za ułamek zwykłej ceny inputu, a agent robi dokładnie to w każdej turze. Pomnóż każdy z czterech liczników przez odpowiednią cenę za milion tokenów dla modelu, który wygenerował odpowiedź, zsumuj i masz koszt równoważny API.

O tym, czy wynik jest poprawny, decydują trzy szczegóły:

• Usuń duplikaty. Ta sama odpowiedź może pojawić się w logu w kilku liniach, więc identyfikuj każdą po message id i request id i licz ją raz. Bez tego suma rośnie ponad rzeczywistość.
• Wyceniaj osobno każdą rodzinę modeli. W moim miesiącu mieszały się trzy modele, a najmocniejszy kosztuje za token wejściowy dwa razy więcej niż kolejny poziom niżej. Jedna uśredniona stawka nie miałaby sensu.
• Filtruj po znaczniku czasu odpowiedzi, nie po dacie pliku. Długie sesje trwają po kilka dni, więc plik zmieniony wczoraj może zawierać tury sprzed dwóch tygodni.

# illustrative shape, not the full script
# $ per 1M tokens: input, output, cache write, cache read
PRICE = {"fable": (10, 50, 12.5, 0.25), "opus": (5, 25, 6.25, 0.5)}
FIELDS = ("input_tokens", "output_tokens",
          "cache_creation_input_tokens", "cache_read_input_tokens")

seen, totals = set(), defaultdict(lambda: [0, 0, 0, 0])
for line in transcript_lines(last_days=30):
    msg = line.get("message") or {}
    usage = msg.get("usage")
    key = (msg.get("id"), line.get("requestId"))
    if line.get("type") != "assistant" or not usage or key in seen:
        continue
    seen.add(key)
    t = totals[family(msg.get("model"))]
    for i, field in enumerate(FIELDS):
        t[i] += usage.get(field, 0)

cost = sum(
    sum(n * price for n, price in zip(t, PRICE[f])) / 1e6
    for f, t in totals.items()
)

Ceny w tym fragmencie to opublikowane stawki za milion tokenów według stanu na wrzesień 2026 dla Claude Fable 5.1 i Opus 5 (input, output, zapis do cache, odczyt z cache). Sonnet 5 jest wyraźnie tańszy od obu. Podstaw stawki swojego dostawcy; struktura się nie zmienia.

Ile wyszło z 30 dni transkryptów

Okno objęło 25 aktywnych dni i około 15 900 odpowiedzi modelu. Liczby poniżej są hipotetyczne: pokazują, ile kosztowałoby to samo użycie, gdyby za każdy token płacić przez API. Nic z tego nie zostało faktycznie naliczone, bo całość szła na stałej subskrypcji.

Zaskoczył mnie skład. Ponad 90% kwoty to odczyty z cache. Na samym najmocniejszym modelu miesiąc dał około 4,15 mld tokenów odczytanych z cache. Output, czyli to, co intuicyjnie kojarzyłem ze „zużyciem”, jest ledwo widoczny. Pytanie „ile tekstu pisze agent?” nie ma więc prawie nic wspólnego z rachunkiem. Liczy się to, jak duży jest kontekst w każdej turze i ile tur trwa sesja.

Gdzie idą tokeny w długiej sesji agenta?

Stąd drugi przekrój tych samych danych: każdą turę przypisałem do przedziału według rozmiaru kontekstu, przy czym kontekst to świeży input plus zapisy do cache plus odczyty z cache w danej turze.

88% tokenów wejściowych poszło na tury, w których kontekst przekraczał już 300K. Z 45 sesji 27 przekroczyło 300K, 16 przekroczyło 500K, a pięć doszło aż do około miliona tokenów, z liczbą tur od 806 do 4473 w jednej sesji. Tura przy 800K kosztuje mniej więcej osiem razy tyle co tura przy 100K, nawet jeśli odpowiedź ma tę samą długość. Model płaci, tura po turze, za ponowne czytanie wszystkiego, co wydarzyło się od początku sesji, łącznie z trzema niezwiązanymi pobocznymi wątkami, które po drodze podjąłem.

To właśnie zmieniło mój sposób pracy. Cache sprawia, że każde ponowne czytanie jest tanie w przeliczeniu na token, a ja w głowie odłożyłem długie sesje na półkę „w porządku, przecież jest cache”. Tanio za token razy setki milionów tokenów to wciąż dominujący koszt. Gdyby te długie sesje kończyły się w okolicach 300K, a kolejny wątek zaczynał się od nowa od krótkiej pisemnej notatki, ta sama ilość pracy wymagałaby ułamka tokenów.

Subskrypcja czy API: opcje i kompromisy

Z liczbami w ręku decyzja sprowadzała się do trzech realnych opcji.

Płatność za tokeny przez API. Zalety: płacisz dokładnie za to, czego używasz, nie ma okna limitu, na które można trafić, i działa tam, gdzie osobista subskrypcja nie działa, na przykład w skryptach, zadaniach CI i zaplanowanych automatyzacjach. Wady przy profilu takim jak mój przesądzają sprawę: długie sesje, duży kontekst i wiele tur na sesję to dokładnie ten kształt użycia, który rozliczenie za zużycie karze, bo odczyty z cache rosną jak rozmiar kontekstu razy liczba tur. W moim miesiącu wariant z API kosztowałby około dwudziestu razy więcej niż subskrypcja.

Stała subskrypcja. Zalety: krańcowy koszt zadania jest praktycznie zerowy, więc przestaję racjonować dobry model, a intensywna praca z długim kontekstem to dokładnie ten przypadek, w którym stała cena wygrywa. Wady: jest okno limitu i gdy się wyczerpie, czekasz; do tego subskrypcja jest związana z interaktywną pracą człowieka, więc nie obejmuje automatyzacji działających bez nadzoru.

Wariant hybrydowy. Subskrypcja jako podstawa całej pracy interaktywnej, a klucz API tylko do skryptów i awaryjnie na ten rzadki dzień, w którym wyczerpie się limit. Wydatki za zużycie pozostają wtedy małe i przewidywalne, kosztem obsługi dwóch sposobów uwierzytelniania.

Zostałem na subskrypcji, a wariant hybrydowy traktuję jako wyjście awaryjne. Logika progu opłacalności jest prosta: API ma sens, gdy użycie jest małe i nieregularne, rzędu kilkunastu dolarów miesięcznie, albo gdy praca idzie bez człowieka przy klawiaturze. Kto pracuje z agentem po kilka godzin dziennie w długich sesjach, powinien spodziewać się dużej kwoty przy rozliczeniu za zużycie. Zgadza się to z tym, co napisałem w tekście o agentach jako współinżynierach: realny wydatek to stałe 200 USD miesięcznie za Claude Max 20x plus plan ChatGPT Plus za 20 USD, który obejmuje Codex CLI, na czas porównywania obu agentów, a ten pomiar wyjaśnia, dlaczego przy takim sposobie pracy ta cena jest tak korzystna.

Czego ten pomiar nie powie

Kwota 4176 USD to scenariusz hipotetyczny i ma ograniczenia, które warto nazwać wprost.

• Przy rozliczeniu za zużycie zachowanie by się zmieniło. Gdybym płacił za tokeny, nie pozwoliłbym pięciu sesjom dojść do miliona tokenów. Ta kwota wycenia moje nawyki z subskrypcji po stawkach API; ktoś na API od pierwszego dnia pracowałby inaczej i płaciłby mniej.
• Obejmuje tylko głównego agenta, w takim zakresie, w jakim trafił do logów. Liczone jest to, co zapisały transkrypty. Nie próbowałem odtwarzać niczego spoza nich.
• Ceny się zmieniają. Stawki są według stanu na wrzesień 2026. Gdy się zmienią, uruchom skrypt ponownie; spodziewam się, że kształt wyniku (dominują odczyty z cache, dominuje długi kontekst) się utrzyma.

Jedna rzecz też nie zadziałała i dane to obnażyły: miałem już pisemną instrukcję, że nowy temat oznacza nową sesję. Model zna tę zasadę. Ja, w środku produktywnego popołudnia, jej nie przestrzegam. Pięć sesji po milion tokenów to dowód. Zasada, która zależy od tego, czy człowiek o niej pamięta w rozpędzie, jest słabym zabezpieczeniem, dlatego moim kolejnym krokiem jest wymuszanie granic sesji narzędziami, a nie instrukcjami.

Co powiedziałbym komuś, kto robi to jutro

• Zmierz, zanim zdecydujesz. Twój agent już loguje zużycie tokenów dla każdej odpowiedzi. Skrypt na jedną stronę zamienia to w realną liczbę w jedno popołudnie, a to lepsze niż każdy szacunek oparty na tym, jak intensywny wydawał się miesiąc.
• Patrz na skład, nie tylko na sumę. Jeśli dominują odczyty z cache, rachunek zależy od rozmiaru kontekstu i liczby tur, a objętość outputu to błąd zaokrąglenia.
• Podziel tury według rozmiaru kontekstu. Ta jedna tabela pokaże, czy Twój koszt siedzi w długim ogonie przerośniętych sesji. U mnie siedział: 88% inputu powyżej 300K.
• Traktuj długość sesji jako decyzję z zakresu context engineering. Context engineering to praktyka decydowania, co i kiedy trafia do okna kontekstu modelu. Zakończenie sesji w naturalnym miejscu i wznowienie pracy od krótkiego pisemnego handoffu (notatki przekazania) to najtańsza dostępna optymalizacja, a przy okazji zwykle poprawia jakość odpowiedzi.
• Dobierz model rozliczeń do kształtu użycia. Intensywna praca interaktywna w długich sesjach przemawia za subskrypcją. Lekkie, nieregularne albo bezobsługowe użycie przemawia za API. Wiele osób potrzebuje obu.

O drugiej połowie budżetu kontekstu, czyli o tym, co ładuje się, zanim cokolwiek wpiszesz, piszę w tekście o tym, jak układam to, co ładuje się do sesji Claude Code. Koszt startu okazał się mały w porównaniu z tym. Tokeny idą na długość rozmowy.