Agent AI wpada w pętlę retry i po cichu spala budżet API: dlaczego limit kosztu powinien być częścią produktu

Agent AI nie musi się zawiesić, żeby zrobić szkody. Wystarczy, że zacznie poprawnie wykonywać źle zaprojektowaną logikę retry. Model zwraca błąd, narzędzie nie odpowiada, API oddaje 429 albo 5xx, więc agent próbuje ponownie. Potem jeszcze raz. I jeszcze. Z perspektywy użytkownika nic szczególnego się nie dzieje: ekran pokazuje „pracuję”, zadanie ostatecznie kończy się błędem albo wraca po kilku minutach. W tle rośnie jednak liczba wywołań modeli, wyszukiwań, embeddingów, zapytań do zewnętrznych API i ponownie przesyłanych tokenów kontekstu.

Najgorszy wariant nie polega na tym, że pojedyncze wywołanie kosztuje dużo. Problem zaczyna się wtedy, gdy koszt jednego błędu jest mnożony przez automatyczne ponowienia, podagentów i kolejne kroki workflow.

Jeżeli agent ma wykonać 12 kroków, w każdym może wykonać do trzech prób, a dodatkowo korzysta z dwóch narzędzi, pozornie niewielki proces może wygenerować dziesiątki płatnych operacji. W systemie obsługującym tysiące zadań dziennie taki błąd przestaje być problemem technicznym. Staje się problemem finansowym.

Dlatego limit kosztu nie powinien być ustawieniem administracyjnym dopisanym po wdrożeniu. Powinien być jednym z podstawowych parametrów produktu, podobnie jak timeout, limit rozmiaru pliku czy maksymalna liczba rekordów w eksporcie.

Retry jest potrzebne. Nieograniczone retry jest błędem projektowym

Ponawianie nieudanej operacji samo w sobie jest poprawnym mechanizmem. Sieć potrafi zerwać połączenie, dostawca modelu może chwilowo przeciążyć usługę, zewnętrzne API zwróci 502, a system objęty rate limitingiem odpowie kodem 429. Rezygnacja po pierwszej nieudanej próbie obniżałaby niezawodność aplikacji.

Problem zaczyna się wtedy, gdy agent nie rozróżnia błędu przejściowego od błędu, którego ponowienie nie naprawi.

Typowy mechanizm powinien wyglądać mniej więcej tak:

• pierwsza próba,

• retry po krótkim opóźnieniu,

• kolejna próba po dłuższym czasie,

• maksymalna liczba prób,

• przerwanie operacji i zapisanie przyczyny.

Dla błędów chwilowych sens ma exponential backoff z jitterem, czyli coraz dłuższe odstępy z niewielkim losowym przesunięciem. Przykładowo: 1 s, około 2 s, około 4 s i około 8 s. Losowość zapobiega sytuacji, w której tysiące klientów ponawiają żądania dokładnie w tej samej sekundzie po zakończeniu awarii.

Nie każdy błąd powinien jednak uruchamiać retry.

Kod 429 może uzasadniać kolejną próbę, szczególnie jeśli serwer zwraca informację o czasie oczekiwania. Błąd 502 lub 503 również często jest przejściowy. Natomiast błędny parametr, niewłaściwy format danych czy brak wymaganych uprawnień zwykle nie znikną tylko dlatego, że agent wyśle identyczne żądanie jeszcze pięć razy.

Jeszcze groźniejszy przypadek pojawia się w agentach, które same interpretują wynik wcześniejszego kroku. Model może uznać:

Dla programu wygląda to rozsądnie. Dla systemu billingowego oznacza następne wywołanie.

Jeżeli przed każdą próbą do modelu przesyłany jest cały dotychczasowy kontekst, koszt kolejnych prób może nawet rosnąć. Pierwsze wywołanie ma przykładowo 8 tys. tokenów wejściowych, następne 11 tys., kolejne 15 tys., bo historia zawiera już odpowiedzi modelu, błędy narzędzi oraz dodatkowe instrukcje.

Łatwo zobaczyć skalę na prostym modelu kosztowym. Załóżmy roboczo stawkę:

• 10 USD za 1 mln tokenów wejściowych,

• 30 USD za 1 mln tokenów wyjściowych.

Jedna operacja zużywająca 20 tys. tokenów wejściowych i 3 tys. tokenów wyjściowych kosztuje wtedy około 0,29 USD.

