# Hur sätter du en hård utgiftsgräns för en kodningsagents uppgift? > En hård utgiftsgräns måste verkställas före varje modell- eller betalt verktygsanrop av en gateway som äger uppgiftsbudgeten. Reservera kostnaden i värsta fall, stäm av faktisk användning, avvisa anrop som inte ryms och stoppa agenten med en användbar kontrollpunkt. # Hur sätter du en hård utgiftsgräns för en kodningsagents uppgift? En hård uppgiftsbudget är ett admission-control-problem. Innan ett debiterbart modell- eller verktygsanrop börjar måste en betrodd gateway bevisa att högsta tillåtna kostnad ryms i uppgiftens återstående saldo. Varningar och rapporter i efterhand kan inte stoppa ett överskridande som redan skett. Designen ska täcka indatatoken, maximal utdata, omförsök, fallback, underagenter, embeddings, sökningar, sandboxar och alla andra betalda verktyg. ## Separera hårda gränser från mjuka mål Använd tre värden: | Kontroll | Syfte | Beteende | |---|---|---| | Mål | Förväntad kostnad | Varna eller välj en billigare plan | | Mjuk gräns | Eskaleringströskel | Be om godkännande eller sänk kvaliteten | | Hård gräns | Högsta godkända utgift | Avvisa nästa anrop innan det startar | En uppgift kan exempelvis sikta på $0.60, begära godkännande vid $0.90 och stoppa vid $1.00. Den hårda gränsen måste ligga på serversidan, inte bara i agentens prompt. ## Lägg varje debiterbar åtgärd bakom en gateway Ge agenten kortlivade uppgiftsuppgifter som bara kan anropa din gateway. Gatewayen lägger till `task_id`, slår upp budgeten, uppskattar nästa åtgärd och reserverar pengar eller avvisar begäran. Exponera inte en leverantörsnyckel som låter agenten kringgå redovisningen. Tillämpa samma regel på webbsökning, hostade sandboxar, kodkörning och betalda retrieval-tjänster. ## Reservera före anropet och stäm av efteråt För ett modellanrop uppskattar du övre gränsen från kända indatatoken plus konfigurerad maximal utdata. Reservera beloppet atomärt, gör anropet och ersätt sedan reserveringen med faktisk användning. ```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) ``` Atomär reservering hindrar två parallella underagenter från att spendera samma återstående saldo. ## Prissätt med ett versionshanterat tariffkort Lagra priset som användes för varje uppskattning tillsammans med händelsen. Modellpriser och faktureringsregler kan ändras, så äldre användning får inte räknas om med dagens pris. När leverantören returnerar auktoritativ kostnad sparar du både uppskattning och slutavgift. Om bara token returneras använder du tariffversionen som valdes före anropet. Lägg till ett försiktigt påslag för okända verktygsavgifter eller avvisa anrop som inte kan begränsas. ## Gör streaming säker Reservera hela den tillåtna svarskostnaden innan strömmen öppnas. Räkna rapporterad användning när den finns, men anta inte att stängning av klientanslutningen omedelbart stoppar debitering. Avbrott är en optimering, inte verkställighetsgränsen. Sätt en utdatatak per anrop och en wall-clock-timeout. Uppgiftens hårda gräns täcker summan av alla strömmar, omförsök och fallback. ## Inkludera omförsök och underagenter Varje försök debiterar samma överordnade uppgiftsbok. En retry-policy som tyst öppnar en ny budget upphäver gränsen. Använd hierarkiska budgetar vid delegering: | Huvudbok | Gräns | Regel | |---|---:|---| | Överordnad uppgift | $1.00 | Absolut tak | | Implementeringsagent | $0.55 | Får inte överskrida förälderns saldo | | Testanalysagent | $0.25 | Återlämnar oanvänd reservering | | Slutgranskning | $0.20 | Kör bara om pengar återstår | Undergränser är tilldelningar, inte extra pengar. ## Stoppa med en användbar kontrollpunkt När nästa åtgärd inte ryms returnerar du ett typat fel som orkestratorn förstår. Agenten ska inte fortsätta försöka det avvisade anropet. Låt agenten skapa en kostnadsfri kontrollpunkt från befintlig kontext som innehåller: * slutförda ändringar och testresultat; * återstående arbete och den blockerade åtgärden; * aktuellt tillstånd i kodförrådet; * uppskattad extra budget; * en återupptagningstoken eller ett uppgifts-ID. Det gör ett budgetstopp till en kontrollerad överlämning i stället för ett skadat delresultat. ## Använd leverantörskontroller som extra skydd Konto- och gatewaygränser kan minska skadans omfattning men är sällan precisa per uppgift. De kan slå samman flera kodförråd, uppdateras asynkront eller sakna verktygskostnader. Med en multimodellgateway som Atlas Cloud behåller du den auktoritativa uppgiftsboken i orkestreringslagret och registrerar gatewayens användnings-ID:n för avstämning. Då består den hårda gränsen vid modellbyte. ## Testa gränsen som en finansiell kontroll Testa parallella anrop, långa strömmar, leverantörstimeout, saknade användningsfält, omförsök, modellfallback och bokföringsfel. Avvisa som standard när budgettjänsten inte är tillgänglig. Verifiera att bokförd kostnad plus öppna reserveringar aldrig överstiger den hårda gränsen. ## Slutsats En verklig hård utgiftsgräns verkställs före utgiften med atomära reserveringar och en huvudbok för varje debiterbar åtgärd. Om systemet bara varnar efter att användningen kommit är det övervakning, inte ett hårt tak. ## FAQ ### Är max_tokens en hård gräns i pengar? Nej. Det begränsar längden på ett svar, inte uppgiftens totala kostnad, indatatoken, omförsök, modellbyten eller betalda verktyg. En beloppsgräns kräver en budgetbok för varje debiterbar åtgärd. ### Var ska en kodningsagents budget verkställas? Verkställ den i en gateway på serversidan eller ett orkestreringslager som alla modell- och verktygsanrop måste passera. Räknare på klientsidan kan kringgås eller få race conditions vid samtidighet. ### Hur budgeterar jag strömmande svar? Reservera den högsta tillåtna utdatakostnaden innan strömmen öppnas och stäm av mot rapporterad användning när den stängs. Avbryt hos leverantören när det stöds, men förlita dig inte enbart på avbrott. ### Ska omförsök dela den ursprungliga uppgiftsbudgeten? Ja. Omförsök, fallback, underagenter och utvärderingsanrop ska belasta samma uppgiftsbok om inte användaren uttryckligen godkänner en separat budget. ### Vad ska hända när återstående budget är för liten? Avvisa nästa debiterbara åtgärd och låt agenten skapa en kontrollpunkt från befintlig kontext med utfört arbete, olösta delar och den extra budget som behövs. ### Kan leverantörens kontogränser ersätta en gräns per uppgift? Vanligen inte. Kontogränser skyddar hela kontot och kan uppdateras med fördröjning. En gateway per uppgift ger omedelbar isolering, medan kontogränser fungerar som extra skydd.