Liczba spraw ta sama, rachunek siedem razy wyższy. Wątki przekroczyły próg długości promptu

W marcu agent obsłużył 4 000 spraw i rachunek za tokeny wyniósł 36 dolarów. W maju obsłużył tyle samo spraw, na tym samym modelu, z tym samym promptem systemowym — i rachunek wyniósł 259 dolarów. Nikt niczego nie przeprojektował. Wątki urosły o połowę, część żądań przekroczyła próg długości promptu, a od tego progu cennik przełącza się na drugą kolumnę i liczy ją od całego żądania, nie od nadwyżki.

To jest najczęstszy mechanizm, przez który koszt agenta rośnie skokowo przy stałym wolumenie. Nie da się go zobaczyć w średnim koszcie sprawy ani w liczbie wywołań. Widać go dopiero wtedy, gdy zestawi się rozkład długości promptu z progiem, który stoi w cenniku używanego modelu.

Agent dokłada kontekst do każdego kroku, a cennik ma drugą kolumnę

Pętla agenta różni się od pojedynczego wywołania modelu tym, że stan jest w promptcie. Przy każdym kroku do żądania wchodzi komplet: prompt systemowy, definicje wszystkich narzędzi, historia wątku, wyniki wcześniejszych wywołań narzędzi i dołączone dokumenty. Siódmy krok obsługi sprawy niesie wszystko, co niósł krok pierwszy, plus sześć rund narzędzi.

Długość promptu rośnie więc w dwóch skalach jednocześnie. W obrębie jednej sprawy — bo pętla się wydłuża. I między miesiącami — bo do agenta dochodzą narzędzia, rośnie baza wiedzy, z której retriever dokłada fragmenty, a dział obsługi dopisuje do promptu systemowego kolejne wyjątki. Żadna z tych zmian nie wygląda na decyzję kosztową i żadna nie przechodzi przez przegląd budżetu.

Dopóki cennik jest liniowy, ten przyrost jest niegroźny: prompt dłuższy o 40 procent kosztuje o 40 procent więcej. Problem zaczyna się tam, gdzie dostawca wprowadza próg długości i zmienia stawkę za cały prompt po jego przekroczeniu.

Trzy cenniki, trzy różne progi i jedna wspólna zasada

Progi są, ale nie tam, gdzie podpowiada intuicja. U Anthropic modele Claude 4.6 i nowsze obejmują cały milion tokenów kontekstu w standardowej cenie — żądanie na 900 tysięcy tokenów jest rozliczane po tej samej stawce co żądanie na 9 tysięcy, z jednym wyjątkiem: Claude Haiku 5.5 jest wyceniany według długości promptu i żądanie powyżej 100 000 tokenów płaci wyższe stawki. Czyli próg ma najtańszy model w zestawie, ten, który zwykle wybiera się właśnie pod agenta o dużym wolumenie.

U OpenAI podział przebiega inaczej: cennik definiuje krótki kontekst jako nie więcej niż 272 tysiące tokenów wejścia, a długi jako wszystko powyżej, i obejmuje nim większość modeli flagowych, ale nie wszystkie — dla gpt-5.4-mini i gpt-5.4-nano podana jest jedna stawka bez progu. U Google próg dotyczy tylko części rodziny: Gemini 3.1 Pro Preview i Gemini 2.5 Pro mają osobne stawki dla promptów do 200 tysięcy tokenów i powyżej, podczas gdy Gemini 3.8 Flash ma stawkę jednolitą.

Poniżej zestawienie stawek standardowych w dolarach za milion tokenów, stan cenników sprawdzony 7 listopada 2026 roku. Ceny modeli zmieniają się częściej niż architektura przepływu, więc przed liczeniem budżetu sprawdź je u siebie, pod swoim modelem i swoim planem.

Wspólna zasada jest jedna i to ona kosztuje: stawka powyżej progu dotyczy całego żądania. Nie płacisz podwójnie za nadwyżkę ponad 100 czy 272 tysiące tokenów — płacisz wyższą stawkę za wszystkie tokeny tego żądania. Każde żądanie jest wyceniane osobno, a wcześniejsze zachowują ceny, po których zostały rozliczone. Żądanie na 100 001 tokenów kosztuje pięciokrotność żądania na 99 999 tokenów, jeśli oba idą na Haiku 5.5.

Policz, ile naprawdę waży prompt, zanim wyślesz żądanie

Do progu liczy się wszystko, co jedzie w żądaniu, a nie to, co wpisał użytkownik. Definicje narzędzi potrafią być największą pojedynczą pozycją w prompcie agenta i rosną z każdym podłączonym serwerem. Wyniki narzędzi wracają w całości, razem z polami, których model nigdy nie czyta. Historia rozumowania z poprzednich tur też wchodzi do wejścia — bloki myślenia z wcześniejszych tur asystenta liczą się do tokenów wejściowych na modelach, które zachowują wszystkie poprzednie tury.