Sześć podobnych prób to już około 1,74 USD.

Przy 1000 takich przypadków miesięcznie mamy 1740 USD, czyli przy kursie rzędu 3,8–4,0 zł za dolara około 6,6–7 tys. zł. To nie jest prognoza konkretnego cennika dostawcy, lecz pokazanie mechanizmu: retry mnoży koszt dokładnie tak samo, jak mnoży liczbę requestów.

W praktyce widziałbym trzy limity, których nie wolno ze sobą mylić:

Limit prób określa, ile razy można powtórzyć daną operację.

Limit kroków mówi, jak długo agent może rozwijać swoje rozumowanie i korzystać z narzędzi.

Limit kosztu odpowiada na najważniejsze pytanie biznesowe: ile maksymalnie wolno wydać na wykonanie konkretnego zadania.

Pierwsze dwa zabezpieczenia nie zastępują trzeciego. Agent może przecież zmieścić się w dozwolonych 20 krokach i nadal zużyć nieakceptowalną ilość drogich tokenów.

Budżet wykonania powinien zatrzymać agenta zanim zrobi to faktura

W klasycznej aplikacji SaaS użytkownik wykonuje operację, której koszt infrastruktury jest względnie przewidywalny. Zapytanie SQL, zapis rekordu albo wygenerowanie pliku ma zazwyczaj ograniczony profil zużycia zasobów.

W agentach AI sytuacja jest inna. Koszt wykonania jest dynamiczny. Zależy od długości promptu, długości odpowiedzi, liczby użytych narzędzi, modelu, liczby retry, rozmiaru historii rozmowy i sposobu działania samego agenta.

Dlatego budżet powinien być przypisany do wykonania, a nie tylko do całego konta.

Najprostszy wariant to:

max_cost_per_run = 0,50 USD

Agent przed następnym krokiem sprawdza koszt już wykonanych operacji oraz przewidywany koszt kolejnej. Jeśli pozostały budżet jest zbyt mały, zatrzymuje zadanie.

W produkcie komercyjnym jeden limit zwykle nie wystarczy. Sensowniejsza hierarchia wygląda tak:

• limit pojedynczego requestu, np. 0,10 USD,

• limit pojedynczego wykonania agenta, np. 0,50 USD,

• limit użytkownika na godzinę lub dobę, np. 5 USD dziennie,

• limit workspace’u lub firmy, np. 500 USD miesięcznie,

• globalny bezpiecznik platformy.

Konkretne wartości zależą oczywiście od ekonomii produktu. Inaczej ustawia się agent generujący opis produktu za kilka groszy, a inaczej system analizujący dokumentację techniczną liczącą kilkaset stron.

Istotny jest mechanizm.

Załóżmy, że aplikacja sprzedaje użytkownikowi operację za 2 zł. Jeżeli normalny koszt AI wynosi 0,15 zł, marża wygląda bezpiecznie. Nie oznacza to jednak, że agent może mieć budżet 2 zł. Przy takim ustawieniu pojedyncza nietypowa operacja może zjeść całą marżę.

Rozsądniej ustalić na przykład:

• oczekiwany koszt: 0,10–0,20 zł,

• próg ostrzegawczy: 0,30 zł,

• twardy limit: 0,50 zł.

Po przekroczeniu 0,30 zł można przejść na tańszy model, ograniczyć kontekst albo wyłączyć część opcjonalnych narzędzi. Przy 0,50 zł operacja jest kończona.

To ważne rozróżnienie. Budżet nie musi oznaczać natychmiastowego przerwania zadania. Może sterować degradacją jakości.

Praktyczna kolejność może wyglądać tak:

1. pełny model i pełen zestaw narzędzi,

2. po wykorzystaniu 60% budżetu wyłączenie operacji dodatkowych,

3. przy 75% ograniczenie maksymalnej długości odpowiedzi,

4. przy 85% przełączenie części kroków na tańszy model,

5. przy 100% bezwarunkowe zakończenie procesu.

Nie stosowałbym jednak automatycznej zmiany modelu w każdym produkcie. Inny model może inaczej obsługiwać structured output, narzędzia albo długi kontekst. Jeżeli fallback nie został przetestowany, lepiej przerwać wykonanie niż otrzymać pozornie poprawny, ale niespójny rezultat.

Drugie istotne zabezpieczenie to budżet tokenów.

