Jak kontrolować koszty agenta AI na serwerze 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 pojedynczego żądania, obejmujący tekst myślenia oraz odpowiedź. Claude nigdy nie generuje treści poza tym limitem, a model nie widzi tej wartości. 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 ono pojedynczą odpowiedź, a nie całe zadanie. Dziesięć wywołań narzędzi przy limicie 4000 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 myślenie, 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, podczas gdy 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 to 20 000 tokenów; mniejsza wartość zwraca błąd 400. Budżet zbyt mały dla danego zadania powoduje zachowanie przypominające odmowę, więc 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ń znajdują się w fazie beta dla Claude Fable 5, Claude Opus 4.8 oraz Claude Opus 4.7. Modele Claude Sonnet 5 oraz Claude Haiku 4.5 są oznaczone jako Not supported, a budżety zadań nie mają zastosowania do Claude Code, więc sesja Claude Code odłączona w tmux zależy od utrzymania porządku w 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 zapytań 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 dodać powiadomienia o wydatkach, aby próg ostrzegał przed osiągnięciem limitu.

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

Wybór modelu jest decyzją podejmowaną dla każdego zadania z osobna. Według stanu na lipiec 2026 roku, ceny za milion tokenów (wejściowych, a następnie wyjściowych) kształtują się następująco: Claude Fable 5 kosztuje 10 USD i 50 USD, Claude Opus 4.8 oraz Opus 4.7 kosztują 5 USD i 25 USD, Claude Sonnet 5 kosztuje 3 USD i 15 USD, a Claude Haiku 4.5 kosztuje 1 USD i 5 USD. Model Sonnet 5 jest obecnie wyceniony poniżej ceny katalogowej, ponieważ „cena promocyjna 2 USD / 10 USD za milion tokenów wejściowych/wyjściowych obowiązuje do 31 sierpnia 2026 roku”. Zadanie polegające wyłącznie na klasyfikacji linii logów nie wymaga modelu Opus. Nie istnieje również żaden darmowy limit, który mógłby pokryć intensywny harmonogram pracy, ponieważ Claude API nie posiada darmowego planu poza niewielkim kredytem przyznawanym przy rejestracji.

Drugim czynnikiem jest nakład pracy (effort). output_config.effort akceptuje low, medium, high, xhigh oraz max, a wartością domyślną jest high, więc jawne ustawienie high daje ten sam efekt, co jego pominięcie. Niższy nakład pracy redukuje coś więcej niż tylko długość procesu wnioskowania: dokumentacja wskazuje, że sprawia on, iż Claude wykonuje mniej wywołań narzędzi i łączy operacje w jedną całość. W przypadku agenta jest to większa oszczędność, ponieważ uniknięte wywołanie narzędzia to całe żądanie, które w ogóle nie zostaje wysłane.

Pułapką jest to, że nakład pracy koliduje z pamięcią podręczną (cache). Zmiana tej wartości między żądaniami unieważnia prompt caching. W udokumentowanym przykładzie żądanie 2 zgłosiło cache_read_input_tokens: 3546; żądanie 3, przy zmianie nakładu pracy z wysokiego na średni, zgłosiło cache_creation_input_tokens z 3546 oraz cache_read_input_tokens z 0. Należy zatem różnicować nakład pracy w zależności od obciążeń, ale nigdy wewnątrz jednej konwersacji korzystającej z pamięci podręcznej. Aby sterować głębokością analizy bez naruszania pamięci podręcznej, należy robić to w samym prompcie: linia typu „Odpowiedz bezpośrednio, bez dłuższego zastanawiania się” dodana do najnowszej wiadomości użytkownika pozostawia wcześniejsze punkty przerwania nienaruszone.

Tokeny myślowe (thinking tokens) są rozliczane według stawek za tokeny wyjściowe 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 składa się na 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. Odczyt z pamięci podręcznej kosztuje 0,1 ceny podstawowej, zatem „buforowanie zwraca się już po jednym odczycie dla czasu trwania 5 minut (zapis 1,25x) lub po dwóch odczytach dla czasu trwania 1 godziny (zapis 2x)”.

