Jak ograniczyć koszty agenta AI działającego na VPS

Jak zapobiec generowaniu wysokich kosztów przez stale działającego agenta AI

Kontrola kosztów agenta AI na serwerze VPS (virtual private server) polega na ustaleniu limitów przed uruchomieniem agenta, ponieważ nikt nie monitoruje licznika w trakcie jego pracy. Należy ograniczyć każdą odpowiedź za pomocą max_tokens, ograniczyć liczbę iteracji pętli we własnym kodzie, buforować niezmienne części promptu oraz logować zużycie dla każdej odpowiedzi, aby zidentyfikować najbardziej kosztowne zadania. Opłata za wynajem serwera jest stała i miesięczna. API modelu jest rozliczane za token, a niekontrolowana pętla może szybko generować wysokie koszty.

Poniższe wskazówki dotyczą istniejącego agenta, który wywołuje Messages API z posiadanego serwera. Artykuł Tworzenie agenta AI z Claude na VPS opisuje techniczne aspekty tego rozwiązania.

Dlaczego agent działający w tle generuje inne koszty

Sesja interaktywna wymaga obecności człowieka. Gdy model obiera błędną ścieżkę lub analizuje log o długości 40 000 linii, obserwujący użytkownik przerywa jego pracę. Agent działający w tle nie posiada takiego zabezpieczenia: wykonuje zadania do momentu zakończenia pętli, po czym timer uruchamia go ponownie.

Częstotliwość to mnożnik, który jest często pomijany. Zadanie uruchamiane co pięć minut wykonuje się 288 razy dziennie i około 8 640 razy w miesiącu. Koszt pojedynczego uruchomienia należy pomnożyć przez tę liczbę. Wiele agentów typu "always-on" nie musi działać w sposób ciągły. Wystarczy, że odpowiedzą w określonym czasie, co można zrealizować za pomocą harmonogramu.

Agent generuje również koszty, których nie ma w oknie czatu.

• Definicje narzędzi są przesyłane w każdym żądaniu. Systemowy prompt dotyczący użycia narzędzi kosztuje 290 tokenów w modelu Claude Opus 4.8 przy tool_choice z auto lub none oraz 410 przy any lub tool. Narzędzie bash dodaje kolejne 325 tokenów. Każdy podłączony serwer MCP zwiększa ten ciężar o swoje schematy, zgodnie ze specyfikacją MCP (Model Context Protocol).
• Wyniki działania narzędzi są tokenami wejściowymi. Polecenie, które wypisuje 8 000 linii, wprowadza 8 000 linii do kolejnego żądania oraz do każdego następnego żądania w ramach tej samej tury.
• Pobrane strony są tokenami wejściowymi. Przeciętna strona internetowa o rozmiarze 10 kB to około 2 500 tokenów, a plik PDF z wynikami badań o rozmiarze 500 kB to około 125 000 tokenów. max_content_tokens ucina tylko tekst, ponieważ "dotyczy zawartości tekstowej, a nie binarnej, takiej jak pliki PDF". Pliki PDF należy ograniczać za pomocą max_uses oraz allowed_domains.
• Wyszukiwanie w sieci jest płatne za każde zapytanie, w cenie 10 USD za 1 000 wyszukiwań, niezależnie od liczby zwróconych wyników. Wyszukiwanie, które zakończy się błędem, nie jest rozliczane.

Żaden z tych elementów nie jest kosztowny przy jednorazowym użyciu. Wszystkie stają się kosztowne przy 8 640 powtórzeniach.

Twarde i miękkie limity rozwiązują różne problemy

max_tokens jest wymuszany. Jest to twardy limit całkowitej liczby tokenów wyjściowych dla pojedynczego żądania, obejmujący zarówno proces myślowy, jak i tekst odpowiedzi. Claude nigdy nie generuje treści poza tym limitem, a model nie ma wglądu w tę wartość. Osiągnięcie limitu skutkuje stop_reason: "max_tokens" oraz ucięciem odpowiedzi. Uwaga dla agentów: każde żądanie w pętli użycia narzędzi posiada własny max_tokens, więc ogranicza on pojedynczą odpowiedź, a nie całe zadanie. Dziesięć wywołań narzędzi przy limicie 4,000 tokenów oznacza limit 40,000 tokenów dla całej tury.