Przykładowo agent może dostać:

• 150 tys. tokenów wejściowych na całe wykonanie,

• 20 tys. tokenów wyjściowych,

• maksymalnie 12 wywołań modelu,

• maksymalnie 3 próby jednego narzędzia.

Sam limit tokenów także nie zastępuje limitu pieniędzy, ponieważ poszczególne modele mają różne ceny. Jest jednak świetnym zabezpieczeniem przed rosnącym kontekstem.

Trzecim elementem jest deadline. Jeśli operacja ma zostać wykonana w 30 sekund, retry uruchomione po 28. sekundzie często nie ma już biznesowego sensu. Agent nie powinien pytać tylko: „czy mogę ponowić?”. Powinien sprawdzić jednocześnie:

Czy mam jeszcze próby? Czy mam budżet? Czy mam czas?

Jeżeli choć jedna odpowiedź brzmi „nie”, workflow powinien się zakończyć.

Bez telemetrii limit kosztu szybko stanie się kolejną liczbą w konfiguracji

Najczęstszy błąd pojawia się po wdrożeniu ograniczenia: zespół ustawia max_retries=3, limit kosztu na zadanie i uznaje problem za zamknięty.

Nie jest.

Bez mierzenia przepływu pieniędzy trudno ustalić, czy limit jest za niski, za wysoki albo czy koszt rośnie przez retry, niepotrzebnie długi prompt czy wadliwe narzędzie.

Każde wykonanie agenta powinno mieć własny identyfikator, a każda płatna operacja powinna zapisywać przynajmniej:

• identyfikator użytkownika i wykonania,

• nazwę modelu,

• liczbę tokenów wejściowych,

• liczbę tokenów wyjściowych,

• koszt operacji,

• koszt narastający całego wykonania,

• nazwę wywołanego narzędzia,

• numer próby,

• typ błędu,

• czas odpowiedzi,

• przyczynę zakończenia workflow.

Dzięki temu można szybko odpowiedzieć na pytanie, którego sama faktura od operatora modelu nie rozwiąże: dlaczego konkretny agent kosztował 4,70 USD, skoro mediana wynosi 0,18 USD?

W dobrym systemie odpowiedź nie wymaga czytania logów ręcznie.

Dashboard powinien pokazywać co najmniej:

koszt na successful run,
koszt na failed run,
średnią liczbę retry,
95. i 99. percentyl kosztu pojedynczego wykonania,
udział wykonania zakończonych przez limit budżetu,
koszt według modelu, narzędzia i typu zadania.

Szczególnie przydatny jest wskaźnik kosztu nieudanych operacji. Jeżeli poprawne wykonanie kosztuje średnio 0,20 zł, a błędne 0,95 zł, system ma prawdopodobnie problem z polityką ponowień. Błąd nie powinien być pięć razy droższy od sukcesu tylko dlatego, że aplikacja długo próbuje ratować operację, której uratować się nie da.

Alarmowanie też musi być wielopoziomowe.

Alert po przekroczeniu miesięcznego budżetu jest spóźniony. Sensowne są wcześniejsze sygnały:

• pojedynczy run kosztuje ponad pięciokrotność mediany,

• średni koszt wykonania wzrósł o 30% w ciągu godziny,

• liczba błędów 429 lub 5xx przekroczyła normalny poziom,

• udział retry przekracza ustalony próg,

• koszt na użytkownika rośnie nienaturalnie szybko.

Przy dużym ruchu przydaje się również circuit breaker. Jeśli zewnętrzna usługa zaczyna masowo zwracać błędy, kolejne requesty nie powinny być wysyłane tylko po to, żeby potwierdzić, że usługa nadal nie działa. Obwód zostaje chwilowo otwarty, żądania są odrzucane lub kolejkowane, a po określonym czasie system wykonuje ograniczoną próbę kontrolną.

To często skuteczniejsze niż zwiększanie retry.

Jest jeszcze jeden szczegół, który regularnie powoduje niepotrzebne wydatki: brak idempotencji. Ponowienie płatnej lub zmieniającej stan operacji nie może bezkrytycznie wykonywać jej drugi raz. Dotyczy to nie tylko płatności. Agent może dwukrotnie utworzyć dokument, wysłać wiadomość, zamówić usługę albo uruchomić kosztowne przetwarzanie danych. Tam, gdzie API to obsługuje, należy używać idempotency key. W innych przypadkach potrzebny jest własny mechanizm wykrywania duplikatów.