Jedno zdanie wyjaśnia, dlaczego jest to rozwiązanie odpowiednie 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 względem pięciominutowego bufora utrzymuje prefiks w stanie aktywnym przez cały dzień przy zaledwie jednym zapisie.

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 umieszczenie znacznika czasu lub identyfikatora uruchomienia w systemowym monicie (system prompt): każde żądanie zawiera wtedy inny prefiks, zapisuje nowy wpis przy koszcie 1,25x i nie odczytuje niczego z powrotem. Sygnałem ostrzegawczym jest wartość usage.cache_read_input_tokens wynosząca 0 przy identycznie wyglądających wywołaniach. Przenieś zmienny tekst 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ą 1024 tokeny dla Claude Opus 4.8 i Claude Sonnet 5 oraz 4096 dla Claude Haiku 4.5, więc przeniesienie zadania z modelu Sonnet na Haiku może spowodować ciche wyłączenie buforowania.

Konwersacja wykraczająca poza okno podglądu (lookback). „Okno podglądu obejmuje 20 bloków”. System sprawdza maksymalnie 20 pozycji na punkt przerwania, a następnie przerywa działanie. W udokumentowanym przykładzie tura zawierająca 35 bloków z punktem przerwania na bloku 35 sprawdza bloki od 35 do 16, a wpis z poprzedniej tury na bloku 15 znajduje się poza oknem, więc nie następuje trafienie. Agent dołączający kilka bloków użycia narzędzi i wyników narzędzi na turę przekracza limit 20 bloków w ciągu dwóch lub trzech tur. Dostępne są cztery punkty przerwania na żądanie, więc jeden z nich należy przeznaczyć na najnowsze 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.

Rejestrowanie pól użycia każdej odpowiedzi we własnym magazynie danych

Nie można przypisać kosztów, których nie zarejestrowano. 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,
}

Należy dopisywać jeden wiersz na 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 zużywa zasoby. Należy monitorować cache_read: kolumna zer jest najczęstszym błędem w raportowaniu kosztów w przypadku agentów hostowanych samodzielnie.

Jedno pole jest podatne na błędną interpretację. 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 danych pochodzi z pamięci podręcznej.

Należy zliczać tokeny przed wysłaniem żądania. Zliczanie tokenów jest bezpłatne, a jego limity są niezależne od tworzenia wiadomości, dlatego należy użyć count_tokens, aby odrzucić zbyt duży załącznik zamiast płacić za wykrycie tego faktu. Wynik jest szacunkowy, dlatego należy przeprowadzać pomiary dla każdego modelu z osobna i nigdy nie używać liczby tokenów uzyskanej z tokenizera innego dostawcy. Modele Claude Opus 4.7 i nowsze, Claude Fable 5 oraz Claude Sonnet 5 korzystają z 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, korzystają z poprzedniej wersji.

Autorytatywne dane o użyciu można uzyskać przez Admin API w https://api.anthropic.com/v1/organizations/usage_report/messages, a o kosztach 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 anthropic-version: 2023-06-01 i akceptują parametry bucket_width=1d, group_by[]=model oraz api_key_ids[]=. Istnieje jedno ograniczenie: „Admin API jest niedostępne dla kont indywidualnych”.

Ostatni parametr to tani sposób na przypisywanie kosztów: należy nadać każdemu zadaniu własny klucz API, przefiltrować wyniki za pomocą api_key_ids[] i podzielić raport według klucza za pomocą group_by[]=api_key_id. Filtr obsługuje wiele wartości, natomiast wymiar grupowania jest pojedynczy. Klucze należy przechowywać w zmiennych środowiskowych, a nie w kodzie, w sposób opisany w pierwszej aplikacji Claude API na VPS.

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

Ograniczona liczba iteracji jest tutaj niezbędna. Pętla należy do Ciebie, więc licznik również musi być Twoim zadaniem:

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 pracy za Ciebie: max_tokens ogranicza pojedynczą odpowiedź, a model jest jedynie informowany o budżecie zadania. Hostowany produkt zatrzymałby działanie w tym miejscu, tak jak limit wywołań narzędzi w pojedynczej turze w Claude przerywa sesję, która wykonała ich zbyt wiele, ale pętla napisana samodzielnie nie posiada takiego zabezpieczenia, dopóki go nie dodasz.