Budżet zadania ma charakter doradczy. task_budget znajduje się wewnątrz output_config i informuje model, ile tokenów ma do dyspozycji na całą pętlę agenta, wliczając w to proces myślowy, wywołania narzędzi, wyniki narzędzi oraz dane wyjściowe.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Budżety zadań to miękka wskazówka, a nie twardy limit." Claude może przekroczyć budżet w trakcie działania, a wymuszony limit wyjściowy nadal wynosi max_tokens. "Odliczanie jest widoczne tylko dla modelu", a odpowiedzi nie zawierają pola pozostałego budżetu. Minimalna akceptowana wartość task_budget.total wynosi 20,000 tokenów; podanie mniejszej wartości zwraca błąd 400. Budżet zbyt mały dla danego zadania powoduje zachowanie przypominające odmowę, przez co model ogranicza zakres zadania lub kończy pracę przedwcześnie.

Jeden szczegół generuje koszty zamiast oszczędności. Jeśli klient zmniejsza wartość task_budget.remaining przy każdym kolejnym żądaniu, zmieniona wartość unieważnia każdy buforowany prefiks, który ją zawiera. Wartość należy ustawić jednorazowo, przy pierwszym żądaniu.

Budżety zadań są w fazie beta dla modeli Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 oraz Claude Haiku 5.5. Modele Claude Sonnet 5 oraz Claude Haiku 4.5 są oznaczone jako Not supported, a budżety zadań nie mają zastosowania do Claude Code, dlatego sesja Claude Code odłączona w tmux zależy od higieny sesji.

Trzeci limit znajduje się w Claude Console: należy przydzielić agentowi własny obszar roboczy, a następnie ustawić w nim miesięczny limit wydatków oraz limity szybkości na minutę. "Nie można ustawić limitów dla domyślnego obszaru roboczego", a "limity dla całej organizacji mają zawsze pierwszeństwo, nawet jeśli suma limitów obszarów roboczych jest wyższa". Należy skonfigurować powiadomienia o wydatkach, aby próg ostrzegał przed osiągnięciem limitu.

Wybór modelu dla zadania i czynniki wpływające na nakład pracy

Wybór modelu jest decyzją podejmowaną dla każdego zadania z osobna. Według stanu na październik 2026 roku, ceny za milion tokenów (wejściowych i wyjściowych) kształtują się następująco: Claude Fable 5.1 oraz Fable 5 kosztują 10 USD i 50 USD, Claude Opus 5.5 kosztuje 4 USD i 20 USD, Claude Opus 5, Opus 4.8 oraz Opus 4.7 kosztują 5 USD i 25 USD, Claude Sonnet 5.5 oraz Sonnet 5 kosztują 2 USD i 10 USD, Claude Haiku 5.5 kosztuje 0,10 USD i 0,50 USD dla promptów do 100 000 tokenów (powyżej tej wartości 0,50 USD i 2,50 USD, z uwzględnieniem tokenów w pamięci podręcznej), a Claude Haiku 4.5 kosztuje 1 USD i 5 USD. Anthropic początkowo oferował Sonnet 5 w tej cenie jako stawkę promocyjną, po czym uczynił ją standardową i anulował planowaną podwyżkę do 3 USD i 15 USD. Zadanie polegające wyłącznie na klasyfikacji linii logów nie wymaga modelu Opus.

Nie należy polegać na darmowym wykorzystaniu w przypadku intensywnego harmonogramu. Poza niewielkim kredytem przyznawanym przez Claude API przy rejestracji, jedynym cyklicznym limitem jest miesięczny kredyt API zawarty w planach Claude Max i Team: 100 USD w Max 5x, 200 USD w Max 20x oraz do 500 USD w puli dla planu Team, odnawiany w każdym cyklu rozliczeniowym. Kredyt można odebrać po 7 dniach korzystania z kwalifikującego się planu; nie jest wymagana metoda płatności. Obejmuje on Claude API, Managed Agents, Agent SDK oraz playground, ale nie Claude Code. Kredyt wygasa z końcem każdego cyklu i nie przechodzi na kolejny okres. Jego wykorzystanie wlicza się do limitu wydatków, a po jego wyczerpaniu żądania są wstrzymywane, chyba że organizacja posiada również zakupione kredyty.