Trzeba też rozdzielić retry na poziomie infrastruktury i retry wykonywane przez samego agenta. Jeśli biblioteka HTTP robi trzy próby, SDK modelu kolejne trzy, a agent po niepowodzeniu jeszcze trzy razy ponawia cały krok, te wartości nie sumują się do dziewięciu. W skrajnym przypadku mogą się mnożyć.

Dlatego w realnym wdrożeniu najpierw rozpisuję pełny łańcuch:

agent → SDK modelu → klient HTTP → proxy/API gateway → dostawca

i sprawdzam, gdzie dokładnie działa automatyczne ponawianie. Bardzo często retry znajduje się w dwóch miejscach, o których zespół aplikacyjny nawet nie pamięta.

Po stronie produktu użytkownik powinien natomiast dostać czytelny komunikat. „Internal server error” jest mało użyteczne. Lepszy komunikat brzmi wprost: zadanie zostało przerwane po osiągnięciu limitu wykonania, a częściowy rezultat został zachowany, jeśli można go bezpiecznie wykorzystać.

Istotna jest też możliwość świadomego ponowienia przez użytkownika. Jeśli poprzednie wykonanie wykorzystało 100% budżetu, kliknięcie „spróbuj ponownie” powinno tworzyć nowy run z nowym budżetem, a nie wskrzeszać tę samą niekontrolowaną pętlę.

Przy projektowaniu takich mechanizmów dobrze patrzeć na agenta jak na usługę, która zużywa mierzalne zasoby, a nie jak na „inteligentny chat”. Dopiero wtedy limity kosztu, obserwowalność, retry i kontrola błędów zaczynają tworzyć spójną architekturę produktu.

Więcej informacji na: https://itux.pl

FAQ: limity kosztów i retry w agentach AI

Czy samo ustawienie max_retries=3 wystarczy?
Nie. Ogranicza liczbę prób w konkretnym miejscu, ale nie kontroluje łącznej liczby wywołań modelu, narzędzi ani podagentów. Potrzebny jest osobny limit kosztu całego wykonania.

Ile retry powinien mieć agent AI?
Dla pojedynczego wywołania zwykle rozsądnym punktem startowym są 2–3 ponowienia błędu przejściowego. Nie należy jednak automatycznie ponawiać błędów wynikających z nieprawidłowych danych, braku uprawnień lub logicznie błędnego żądania.

Czy limit tokenów wystarczy zamiast limitu pieniędzy?
Nie. Ten sam milion tokenów może mieć różny koszt zależnie od modelu i rodzaju tokenów. Limit tokenów kontroluje rozmiar przetwarzania, natomiast limit pieniężny kontroluje ekonomię wykonania.

Czy agent powinien automatycznie przełączać się na tańszy model po przekroczeniu budżetu?
Tylko jeśli taka ścieżka została wcześniej przetestowana. Tańszy model może inaczej obsługiwać narzędzia, structured output lub długi kontekst. Bez testów bezpieczniej zakończyć zadanie niż zwrócić użytkownikowi nieprzewidywalny rezultat.

Co mierzyć jako pierwsze?
Koszt pojedynczego wykonania, koszt nieudanych wykonań, liczbę retry oraz 95. i 99. percentyl kosztu. Sama średnia potrafi ukryć niewielką grupę agentów spalających wielokrotność normalnego budżetu.

Czy limit miesięczny konta chroni przed pętlą retry?
Chroni dopiero na końcu. Zanim zostanie osiągnięty, pojedynczy wadliwy workflow może zużyć znaczną część budżetu. Dlatego twardy limit powinien działać również na poziomie pojedynczego runu.

Od czego zacząć wdrożenie ochrony kosztowej?
Najpierw usuń nieograniczone retry i policz wszystkie miejsca, w których request może być ponowiony: agent, SDK, klient HTTP, gateway i zewnętrzne API. Następnie dodaj twardy budżet pojedynczego wykonania liczony przed każdym płatnym krokiem. Dopiero później optymalizuj prompty, wybór modeli i cache. Jeśli system może dziś wykonać płatne wywołanie bez sprawdzenia, ile już wydał w ramach danego zadania, to właśnie ten błąd należy usunąć w pierwszej kolejności.