Ten sam agent, ten sam wolumen zgłoszeń, a rachunek za API wyższy o siedemdziesiąt procent niż w pierwszym pełnym miesiącu. Nikt nie podmienił modelu, dostawca nie podniósł cennika. Zmieniło się to, ile tekstu agent czyta przy każdym pojedynczym kroku – a to jest pozycja, która w obsłudze zgłoszeń dominuje nad wszystkimi pozostałymi.

Poniżej rozbicie rachunku na części, miejsca, w których rośnie po cichu, i kalkulacja dla dwóch tysięcy zgłoszeń miesięcznie z założeniami do podmiany na własne.

Agent obsługuje jedno zgłoszenie i płacisz za cztery pozycje

Faktura od dostawcy modelu wygląda na jedną liczbę, ale powstaje z czterech niezależnych strumieni. Trzeba je rozdzielić, bo każdy rośnie z innego powodu i każdy tnie się inną techniką.

• Tokeny wejścia – wszystko, co model czyta: prompt systemowy, definicje narzędzi, treść zgłoszenia, wyniki wywołanych narzędzi i cała dotychczasowa historia rozmowy. To zwykle 80-95% objętości.
• Tokeny wyjścia – to, co model pisze: odpowiedź, wywołania narzędzi, bloki rozumowania. Objętościowo niewiele, ale w cenniku Anthropic dla Claude Sonnet 5 wyjście kosztuje pięciokrotnie więcej niż wejście (15 USD wobec 3 USD za milion tokenów, stan na sierpień 2026; do 31 sierpnia 2026 obowiązuje niższa cena wprowadzająca 2 i 10 USD).
• Zapis do cache wejścia – płatny narzut za odłożenie stałego początku promptu. Przy pięciominutowym TTL to 1,25-krotność ceny wejścia, przy godzinnym 2-krotność.
• Odczyt z cache – 0,1 ceny wejścia. To ta pozycja, dla której cały mechanizm istnieje.

Mnożniki cache pochodzą z dokumentacji Anthropic dotyczącej prompt caching. U innych dostawców proporcje bywają inne, ale sama struktura rachunku jest ta sama, więc rozbicie warto zrobić niezależnie od tego, czyj model stoi pod spodem.

Historia rozmowy puchnie z każdym krokiem pętli

Tu leży najczęstsza pomyłka w szacowaniu kosztu agenta. API jest bezstanowe. Model nie pamięta poprzedniego kroku – przy każdym wywołaniu wysyłasz mu całą dotychczasową rozmowę od nowa.

Prześledźmy jedno zgłoszenie w typowym przepływie: agent czyta skrzynkę, klasyfikuje sprawę, odpytuje bazę wiedzy i system ticketowy, po czym pisze odpowiedź.

• Krok 1. Prompt systemowy, definicje narzędzi, treść maila. Wejście: około 5 500 tokenów. Model odpowiada wywołaniem narzędzia.
• Krok 2. To samo co wyżej plus wywołanie z kroku 1 plus wynik z bazy wiedzy – trzy fragmenty dokumentacji. Wejście: 7 500 tokenów.
• Krok 3. To samo plus historia klienta z systemu ticketowego. Wejście: 10 000 tokenów.

Trzy kroki, ale 23 000 tokenów wejścia zamiast 10 000, które widać w ostatnim wywołaniu. Wynik narzędzia z kroku 2 przepłacasz dwa razy, bo jedzie w kontekście do końca zgłoszenia. Przy pięciu krokach zamiast trzech koszt wejścia rośnie nie o dwie trzecie, tylko ponad dwukrotnie – wzrost jest kwadratowy względem liczby kroków, nie liniowy.

Praktyczny wniosek: pozycja „wyniki narzędzi” jest w rachunku ukryta w tokenach wejścia i nikt jej osobno nie mierzy. Narzędzie, które zwraca 4 000 tokenów zamiast 400, podnosi koszt każdego kolejnego kroku w tej rozmowie.

Cache wejścia tnie rachunek, dopóki początek promptu jest bajt w bajt ten sam

Cache wejścia działa na dopasowaniu prefiksu. Dostawca liczy skrót z dokładnych bajtów promptu do wyznaczonego punktu odcięcia i przy kolejnym wywołaniu porównuje go z zapisanym. Zgadza się – płacisz dziesiątą część. Nie zgadza się o jeden bajt – płacisz pełną stawkę za wszystko od miejsca różnicy w dół.

Kolejność renderowania promptu jest stała: najpierw definicje narzędzi, potem prompt systemowy, na końcu wiadomości. Co z tego wynika w praktyce:

• Data w prompcie systemowym unieważnia wszystko. Wstawka w stylu „dzisiaj jest 2026-08-09, godzina 14:22” na początku promptu sprawia, że nic poniżej nie trafia w cache. Ta sama data w treści wiadomości użytkownika nie psuje niczego.
• Zmiana zestawu narzędzi resetuje cache w całości. Narzędzia renderują się na pozycji zerowej. Dodanie jednego narzędzia w połowie rozmowy, przełączenie „trybu” przez podmianę listy narzędzi albo niedeterministyczna serializacja JSON-a (nieposortowane klucze, iteracja po zbiorze) unieważniają wszystko.
• Personalizacja promptu systemowego per klient zabija współdzielenie. Wstrzyknięcie nazwy firmy i ID konta do nagłówka daje tyle osobnych prefiksów, ilu masz klientów. Ta sama treść wstawiona po punkcie odcięcia nie kosztuje nic.
• Zbyt krótki prefiks nie cache’uje się w ogóle i nie dostajesz o tym żadnego błędu. Progi zależą od modelu: 512 tokenów dla Claude Opus 5, 1024 dla Claude Sonnet 5, 4096 dla Claude Haiku 4.5.
• Zmiana modelu unieważnia cache. Cache jest przypisany do modelu, więc „przełączmy tanie zgłoszenia na mniejszy model” to decyzja, którą trzeba policzyć razem z utratą trafień.

Jest jeszcze pułapka wolumenowa, którą łatwo przeoczyć. Domyślny TTL to pięć minut. Przy 2 000 zgłoszeń miesięcznie i trzech wywołaniach na zgłoszenie wychodzi około 6 000 wywołań, czyli w godzinach pracy jedno co siedem minut. Cache wygasa między zgłoszeniami i zamiast tanich odczytów płacisz drogie zapisy. Progi break-even są proste: przy TTL pięciominutowym zapis zwraca się po dwóch odczytach, przy godzinnym – po trzech. Jeśli ruch jest rzadszy niż TTL, cache w domyślnej konfiguracji potrafi być droższy niż jego brak.

Weryfikacja jest jednoznaczna. W odpowiedzi z API są trzy pola: cache_read_input_tokens, cache_creation_input_tokens i input_tokens. Jeśli pierwsze z nich uparcie pokazuje zero mimo identycznych promptów, coś unieważnia prefiks. Zrzuć wyrenderowany prompt z dwóch kolejnych wywołań i zrób diff bajtowy – przyczyna zawsze jest widoczna.

Ponowienia i przerwane wywołania dopisują się bez śladu w metrykach biznesowych

Dashboard biznesowy pokazuje 2 000 obsłużonych zgłoszeń. Dostawca policzył 6 400 wywołań. Różnica siedzi w miejscach, których nikt nie ogląda.

Ponowienia po błędach. Klienty API domyślnie powtarzają żądania po 429 i po błędach 5xx, zwykle dwa razy. Każde powtórzenie to pełny koszt wejścia od zera. Przy limitach przepustowości ustawionych zbyt ciasno agent generuje kaskadę 429 i płacisz za tokeny, których nigdy nie zobaczyłeś.

Odcięcie na limicie wyjścia. Wywołanie, które kończy się z powodem zatrzymania „max_tokens”, jest w pełni płatne, a odpowiedź jest bezużyteczna. Retry z wyższym limitem oznacza, że za to samo zgłoszenie zapłaciłeś dwa razy, za drugim razem drożej.

Pętle narzędziowe bez limitu kroków. Agent, który nie potrafi zamknąć sprawy, potrafi krążyć: odpytuje bazę, nie znajduje, odpytuje inaczej, znowu nie znajduje. Każdy obrót dokłada wynik narzędzia do kontekstu i podnosi cenę następnego. Bez twardego limitu iteracji jedno patologiczne zgłoszenie kosztuje tyle, co pięćdziesiąt zwykłych.

Rozumowanie modelu. W modelach z adaptacyjnym myśleniem bloki rozumowania są liczone jako tokeny wyjścia, czyli po najdroższej stawce – także wtedy, gdy nie wyświetlasz ich użytkownikowi. Parametr poziomu wysiłku jest tu realnym regulatorem kosztu, a nie kosmetyką.

Dlaczego drugi miesiąc kosztuje więcej niż pierwszy tydzień

W pierwszym tygodniu prompt systemowy jest chudy, baza wiedzy mała, a agent obsługuje tylko trzy typy spraw. Potem dzieje się to, co zawsze.

Prompt systemowy rośnie o łatki. Każde źle obsłużone zgłoszenie kończy się dopisaniem akapitu z wyjątkiem. Po dwóch miesiącach z 4 000 tokenów robi się 7 000, a te 3 000 tokenów jedzie w każdym z sześciu tysięcy wywołań miesięcznie.

Fragmenty z bazy wiedzy się wydłużają, bo dopisano do niej nowe procedury i wyszukiwanie zwraca więcej trafień. Doszły dwa narzędzia. Zakres spraw poszerzono, więc zgłoszenia wymagają czterech kroków zamiast trzech. Odpowiedzi są dłuższe, bo zespół uznał je za zbyt zdawkowe.