Drugim czynnikiem jest nakład pracy (effort). output_config.effort akceptuje low, medium, high, xhigh oraz max, choć nie każdy model obsługuje każdy poziom. Wartością domyślną jest high dla większości modeli oraz medium dla Claude Opus 5.5 i Claude Haiku 5.5. Jawne ustawienie wartości domyślnej modelu jest równoważne jej pominięciu. Niższy nakład pracy ogranicza nie tylko długość rozumowania: dokumentacja wskazuje, że sprawia on, iż Claude wykonuje mniej wywołań narzędzi i łączy wiele operacji w mniejszą liczbę wywołań. W przypadku agenta jest to większa oszczędność, ponieważ uniknięte wywołanie narzędzia to całe żądanie, które nie zostaje wysłane.

Pułapką jest to, że nakład pracy wpływa na pamięć podręczną. Zmiana wartości na najwyższym poziomie między żądaniami unieważnia prompt caching. W udokumentowanym przykładzie dla Claude Opus 5.5 żądanie 2 zgłosiło cache_read_input_tokens: 3546. Żądanie 3 zmieniło nakład pracy z medium (wartość domyślna modelu) na low i zgłosiło cache_creation_input_tokens z 3546 oraz cache_read_input_tokens z 0. Należy zatem różnicować nakład pracy między obciążeniami, nigdy wewnątrz jednej konwersacji korzystającej z pamięci podręcznej. Istnieją dwie metody zmiany głębokości bez naruszania pamięci podręcznej. W modelach Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 oraz Haiku 5.5 zmiana nakładu pracy dla pojedynczej wiadomości (wersja beta, nagłówek mid-conversation-output-config-2026-07-01) ustawia nowy poziom, pozostawiając prefiks w pamięci podręcznej bez zmian. W każdym modelu można również sterować tym w prompcie: linia typu "Answer directly without deliberating." w najnowszej wiadomości użytkownika pozostawia wcześniejsze punkty podziału nienaruszone. W przypadku Claude Haiku 5.5 fraza ta nie redukuje jednak procesu myślowego w sposób niezawodny.

Tokeny myślowe są rozliczane według stawek wyjściowych i wliczają się do max_tokens, dlatego ucięta odpowiedź często oznacza, że proces myślowy wyczerpał budżet. Należy sprawdzić usage.output_tokens_details.thinking_tokens, aby poznać liczbę. Co faktycznie wypełnia rachunek za tokeny Claude szczegółowo wyjaśnia sposób naliczania opłat.

Buforowanie stabilnego prefiksu i zapobieganie jego przypadkowemu unieważnianiu

Zapis w pamięci podręcznej kosztuje 1,25 raza więcej niż podstawowa cena wejściowa w przypadku bufora pięciominutowego oraz 2 razy więcej w przypadku bufora jednogodzinnego. W większości modeli odczyt z pamięci podręcznej kosztuje 0,1 ceny podstawowej, zatem „buforowanie zwraca się po jednym odczycie dla czasu trwania 5 minut (zapis 1,25x) lub po dwóch odczytach dla czasu trwania 1 godziny (zapis 2x)”. Odczyty są jeszcze tańsze w najnowszych modelach: 0,05 raza w Claude Opus 5.5 i Claude Sonnet 5.5 oraz 0,025 raza w Claude Fable 5.1.

Jedno zdanie wyjaśnia, dlaczego jest to rozwiązanie korzystne dla agenta działającego w trybie ciągłym: „Pamięć podręczna jest odświeżana bez dodatkowych kosztów przy każdym użyciu zbuforowanej zawartości”. Zadanie uruchamiane co dwie minuty z wykorzystaniem pięciominutowego bufora utrzymuje prefiks w stanie aktywnym przez cały dzień przy koszcie jednego zapisu.

Istnieją trzy sposoby na utratę pamięci podręcznej bez zauważenia tego faktu.