Zgadywanie tej liczby z długości tekstu w znakach nie działa, a jednostka rozliczeniowa bywa różna nawet w obrębie jednej kategorii narzędzi — w gotowych programach limit bywa liczony w znakach, w słowach na dobę albo w tokenach, i dopiero ta trzecia jednostka odpowiada temu, co widzi cennik API. Jest na to osobny endpoint i jest darmowy: liczenie tokenów przyjmuje tę samą strukturę wejścia co tworzenie wiadomości, razem z promptem systemowym, narzędziami, obrazami i PDF-ami, i zwraca liczbę tokenów wejściowych. Jest bezpłatne, ma własne limity zapytań na minutę zależne od progu konta — 5 000, 10 000 albo 20 000 — i te limity są niezależne od limitów tworzenia wiadomości.

Dwa zastrzeżenia, które zmieniają sposób użycia. Po pierwsze, zwrócona liczba jest szacunkiem i faktyczna liczba tokenów wejściowych może się nieznacznie różnić — próg roboczy w kodzie ma więc stać wyraźnie poniżej progu cennikowego, nie na nim. Po drugie, liczenie tokenów nie korzysta z logiki cache’owania, nawet jeśli prześlesz bloki cache_control, więc sprawdza długość promptu, a nie to, ile z niego zapłacisz.

Rachunek miesięczny tego samego przepływu przed progiem i po nim

Rachunek niżej to wyliczenie na założeniach, nie pomiar z produkcji. Założenia: agent zgłoszeniowy, 4 000 spraw miesięcznie, średnio 6 wywołań modelu na sprawę, czyli 24 000 wywołań; model Claude Haiku 5.5; prefiks promptu trafiony w cache, reszta wejścia świeża.

Teraz rozbicie przyrostu, bo ono rozstrzyga, co naprawiać. Gdyby majowy prompt — dłuższy o 49 procent — był rozliczony po stawkach sprzed progu, miesiąc kosztowałby 51,84 dolara. Objętość odpowiada więc za 15,84 dolara wzrostu. Przeskok stawki odpowiada za pozostałe 207,36 dolara, czyli za 93 procent przyrostu rachunku. Optymalizacja promptu o kilka procent nie rusza tej struktury. Zejście pod próg rusza ją w całości.

Drugi wniosek jest mniej oczywisty: przekroczenie progu nie jest sygnałem do zmiany modelu. To samo żądanie na 104 000 tokenów puszczone przez Claude Sonnet 5.5, który progu nie ma, kosztuje 0,0336 dolara wobec 0,0108 dolara na Haiku 5.5 powyżej progu. Haiku zostaje tańsze — zmienia się tylko dystans. Poniżej progu było 15 razy tańsze, powyżej jest 3 razy tańsze. Decyzja brzmi „skróć prompt”, nie „przesiądź się”.

Licznik tokenów rośnie też tam, gdzie nikt nie dopisał treści

Odczyt z cache’u obniża stawkę, ale nie skraca promptu

To jest pułapka, w którą wpada się właśnie dlatego, że wcześniej zrobiło się dobrą robotę. Cache prefiksu działa: trafienie w cache kosztuje 10 procent standardowej ceny wejścia, a na Claude Opus 5.5 i Claude Sonnet 5.5 — 5 procent. Zespół widzi spadek kosztu, uznaje warstwę kontekstu za zoptymalizowaną i przestaje jej pilnować. Prompt rośnie dalej, bo rośnie tanio.

Tyle że próg długości nie patrzy na cenę. Długość promptu liczy wszystkie tokeny wejściowe żądania, w tym odczyty z cache’u i zapisy do cache’u, a żądanie powyżej progu płaci wyższe ceny także wtedy, gdy część jego promptu była trafieniem w cache. Innymi słowy: 96 tysięcy tokenów odczytanych z cache’u wlicza się do progu dokładnie tak samo jak 96 tysięcy tokenów przesłanych świeżo. Cache zmienia mnożnik, nie licznik.

Praktyczny skutek: nie można zaprojektować wyjścia z progu przez cache’owanie większej części promptu. Jedyne, co obniża licznik, to wyrzucenie treści z żądania — krótsze definicje narzędzi, mniej fragmentów z retrievera, streszczona historia wątku, wyniki narzędzi obcięte do pól, które model naprawdę czyta.

Podmiana modelu podnosi licznik bez jednego nowego zdania

Jest jeszcze jedno wejście na próg i nie ma nic wspólnego z rozrostem promptu. Tokenizer bywa inny w nowszej generacji modeli: modele Claude 4.7 i nowsze używają nowszego tokenizera, w którym ten sam tekst daje około 30 procent więcej tokenów niż na modelach wcześniejszych.