Żadna z tych zmian nie wygląda na kosztową. Każda dokłada do wejścia mnożonego przez liczbę wywołań.

Dochodzi do tego zmiana składu spraw. W pierwszym tygodniu agent dostaje ruch pilotażowy – zwykle najprostsze kategorie, wybrane właśnie dlatego, że są proste. Po otwarciu na pełen strumień rośnie udział zgłoszeń wieloetapowych, z załącznikami i z historią korespondencji. Średnia liczba kroków na zgłoszenie idzie w górę, a razem z nią kwadratowy człon z poprzedniej sekcji. Dlatego ekstrapolacja kosztu z pilotażu na produkcję prawie zawsze zaniża wynik, i to nie o kilka procent.

Liczymy rachunek dla 2 000 zgłoszeń miesięcznie

Stawki: 3 USD za milion tokenów wejścia, 15 USD za milion wyjścia, odczyt z cache 0,3 USD, zapis do cache przy pięciominutowym TTL 3,75 USD. To cennik Anthropic dla Claude Sonnet 5 na sierpień 2026. Wszystkie pozostałe liczby to założenia – podstaw swoje z logów.

Miesiąc pierwszy: prefiks 4 000 tokenów, trzy kroki na zgłoszenie, zmienna część wejścia 1 500 / 3 500 / 6 000 tokenów, wyjście 1 200 tokenów łącznie. Miesiąc trzeci: ten sam wolumen, prefiks 7 000, cztery kroki, zmienna część 1 500 / 3 500 / 6 000 / 9 000, wyjście 1 600.

Ten sam wolumen, wzrost o 70%, i ani jednej decyzji, którą ktokolwiek nazwałby kosztową.

Druga tabela pokazuje, ile w miesiącu pierwszym zależy wyłącznie od tego, czy cache trafia. Zmieniamy tylko obsługę prefiksu, reszta założeń bez zmian.

Różnica między najgorszym a najlepszym wariantem to 90% kosztu prefiksu, ale tylko 37% rachunku łącznie. Cache nie jest dźwignią, którą wygrywa się cały budżet – dopóki zmienne wejście i wyjście stanowią większość, tam trzeba szukać reszty.

W miesiącu trzecim zmienne wejście to 120 z 233 USD, czyli ponad połowa rachunku, i żaden cache tego nie dotyka, bo z definicji zmienia się przy każdym wywołaniu. Dźwignie są tam trzy i wszystkie leżą po stronie przepływu, nie modelu: krótsze wyniki narzędzi, mniej kroków na zgłoszenie oraz przycinanie historii, gdy rozmowa przekracza ustalony próg. Czwarta, tańszy model dla części kroków, działa, ale kosztuje utratę trafień w cache i wymaga osobnego pomiaru jakości – klasyfikacja wstępna zwykle znosi mniejszy model bez szkody, redagowanie odpowiedzi do klienta znacznie rzadziej.

Co zmierzyć w tym tygodniu, zanim tkniesz cokolwiek

Optymalizacja bez pomiaru w tym obszarze zwykle kończy się przeniesieniem kosztu, nie jego obcięciem. Kolejność jest taka:

• Zapisz z każdego wywołania cztery liczby: input_tokens, cache_read_input_tokens, cache_creation_input_tokens, output_tokens – razem z identyfikatorem zgłoszenia i numerem kroku. Bez tego dalsze punkty są zgadywanką.
• Policz stosunek wywołań do zgłoszeń. Wynik powyżej zakładanej liczby kroków oznacza ponowienia albo pętle – znajdź je, zanim zaczniesz skracać prompt.
• Sprawdź udział odczytów z cache w całym wejściu. Zero oznacza zmienny prefiks. Niski udział przy ciężkim prefiksie oznacza, że TTL nie pasuje do gęstości ruchu.
• Zrób ranking narzędzi po średniej długości zwracanego wyniku. To najczęściej najtańsza w naprawie i najbardziej opłacalna pozycja – obcięcie odpowiedzi narzędzia zmniejsza wejście każdego kolejnego kroku.
• Wyznacz koszt jednego zgłoszenia i pilnuj go jako metryki tygodniowej, obok wskaźnika automatycznego zamknięcia. Rachunek miesięczny miesza wolumen z efektywnością i ukrywa regresję.

Kiedy te pięć liczb jest na wykresie, decyzja do podjęcia jest jedna i konkretna: ustal górny próg kosztu pojedynczego zgłoszenia, przy którym agent przestaje być tańszy od człowieka w Twoim zespole, i wpisz go jako twardy limit w monitoringu. Zgłoszenia, które ten próg przekraczają, kieruj do eskalacji zamiast pozwalać agentowi krążyć – z tym progiem w ręku każda kolejna zmiana promptu, narzędzia czy modelu ma jasne kryterium przyjęcia.