Zmieniający się prefiks. „Prefiksy pamięci podręcznej są tworzone w następującej kolejności: tools, system, a następnie messages”. Każda zmiana bajtu na wcześniejszym etapie tej kolejności unieważnia wszystko, co następuje po niej, a edycja definicji narzędzi unieważnia całą pamięć podręczną. Klasycznym błędem jest umieszczanie znacznika czasu lub identyfikatora uruchomienia w systemowym prompcie: każde żądanie zawiera wtedy inny prefiks, zapisuje nowy wpis przy koszcie 1,25x i nie odczytuje żadnych danych. Sygnałem ostrzegawczym jest wartość usage.cache_read_input_tokens równa 0 przy identycznie wyglądających wywołaniach. Zmienne treści należy przenosić do najnowszej wiadomości użytkownika.

Zbyt krótki prefiks. Każdy model posiada minimalną długość podlegającą buforowaniu; poniżej tej wartości żądanie jest przetwarzane bez użycia pamięci podręcznej i „nie jest zwracany żaden błąd”. Wartości te obejmują 512 tokenów dla Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 oraz Haiku 5.5, 1024 dla Claude Opus 4.8 i Claude Sonnet 5 oraz 4096 dla Claude Haiku 4.5. Przeniesienie zadania z modelu Sonnet 5 na Haiku 4.5 może zatem spowodować ciche wyłączenie buforowania.

Konwersacja wykraczająca poza okno podglądu. „Okno podglądu obejmuje 20 bloków”. System sprawdza maksymalnie 20 pozycji na punkt przerwania, a następnie kończy działanie. W udokumentowanym przykładzie tura zawierająca 35 bloków z punktem przerwania na bloku 35 sprawdza bloki od 35 do 16. Wpis z poprzedniej tury znajdujący się w bloku 15 wypada poza okno, co skutkuje brakiem trafienia. Agent dołączający kilka bloków użycia narzędzi i wyników narzędzi w każdej turze przekracza limit 20 bloków w ciągu dwóch lub trzech tur. Dostępne są cztery punkty przerwania na żądanie, dlatego warto przeznaczyć jeden z nich na ostatnie wiadomości.

Przekieruj zadania, które mogą czekać, do Batches API

"Całe użycie jest rozliczane według 50% standardowych cen API", zarówno w przypadku danych wejściowych, jak i wyjściowych. Przetwarzanie wsadowe jest asynchroniczne, "a większość partii kończy się w czasie krótszym niż 1 godzina", z wynikami dostępnymi po zakończeniu wszystkich żądań lub po upływie 24 godzin, w zależności od tego, co nastąpi wcześniej. Jest to wartość typowa, a nie gwarantowana.

Należy odpytywać processing_status, aż status zmieni się na ended. Żądania zwracające errored, canceled lub expired nie są objęte opłatami. Jedno zastrzeżenie, jeśli polegasz na limicie wydatków: "partie mogą nieznacznie przekroczyć skonfigurowany limit wydatków Twojego obszaru roboczego".

Rabaty sumują się, a ponieważ partia może trwać dłużej niż pięć minut, dokumentacja zaleca jednogodzinny cache dla partii współdzielących kontekst. Podziel więc pracę: wszystko, na co czeka użytkownik lub webhook, pozostaje w ścieżce bezpośredniej, natomiast nocne zestawienia lub klasyfikacja logów z poprzedniego dnia trafiają do partii za połowę ceny.

Rejestruj pola użycia każdej odpowiedzi we własnym magazynie danych

Nie można przypisać wydatków, których nie odnotowano. Każda odpowiedź zawiera informację o swoim koszcie.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

Dołączaj jeden wiersz na każde wywołanie API do pliku w formacie JSON-lines, oznaczając go nazwą zadania. Po tygodniu można określić, które zadanie generuje koszty, a które jedynie sprawia wrażenie zajętego. Monitoruj cache_read: kolumna zer jest najczęstszym błędem powodującym koszty w przypadku agentów hostowanych samodzielnie.

Jedno pole jest łatwe do błędnej interpretacji. input_tokens zlicza tylko tokeny po ostatnim punkcie przerwania pamięci podręcznej, więc rzeczywisty rozmiar promptu to total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Agent raportujący input_tokens: 400 przy dużym prompcie nie jest tani: reszta pochodzi z pamięci podręcznej.

