# Jak ustawić twardy limit wydatków dla zadania agenta programistycznego? > Twardy limit wydatków musi być egzekwowany przed każdym wywołaniem modelu lub płatnego narzędzia przez bramę zarządzającą budżetem zadania. Rezerwuj koszt najgorszego przypadku, rozliczaj rzeczywiste zużycie, odrzucaj wywołania niemieszczące się w budżecie i kończ agentem z użytecznym punktem kontrolnym. # Jak ustawić twardy limit wydatków dla zadania agenta programistycznego? Twardy budżet zadania jest problemem admission control. Przed każdym płatnym wywołaniem modelu lub narzędzia zaufana brama musi potwierdzić, że maksymalny dozwolony koszt mieści się w pozostałym saldzie. Alerty i raporty po fakcie nie zatrzymają już powstałego przekroczenia. Projekt musi obejmować tokeny wejściowe, maksymalne wyjście, ponowienia, fallbacki, subagentów, embeddings, wyszukiwanie, sandboxy i każde inne płatne narzędzie. ## Oddziel twarde limity od miękkich celów Używaj trzech wartości: | Kontrola | Cel | Zachowanie | |---|---|---| | Cel | Oczekiwany koszt | Ostrzeżenie lub tańszy plan | | Limit miękki | Próg eskalacji | Prośba o zgodę lub obniżenie jakości | | Limit twardy | Maksymalny autoryzowany wydatek | Odrzucenie następnego wywołania przed startem | Zadanie może celować w $0.60, prosić o zgodę przy $0.90 i zatrzymać się przy $1.00. Twardy limit musi być po stronie serwera, nie tylko w prompcie. ## Umieść każdą płatną czynność za jedną bramą Wydaj agentowi krótkotrwałe poświadczenia zadania, które wywołują tylko twoją bramę. Brama dodaje `task_id`, odczytuje budżet, szacuje następną czynność i rezerwuje środki albo ją odrzuca. Nie ujawniaj klucza dostawcy pozwalającego ominąć rozliczenia. Tę samą regułę stosuj do wyszukiwania, hostowanych sandboxów, wykonywania kodu i płatnego retrieval. ## Rezerwuj przed wywołaniem i rozliczaj po nim Dla wywołania modelu oszacuj górną granicę na podstawie znanych tokenów wejściowych i maksymalnego wyjścia. Atomowo zarezerwuj kwotę, wykonaj żądanie i zastąp rezerwację rzeczywistym użyciem. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` Atomowa rezerwacja zapobiega wydaniu tego samego salda przez dwóch równoległych subagentów. ## Wyceniaj według wersjonowanej tabeli stawek Zapisuj cenę używaną do każdego szacunku. Ceny modeli i reguły rozliczeń się zmieniają, więc nie przeliczaj historycznego użycia według dzisiejszych stawek. Gdy dostawca zwraca autorytatywny koszt, zachowaj zarówno szacunek, jak i opłatę końcową. Przy samych tokenach użyj wersji tabeli wybranej przed wywołaniem. Dodaj konserwatywny narzut dla nieznanych kosztów albo odrzucaj nieograniczone wywołania. ## Zabezpiecz streaming Przed otwarciem strumienia zarezerwuj pełny dozwolony koszt odpowiedzi. Licz raportowane użycie, lecz nie zakładaj, że zamknięcie klienta natychmiast zatrzymuje naliczanie. Anulowanie jest optymalizacją, a nie granicą egzekwowania. Ustaw limit wyjścia na wywołanie i timeout zegarowy. Twardy limit zadania obejmuje łącznie wszystkie strumienie, ponowienia i fallbacki. ## Uwzględnij ponowienia i subagentów Każda próba obciąża tę samą nadrzędną księgę. Retry otwierający po cichu nowy budżet niweczy limit. Przy delegowaniu użyj budżetów hierarchicznych: | Księga | Limit | Reguła | |---|---:|---| | Zadanie nadrzędne | $1.00 | Absolutny pułap | | Subagent implementacji | $0.55 | Nie przekracza pozostałego salda rodzica | | Subagent analizy testów | $0.25 | Zwraca niewykorzystaną rezerwację | | Przegląd końcowy | $0.20 | Działa tylko, gdy zostały środki | Limity podrzędne są przydziałami, a nie dodatkowymi pieniędzmi. ## Zatrzymuj z użytecznym punktem kontrolnym Gdy następna czynność nie mieści się w budżecie, zwróć typowany błąd zrozumiały dla orkiestratora. Agent nie powinien ponawiać odrzuconego wywołania. Poproś go o bezkosztowy punkt kontrolny z dostępnego kontekstu, zawierający: * wykonane zmiany i wyniki testów; * pozostałą pracę i zablokowaną czynność; * bieżący stan repozytorium; * szacowany dodatkowy budżet; * token wznowienia lub ID zadania. To zmienia zatrzymanie budżetowe w kontrolowane przekazanie zamiast uszkodzonej częściowej pracy. ## Używaj kontroli dostawcy jako zabezpieczenia Limity konta zmniejszają skalę szkody, ale rzadko są precyzyjne per zadanie. Mogą agregować wiele repozytoriów, aktualizować się asynchronicznie lub pomijać koszty narzędzi. Przy bramie wielomodelowej, takiej jak Atlas Cloud, utrzymuj autorytatywną księgę zadania w orkiestracji i zapisuj identyfikatory użycia do uzgodnienia. Granica zostaje zachowana przy zmianie modelu. ## Testuj limit jak kontrolę finansową Testuj równoległe wywołania, długie strumienie, timeouty dostawcy, brak pól użycia, ponowienia, fallbacki i awarie księgi. Domyślnie odmawiaj, gdy usługa budżetu jest niedostępna. Potwierdź, że zaksięgowane koszty i otwarte rezerwacje nigdy nie przekraczają limitu. ## Podsumowanie Prawdziwy twardy limit jest egzekwowany przed wydatkiem przez atomowe rezerwacje i jedną księgę wszystkich płatnych czynności. System ostrzegający dopiero po użyciu zapewnia monitoring, nie twardy limit. ## FAQ ### Czy max_tokens jest twardym limitem kwotowym? Nie. Ogranicza długość jednej odpowiedzi, a nie całkowity koszt zadania, tokeny wejściowe, ponowienia, zmiany modeli lub płatne narzędzia. Limit kwotowy wymaga księgi budżetowej dla każdej płatnej czynności. ### Gdzie egzekwować budżet agenta programistycznego? W bramie po stronie serwera lub warstwie orkiestracji, przez którą przechodzą wszystkie wywołania modeli i płatnych narzędzi. Liczniki po stronie klienta można ominąć i są podatne na wyścigi. ### Jak budżetować odpowiedzi strumieniowe? Przed otwarciem strumienia zarezerwuj maksymalny dozwolony koszt wyjścia, a po zamknięciu rozlicz raportowane użycie. Anuluj u dostawcy, jeśli to możliwe, ale nie polegaj wyłącznie na anulowaniu. ### Czy ponowienia powinny korzystać z pierwotnego budżetu zadania? Tak. Ponowienia, modele zapasowe, subagenci i wywołania ewaluacyjne powinny obciążać tę samą księgę, chyba że użytkownik zatwierdzi osobny budżet. ### Co zrobić, gdy pozostały budżet jest zbyt mały? Odrzuć następną płatną czynność i poproś agenta o utworzenie punktu kontrolnego z dostępnego kontekstu: wykonane prace, otwarte zadania i kwota potrzebna do kontynuacji. ### Czy limity konta dostawcy mogą zastąpić limit na zadanie? Zwykle nie. Chronią całe konto i mogą aktualizować się z opóźnieniem. Brama per zadanie daje natychmiastową izolację, a limity konta pozostają dodatkowym zabezpieczeniem.