Zastosuj drugi hamulec poza procesem. Uruchamiaj zadanie za pomocą systemd timer zamiast stałego procesu i ustaw RuntimeMaxSec= w jego jednostce serwisowej. Dzięki RuntimeMaxSec=600 zawieszony proces zostanie zakończony po dziesięciu minutach, zamiast działać w nieskończoność, dopóki nie zauważysz problemu. Uruchamianie programu jako usługa i timer systemd opisuje tworzenie plików jednostek. Sprawdź wyniki działania za pomocą journalctl -u triage-agent.service --since "1 hour ago".

Ogranicz również liczbę ponownych prób, ponieważ procedura obsługi, która ponawia działanie w nieskończoność, nalicza koszty za każdą próbę. Błąd 429 lub 500 uzasadnia kilka prób z mechanizmem backoff. Błąd 400 nie uzasadnia żadnej, ponieważ to samo żądanie zawsze zakończy się w ten sam sposób.

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

Nikt nie określi kosztu działania agenta pracującego w trybie ciągłym, ponieważ koszt ten stanowi iloczyn 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 zuż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 działająca 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 opisuje kwestie subskrypcji. Każda cena i limit zostały zweryfikowane z dokumentacją Anthropic w lipcu 2026 roku, dlatego przed zaplanowaniem budżetu należy ponownie sprawdzić stronę z cennikiem.

FAQ

Ile kosztuje utrzymanie stale działającego agenta AI na serwerze VPS?

Istnieją dwa rodzaje opłat, z których tylko jedna jest przewidywalna. Serwer ma stałą miesięczną cenę. API modelu jest rozliczane za token, więc koszt stanowi iloczyn zużycia w jednym uruchomieniu oraz częstotliwości wykonywania zadań. Anthropic nie podaje szacunkowych kosztów dla stale działającego, samodzielnie hostowanego agenta, dlatego każdą podaną kwotę należy traktować jako przypuszczenie. Zarejestruj usage z jednego rzeczywistego uruchomienia i pomnóż przez liczbę zaplanowanych zadań.

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

Parametr max_tokens jest wymuszany i niewidoczny dla modelu. Ogranicza on wynik pojedynczego żądania, wliczając w to proces myślowy, a jego przekroczenie skutkuje błędem stop_reason: "max_tokens". Budżet zadania działa odwrotnie: model otrzymuje informację o limicie i dostosowuje do niego pętlę agenta, jednak „budżety zadań są jedynie miękką wskazówką, a nie twardym limitem”, a wymuszane ograniczenie nadal stanowi max_tokens.

Dlaczego wartość cache_read_input_tokens dla mojego agenta zawsze wynosi zero?

Przyczyną jest zmiana prefiksu między wywołaniami lub zbyt mała jego długość, aby można było użyć pamięci podręcznej. Zazwyczaj wynika to z umieszczenia znacznika czasu lub identyfikatora uruchomienia w system prompt: pamięć podręczna jest indeksowana na podstawie prefiksu, więc zmiana dowolnego bajtu unieważnia wszystko, co po nim następuje. Zmiana definicji narzędzi lub wartości effort powoduje ten sam efekt. W przeciwnym razie przyczyną jest rozmiar, ponieważ zbyt krótkie prompty nie są buforowane, a system nie zwraca w takim przypadku błędu.

Jak zatrzymać agenta AI przed zapętleniem?

Zliczaj iteracje w kodzie pętli i zatrzymuj działanie po osiągnięciu ustalonego maksimum, ponieważ max_tokens ogranicza tylko jedną odpowiedź, a agent wykonuje ich wiele. Dodaj limit czasu rzeczywistego poza procesem: uruchamiaj zadanie za pomocą systemd timer z ustawionym parametrem RuntimeMaxSec=, aby zawieszony proces został przerwany zgodnie z harmonogramem. Ogranicz również liczbę ponownych prób, ponieważ pętla ponowień generuje koszty przy każdej próbie.

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

Dokumentowany limit wydatków dotyczy obszaru roboczego (workspace), a nie pojedynczego klucza, dlatego należy przypisać agentowi osobny obszar roboczy i tam ustawić miesięczny limit. „Nie można ustawić limitów dla Default Workspace”. Skonfiguruj powiadomienia o wydatkach, aby otrzymywać alerty po przekroczeniu progu. W celu przypisania kosztów, wygeneruj osobny klucz dla każdego zadania, a następnie pogrupuj raport użycia za pomocą group_by[]=api_key_id.