Zliczaj przed wysłaniem. Zliczanie tokenów jest bezpłatne, a jego limity szybkości są oddzielone od tworzenia wiadomości, więc użyj count_tokens, aby odrzucić zbyt duży załącznik zamiast płacić za odkrycie tego faktu. Wynik jest szacunkowy, więc należy dokonywać pomiarów dla każdego modelu z osobna i nigdy nie używać ponownie wyniku z tokenizera innego dostawcy. Modele Claude 4.7 i nowsze, w tym Claude Fable 5 oraz Claude Sonnet 5, używają nowszego tokenizera, który „generuje około 30% więcej tokenów dla tego samego tekstu”. Modele Claude Sonnet 4.6 i starsze, w tym Claude Haiku 4.5, używają poprzedniej wersji.

Autorytatywne dane zapewnia Admin API, raportując użycie w https://api.anthropic.com/v1/organizations/usage_report/messages oraz koszt w https://api.anthropic.com/v1/organizations/cost_report. Oba wymagają klucza administratora (sk-ant-admin01-...) przekazanego jako x-api-key: $ANTHROPIC_ADMIN_KEY z użyciem anthropic-version: 2023-06-01. Raport użycia akceptuje bucket_width=1d, group_by[]=model oraz api_key_ids[]=. Raport kosztów jest dostępny tylko w ujęciu dziennym i grupuje dane według workspace_id lub description. Jedno ograniczenie: „Admin API jest niedostępne dla kont indywidualnych”.

Parametr api_key_ids[] to tani sposób na przypisywanie kosztów: nadaj każdemu zadaniu własny klucz API, przefiltruj raport użycia za pomocą api_key_ids[] i podziel go według klucza za pomocą group_by[]=api_key_id. Filtr obsługuje wiele wartości, wymiar grupowania jest pojedynczy. Przechowuj klucze w zmiennych środowiskowych, a nie w kodzie, w sposób opisany w pierwsza aplikacja Claude API na VPS.

Ograniczenie pętli, ponieważ nic innego tego nie zrobi

Ograniczona liczba iteracji nie jest tutaj opcjonalna. Pętla należy do użytkownika, więc licznik również.

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

Żaden z powyższych limitów górnych nie wykona tego zadania za użytkownika: max_tokens ogranicza pojedynczą odpowiedź, a model otrzymuje jedynie informację o budżecie zadania. Hostowany produkt zatrzymałby działanie w tym miejscu, w sposób w jaki limit Claude dotyczący wywołań narzędzi w pojedynczej turze przerywa sesję, która wykonała ich zbyt wiele, ale samodzielnie napisana pętla nie posiada takiego zabezpieczenia, dopóki nie zostanie ono dodane.

Należy zastosować drugi hamulec poza procesem. Uruchom zadanie za pomocą systemd timer zamiast stałego procesu i nadaj jednostce usługi limit czasu rzeczywistego. Zadanie typu timer jest zazwyczaj Type=oneshot, a RuntimeMaxSec= „nie ma żadnego wpływu na usługi typu Type=oneshot”, dlatego należy ustawić tam TimeoutStartSec=600. Używaj RuntimeMaxSec=600 tylko w jednostce Type=simple. W obu przypadkach zawieszony proces zostanie zabity po dziesięciu minutach, zamiast działać w nieskończoność, dopóki nie zostanie zauważony. Uruchamianie programu jako usługi i timera systemd omawia same pliki jednostek. Przeanalizuj wyniki działania za pomocą journalctl -u triage-agent.service --since "1 hour ago".

Należy również ograniczyć liczbę ponownych prób, ponieważ procedura, która ponawia próbę w nieskończoność, nalicza koszty za każdą z nich. Błąd 429 lub 500 zasługuje na kilka prób z mechanizmem backoff. Błąd 400 nie zasługuje na żadną, ponieważ to samo żądanie zawsze kończy się tak samo.

Kontrola kosztów agenta AI zaczyna się od analizy własnych danych