Prompt, który na starym modelu ważył 85 tysięcy tokenów, po migracji może ważyć około 110 tysięcy. Treść się nie zmieniła, przepływ się nie zmienił, a żądanie jest po drugiej stronie progu stu tysięcy. Dokumentacja mówi o tym wprost: przy migracji z modelu starszego niż Claude Opus 4.7 nie należy używać pomiarów tokenów ze starego modelu do szacowania kosztów ani dopasowania do okna kontekstu — prompty trzeba przeliczyć pod identyfikatorem modelu, którego się planuje użyć.

To zamienia „podbijamy wersję modelu” z zadania na pół dnia w zadanie, które wymaga ponownego policzenia rozkładu długości promptów. Jeśli przepływ dopiero powstaje albo właśnie przechodzi na nowszy model, budżet kontekstu lepiej rozstrzygnąć na etapie projektu niż na pierwszej fakturze — tym zajmuje się projektowanie przepływów agentowych wraz z rachunkiem tokenów.

Wstaw bramkę długości w pętlę agenta

Schemat przepływu z bramką wygląda tak:

• Krok 1 — zbuduj żądanie: prompt systemowy, definicje narzędzi, historia wątku, fragmenty z retrievera, wyniki narzędzi.
• Krok 2 — policz długość promptu przed wysyłką, osobnym wywołaniem liczenia tokenów.
• Krok 3 — porównaj z progiem roboczym, ustawionym poniżej progu cennikowego (przy progu 100 000 sensowny punkt to 90 000, bo pomiar jest szacunkiem).
• Krok 4a — poniżej progu roboczego: wyślij żądanie, zapisz zmierzoną długość do logu.
• Krok 4b — powyżej progu roboczego: uruchom redukcję w ustalonej kolejności — obetnij wyniki narzędzi do pól używanych, zmniejsz liczbę fragmentów z retrievera, zastąp najstarszą część wątku streszczeniem, zdejmij definicje narzędzi nieużywanych w tym typie sprawy.
• Krok 5 — policz ponownie; jeśli nadal powyżej progu, wyślij i oznacz żądanie w logu jako rozliczone po wyższej stawce.
• Krok 6 — raportuj rozkład, nie średnią.

Krok szósty jest tym, którego zwykle brakuje. Średnia długość promptu nie pokazuje przejścia przez próg, bo próg jest zdarzeniem na ogonie rozkładu. Przy średniej 92 tysiące tokenów i percentylu 95 na poziomie 108 tysięcy przez drugą stawkę przechodzi 5 procent ruchu — i w rachunku z powyższego przykładu te 5 procent żądań odpowiada za około 21 procent miesięcznego kosztu. Wskaźnik, który to wyłapuje, to udział żądań powyżej progu w całości ruchu, liczony dziennie.

Lista kontrolna przed wdrożeniem przepływu agentowego:

• Sprawdzony próg długości promptu dla konkretnego modelu i planu, nie dla rodziny modeli.
• Zmierzony percentyl 95 długości promptu na realnym ruchu, nie na przykładowej sprawie.
• Ustalony twardy budżet tokenów per składnik żądania: narzędzia, retriever, historia, wyniki narzędzi.
• Ustalona kolejność redukcji, gdy budżet zostanie przekroczony, i zapisane, co wolno wyrzucić jako ostatnie.
• Alert na udział żądań powyżej progu, a nie na łączny koszt miesięczny.
• Przeliczone prompty nowym tokenizerem przy każdej zmianie wersji modelu.
• Sprawdzone, czy przepływ nadaje się do przetwarzania wsadowego — API wsadowe daje 50 procent zniżki na tokeny wejściowe i wyjściowe, co dla części zadań agenta, które nie muszą odpowiadać natychmiast, jest tańsze niż jakakolwiek optymalizacja promptu.

Decyzja: budżet kontekstu albo rachunek rozstrzygnie za ciebie

Do rozstrzygnięcia są dwie rzeczy i obie są projektowe, nie operacyjne. Pierwsza: ile tokenów wolno ważyć żądaniu w tym przepływie. Liczba musi być zapisana w kodzie jako limit, nie w dokumencie jako zalecenie, bo kontekst rośnie przez dokładanie drobiazgów, z których żaden nie wygląda na problem. Druga: co wylatuje z żądania, kiedy limit zostanie przekroczony, i w jakiej kolejności — ta decyzja zapada raz, na spokojnie, a nie w momencie, w którym agent już stoi przed wysyłką.

Bez tych dwóch liczb przepływ działa poprawnie i kosztuje tyle, ile wynika z długości wątków, których nikt nie mierzy. Rachunek za maj jest wtedy pierwszym miejscem, w którym widać, że prompt urósł o połowę — a wtedy jest już o kilkaset dolarów za późno.