Kiedy wdrażaliśmy pierwszego agenta dla klienta z branży ciężkiego przemysłu — zadanie: automatyzacja tygodniowych raportów z pięciu systemów — łączny token cost za pierwszy miesiąc przekroczył pierwotny szacunek pięciokrotnie. Nie dlatego, że agent robił coś złego. Lecz dlatego, że nie domyśleliśmy się, ile tokenów pochłania każdy krok pętli, gdy historia rośnie, gdy wywołanie narzędzia wielokrotnie się powtarza, a cała konwersacja trafia do kontekstu przy każdym wywołaniu. To, co w prototypie kosztowało grosze na zapytanie, w produkcji z dziesiątkami użytkowników i tysiącami zadań dziennie kosztowało rząd wielkości więcej.
Ten artykuł nie dotyczy hipotetycznej wyceny. Chodzi o to, gdzie naprawdę uciekają pieniądze przy wdrożeniu agenta, dlaczego typowe szacunki tak bardzo mijają się z rzeczywistością i jaki zestaw optymalizacji sprawdza się w praktyce — od krótszego kontekstu, przez routing na tańsze modele, aż po prompt caching.
Skąd bierze się token cost agenta
Agenci są drożsi niż zwykłe wywołania LLM z jednego prostego powodu: każdy krok pętli to nowe wywołanie API, przy czym do kontekstu trafia narastająca historia. Porównajcie to z klasycznym RAG: jedno zapytanie, jedno wywołanie, odpowiedź. Agent z dziesięcioma krokami wykona dziesięć wywołań — a każde z nich niesie cały dotychczasowy kontekst.
Konkretna topologia kosztów wygląda następująco:
- Prompt systemowy — powtarza się przy każdym wywołaniu. Jeśli masz prompt systemowy zawierający 2 000 tokenów, a agent wykona 8 kroków, zapłacisz za ten sam tekst osiem razy.
- Historia konwersacji — każdy cykl Reason-Act-Observe dokłada kolejne tokeny do kontekstu. Przy długich zadaniach tokeny wejściowe rosną kwadratowo.
- Wyniki narzędzi — odpowiedzi narzędzi (wyniki z bazy danych, odpowiedzi API, dokumenty) trafiają do kontekstu i zwiększają jego rozmiar. Szeroki retrieval RAG przed każdym krokiem może podwoić tokeny wejściowe.
- Pętle retry — gdy wywołanie narzędzia się nie powiedzie, agent próbuje ponownie. Wskaźnik retry na poziomie 10–15 % jest w systemach produkcyjnych normą. Każdy retry = kolejne wywołanie z pełnym kontekstem.
- Tokeny wyjściowe — reasoning agentów (chain-of-thought, rozumowanie krok po kroku) generuje długie odpowiedzi. Tokeny wyjściowe są zwykle 3–5× droższe niż wejściowe.
Efekt: rzeczywisty agent w produkcji zużywa na jedno zadanie rzędu 5–50× więcej tokenów, niż wynikałoby z oszacowania na podstawie prototypu.
Rzędowe przykłady — co to oznacza w euro
Ceny modeli zmieniają się co 1–3 miesiące, dlatego podaję orientacyjne przykłady rzędów wielkości aktualne w chwili pisania tego artykułu. Zawsze weryfikujcie bieżące ceny bezpośrednio u dostawcy.
Modele frontier poruszają się obecnie w przedziale od ~0,10 USD do ~5 USD za milion tokenów wejściowych i od ~5 USD do ~30 USD za milion tokenów wyjściowych — czyli różnica 50× między najtańszym a najdroższym tierem. To kluczowa liczba: wybór modelu jest najsilniejszą dźwignią kosztową, mocniejszą niż jakakolwiek inna optymalizacja.
Wyobraźcie sobie agenta przetwarzającego 100 zadań dziennie:
- Tani tier (ekwiwalent Flash/Haiku, 0,10–0,30 USD/1M tokenów wejściowych): nawet przy 50 000 tokenach na zadanie poruszacie się w rzędach euro dziennie. Miesięcznie kilkaset euro.
- Środkowy tier (ekwiwalent Sonnet, ~3–5 USD/1M tokenów wejściowych): to samo obciążenie może wyjść 1 000–3 000 euro miesięcznie.
- Tier premium (ekwiwalent Opus, ~15+ USD/1M tokenów wejściowych): to samo obciążenie może być 5–10× droższe niż środkowy tier.
Jeśli dodatkowo system działa z 12-procentowym wskaźnikiem retry, efektywnie płacicie za każde zadanie 1,12× — co przy większym wolumenie szybko się sumuje.
Eskalacja do człowieka to kolejny ukryty koszt: jeśli agent nie daje rady z 5 % zadań, a każda eskalacja do ludzkiego operatora kosztuje 2–10 euro (czas pracy), ten koszt może być wyższy niż sam token cost.
Cztery miejsca, w których koszty można skutecznie przyciąć
1. Skróć kontekst — systematycznie, nie przypadkowo
Największą oszczędnością nie jest tańszy model, ale mniej tokenów na wywołanie. Konkretne kroki:
- Kompresuj prompt systemowy. Każda zbędna linia w prompcie systemowym jest opłacana setki razy dziennie. Regularnie audytuj, co naprawdę tam potrzeba.
- Podsumowuj historię konwersacji. Zamiast wrzucać całą historię do kontekstu, pozwól agentowi po N krokach wygenerować streszczenie.
LangGraphma do tego wbudowany węzeł podsumowujący. Traci się trochę granularności, ale dla większości zadań to nie przeszkadza. - Filtruj wyniki narzędzi. Jeśli retrieval RAG zwróci pięć dokumentów, ale agent potrzebuje tylko jednego, niepotrzebnie płacicie za cztery. Ustaw reranking i ogranicz liczbę fragmentów trafiających do kontekstu.
- Ogranicz długość wyjścia. Strumień rozumowania nie zawsze musi być nieograniczony. Do standardowych kroków wystarczy krótka odpowiedź; szczegółowy chain-of-thought zostawiaj tylko dla naprawdę złożonych punktów decyzyjnych.
2. Routuj na tańszy model dla prostych kroków
Nie każdy krok agenta wymaga modelu frontier. Typowy rozkład:
- Kroki orkiestracyjne (co robić dalej, jakie narzędzie wywołać): zwykle radzi sobie tańszy model
- Retrieval i filtrowanie danych: tani model lub wręcz deterministyczna logika
- Końcowa synteza odpowiedzi dla użytkownika: tu warto sięgnąć po silniejszy model
- Weryfikacja i sprawdzenie self-consistency: tani model w pętli
LLM routing — dynamiczny wybór modelu według złożoności kroku — to optymalizacja, o której pisaliśmy oddzielnie w artykule o LLM routingu i cascadingu. W kontekście agentowym działa ta sama zasada: masz dispatcher, który klasyfikuje każdy krok i kieruje go do najtańszego modelu zdolnego go obsłużyć.
3. Prompt caching — prompt systemowy opłać raz
Prompt caching to technologia, którą Anthropic, OpenAI i Google oferują w swoich API. Zasada: jeśli początek kontekstu (typowo prompt systemowy lub długi statyczny dokument) powtarza się między wywołaniami, dostawca cachuje go po stronie serwera i za każde kolejne użycie nalicza ułamek standardowej ceny — rzędu –90 % na cachowaną część.
Dla agenta, który ma długi prompt systemowy i działa w dziesiątkach równoległych sesji, caching jest jedną z najszybciej wdrażalnych oszczędności. Szerzej omawiamy to w artykule o prompt cachingu i kosztach.
Warunek: caching dobrze działa przy stabilnych częściach promptu. Jeśli każde wywołanie zawiera inną dynamiczną treść na początku, cache hit rate będzie niski, a oszczędność minimalna.
4. Ustaw limity — przed wdrożeniem, nie po incydencie
To punkt, który w literaturze technicznej pojawia się jako przypis na dole, ale w praktyce jest prawem: agent bez twardych limitów to ryzyko finansowe.
max_steps(lub odpowiednik): maksymalna liczba kroków pętli przed zatrzymaniemmax_tokens_per_run: całkowity budżet tokenowy na jedno zadanietimeout: czas, po którym agent zatrzymuje się i zwraca wynik częściowycost_budget_per_day: na poziomie całego systemu, monitorowane alertem
Agent bez limitu max_steps może przy nieoczekiwanym wejściu lub problemie z zależnością narzędzia utknąć w pętli i przez noc wygenerować tysiące wywołań — z rachunkiem rzędu tysięcy euro. To nie jest scenariusz hipotetyczny. Widzimy to w systemach produkcyjnych i zawsze można temu zapobiec.
Agentic RAG: gdzie koszty eskalują niepostrzeżenie
Agentic RAG — czyli RAG, w którym agent samodzielnie decyduje, ile razy i co pobrać — jest 5–10× droższy niż klasyczny RAG. Nie dlatego, że jest zły, ale dlatego, że wykonuje więcej pracy.
Typowa sekwencja agentic RAG dla jednego pytania:
- 1.Decyzja, jakiej strategii retrieval użyć (1 wywołanie LLM)
- 2.Pierwsze wyszukiwanie (retrieval + reranking)
- 3.Ocena, czy wyniki są wystarczające (1 wywołanie LLM)
- 4.Ewentualne kolejne wyszukiwanie ze zmodyfikowanym zapytaniem (retrieval + reranking)
- 5.Synteza odpowiedzi (1 wywołanie LLM z całym zebranym kontekstem)
Każdy krok ma cenę. Jeśli dodatkowo używacie silnego modelu przy każdym z tych wywołań, koszty rosną szybko.
Optymalizacja: użyjcie taniego modelu do kroków decyzyjnych (1, 3) i silnego modelu tylko do końcowej syntezy (5). I ustalcie limit liczby iteracji retrieval — większość pytań rozwiązuje się w 1–2 rundach, nie w pięciu.
Więcej o architekturze agentic RAG znajdziecie w artykule Agentic RAG — jak to działa w praktyce.
Batch API: gdy nie musisz czekać na wynik natychmiast
Jeśli macie zadania, które nie wymagają odpowiedzi w czasie rzeczywistym — przetwarzanie dokumentów offline, nocne analizy, dane treningowe — Batch API to znaczna oszczędność. Anthropic (i inni dostawcy) oferują –50 % na wywołania batch w stosunku do ceny synchronicznej, kosztem przetwarzania z opóźnieniem kilku godzin.
Architektura: system front-end zbiera zadania w kolejce, batch job uruchamia się w nocy lub gdy obciążenie jest niskie, wyniki zapisują się do bazy danych i są dostępne rano. Dla wielu aplikacji przemysłowych — streszczenia raportów, kategoryzacja dokumentacji, ekstrakcja danych z PDF — to podejście jest rzędu wielkości tańsze.
Mierzenie kosztów: co śledzić w produkcji
Token cost bez observability to czarna skrzynka. Zalecamy monitorowanie co najmniej tych metryk:
- Cost per task type — różne typy zadań mają różny profil kosztowy. Bez tego rozróżnienia nie wiesz, gdzie optymalizować.
- Retry rate per tool — które narzędzie najczęściej powoduje retry? To błąd narzędzia czy słaby opis w schemacie?
- Average steps per run — jeśli średnia to 8 kroków tam, gdzie zakładaliście 4, warto przyjrzeć się architekturze.
- Cache hit rate — jeśli macie prompt caching, jaki procent wywołań faktycznie korzysta z cache? Poniżej 60 % oznacza, że caching jest źle skonfigurowany.
- Human escalation rate — jaki procent zadań kończy się eskalacją? Jeśli rośnie, agent prawdopodobnie nie radzi sobie ze scenariuszami, do których nie był zaprojektowany.
Narzędzia takie jak Langfuse (self-hostable, framework-agnostic) lub LangSmith (głęboka integracja z LangGraph) przechwytują te metryki na poziomie każdego węzła i wywołania. Bez observability jesteście ślepi — więcej na ten temat w artykule o observability agentów AI.
Open-weight modele jako alternatywa kosztowa
Dla zespołów, którym zależy przede wszystkim na stronie kosztowej, aktualne modele open-weight są realną alternatywą. Rodziny takie jak Qwen 3.x, DeepSeek czy Llama 4 osiągają w wielu benchmarkach agentowych wyniki porównywalne z zamkniętymi modelami frontier — przy zerowych lub minimalnych kosztach API, jeśli działają on-premises.
Płacicie za serwer GPU zamiast za API. Przy dużych wolumenach zadań (dziesiątki tysięcy wywołań dziennie) break-even point zwykle mieści się w horyzoncie miesięcy. W środowiskach regulowanych, gdzie dane nie mogą opuszczać firmy, on-prem jest dodatkowo wymogiem zgodności z przepisami, nie tylko kwestią kosztową.
Kompromis: on-prem wymaga nakładów inżynieryjnych na zarządzanie infrastrukturą, serving stack (vLLM, SGLang), monitoring i aktualizacje modeli. Nie każdy zespół to ma.
Najczęstsze pytania
Dlaczego mój agent jest dużo droższy, niż pierwotnie szacowałem?
Najczęstszą przyczyną jest kombinacja trzech czynników: rosnąca historia w kontekście przy każdym kroku pętli, wywołania retry przy awariach narzędzi oraz długie prompty systemowe powtarzane przy każdym wywołaniu. Prototyp testuje zwykle 1–2 kroki ze statycznymi wejściami. Produkcja oznacza rzeczywiste wejścia, rzeczywiste błędy narzędzi i użytkowników, którzy doprowadzają agenta do nieoczekiwanych stanów. Zalecamy profilowanie kosztu na jedno uruchomienie z podziałem na składniki (prompt systemowy, historia, wyniki narzędzi, wyjście) zanim zaczynacie optymalizować.
Czy warto wdrożyć prompt caching?
Jeśli masz prompt systemowy dłuższy niż 1 000 tokenów, a agent działa w dziesiątkach lub setkach sesji dziennie — tak, warto prawie zawsze. Implementacja jest zazwyczaj prosta (parametr przy wywołaniu API), a oszczędność na cachowanej części to rzędu –90 % u Anthropica. Warunkiem jest stabilność początku kontekstu — jeśli prompt systemowy zmienia się przy każdym wywołaniu, cache hit rate będzie niski.
Kiedy opłaca się przejść z API na model on-prem?
Zależy od wolumenu i wymogów compliance. Jako orientacyjna zasada: gdy miesięczny rachunek za API przekracza koszt dedykowanego serwera GPU (włącznie z obsługą i amortyzacją sprzętu) — typowo gdzieś w okolicach kilku tysięcy euro miesięcznie — warto przeprowadzić analizę. W branżach regulowanych (ochrona zdrowia, prawo, finanse) on-prem to przy tym wymóg zgodności z RODO, nie tylko kwestia kosztów.
Jak ustawić rozsądny limit max_steps?
Zacznijcie od profilowania — ile kroków rzeczywiście potrzebuje typowe zadanie? Jeśli mediana to 4 kroki, a 95. percentyl to 8, ustawcie limit na 12–15 z marginesem bezpieczeństwa. Limit powinien być wystarczająco wysoki, żeby nie przerywać legalnie długich zadań, ale wystarczająco niski, żeby wychwycić nieskończone pętle. Kombinacja max_steps + timeout + alert monitoringowy dla przebiegów przekraczających 80 % limitu jest w praktyce solidna.
Co jest większym kosztem — tokeny czy eskalacja do człowieka?
Zależy od wskaźnika eskalacji. Jeśli agent eskaluje 1–2 % zadań, a czas pracy człowieka kosztuje 5 euro na incydent, to przy 1 000 zadaniach dziennie mamy 50–100 euro/dzień na eskalacje — co może przewyższyć token cost tańszego modelu. W systemach z wysokim wolumenem zadań i niezerowym wskaźnikiem eskalacji zmniejszanie eskalacji (lepsze szkolenie agenta, wyraźniejsze guardrails) to lepsza inwestycja niż oszczędzanie na tokenach.
*Koszty agenta w produkcji są mierzalne i kontrolowalne — ale tylko wtedy, gdy naprawdę je mierzymy. W MP Industrial Solutions pomagamy firmom zaprojektować systemy agentowe z jasnym profilem kosztowym od samego początku, zamiast optymalizować retrospektywnie po tym, jak pierwszy miesięczny rachunek ich zaskoczy. Jeśli planujecie wdrożenie agenta i chcecie przygotować realistyczny model kosztowy jeszcze przed implementacją, chętnie porozmawiamy.*