Nikt nie jest w stanie określić kosztu agenta działającego w trybie ciągłym, ponieważ koszt ten stanowi iloczyn liczby tokenów na uruchomienie oraz liczby uruchomień na dobę, a obie te wartości zależą od użytkownika. Należy uruchomić agenta raz, odczytać zarejestrowany wiersz użycia i pomnożyć go przez planowaną częstotliwość. Dwa dni później należy porównać raport kosztów z wykonanymi obliczeniami. Jeśli wartości są rozbieżne, przyczyną jest niemal zawsze uszkodzona pamięć podręczna lub pętla, która działała dłużej, niż zakładano.

Powyższe założenie dotyczy klucza API, ponieważ agent jest własnym programem wywołującym Messages API. W przypadku pracy interaktywnej, sekcja który plan Claude pasuje do Twojego stylu pracy omawia kwestie subskrypcji. Każda cena i limit zostały zweryfikowane zgodnie z dokumentacją Anthropic w październiku 2026 roku, dlatego przed zaplanowaniem budżetu należy ponownie sprawdzić stronę z cennikiem.

FAQ

Ile kosztuje utrzymanie działającego w trybie ciągłym agenta AI na serwerze VPS?

Istnieją dwa rodzaje kosztów, z których tylko jeden jest przewidywalny. Serwer ma stałą miesięczną cenę. API modelu jest rozliczane za token, więc koszt stanowi iloczyn zużycia pojedynczego uruchomienia oraz częstotliwości wywołań. Anthropic nie publikuje szacunków dla samodzielnie hostowanego agenta działającego w trybie ciągłym, dlatego każdą podaną kwotę należy traktować jako przypuszczenie. Zarejestruj usage z jednego rzeczywistego uruchomienia i pomnóż przez swój harmonogram.

Jaka jest różnica między max_tokens a budżetem zadania?

max_tokens jest wymuszane i niewidoczne dla modelu. Ogranicza ono wyjście pojedynczego żądania, wliczając w to proces myślowy, a jego przekroczenie skutkuje stop_reason: "max_tokens". Budżet zadania to przeciwieństwo: model otrzymuje informację o liczbie i dostosowuje pętlę agenta do tego limitu, jednak "budżety zadań są miękką wskazówką, a nie twardym limitem", podczas gdy wymuszony limit to nadal max_tokens.

Dlaczego cache_read_input_tokens zawsze wynosi zero dla mojego agenta?

Ponieważ prefiks zmienia się między wywołaniami lub jest zbyt krótki, aby go zbuforować. Typową przyczyną jest znacznik czasu lub identyfikator uruchomienia wstawiony do systemowego promptu: pamięć podręczna jest indeksowana na podstawie prefiksu, więc każda zmiana bajtu unieważnia wszystko, co po nim następuje. Zmiana definicji narzędzi lub wartości effort na najwyższym poziomie powoduje to samo. W przeciwnym razie przyczyną jest rozmiar, ponieważ krótsze prompty nie są buforowane i nie jest zwracany żaden błąd.

Jak powstrzymać agenta AI przed zapętleniem?

Zliczaj iteracje w kodzie pętli i zatrzymaj się przy ustalonej wartości maksymalnej, ponieważ max_tokens ogranicza jedną odpowiedź, a agent wykonuje ich wiele. Dodaj limit czasu rzeczywistego poza procesem: uruchom zadanie za pomocą systemd timer i ustaw TimeoutStartSec= dla jednostki typu oneshot lub RuntimeMaxSec= dla typu simple, aby zawieszony proces został zabity zgodnie z harmonogramem. Ogranicz również liczbę ponownych prób, ponieważ pętla ponowień nalicza opłaty za każdą próbę.

Czy mogę ustawić limit wydatków dla pojedynczego klucza API Claude?

Udokumentowany limit wydatków dotyczy obszaru roboczego (workspace), a nie klucza, dlatego przydziel agentowi osobny obszar roboczy i tam ogranicz jego miesięczne wydatki. "Nie można ustawić limitów dla domyślnego obszaru roboczego" (Default Workspace). Dodaj powiadomienia o wydatkach, aby próg ostrzegał Cię z wyprzedzeniem. W celu przypisania kosztów, wygeneruj dla każdego zadania osobny klucz, a następnie pogrupuj raport użycia za pomocą group_by[]=api_key_id.