# Come si imposta un limite di spesa rigido per un'attività di un agente di coding? > Un limite rigido deve essere applicato prima di ogni chiamata a un modello o strumento a pagamento da un gateway che controlla il budget dell'attività. Prenota il costo massimo, riconcilia l'uso reale, rifiuta le chiamate che non rientrano nel saldo e arresta l'agente con un checkpoint utile. # Come si imposta un limite di spesa rigido per un'attività di un agente di coding? Un budget rigido è controllo di ammissione. Prima di ogni chiamata fatturabile, un gateway affidabile deve verificare che il costo massimo consentito rientri nel saldo. Gli avvisi successivi non fermano un superamento già avvenuto. Includi input, output massimo, tentativi, fallback, sottoagenti, embedding, ricerca, sandbox e ogni strumento a pagamento. ## Separare limite rigido e obiettivo flessibile Usa tre valori: | Controllo | Scopo | Comportamento | |---|---|---| | Obiettivo | Costo previsto | Avvisare o scegliere un piano meno costoso | | Limite flessibile | Soglia di escalation | Chiedere approvazione o ridurre la qualità | | Limite rigido | Spesa massima autorizzata | Rifiutare prima della chiamata successiva | Esempio: obiettivo $0.60, approvazione a $0.90, arresto a $1.00. Il limite rigido deve stare sul server, non solo nel prompt. ## Far passare ogni azione a pagamento da un gateway Fornisci all'agente credenziali brevi che chiamino solo il tuo gateway. Il gateway aggiunge `task_id`, controlla il budget, stima l'azione e prenota o rifiuta. Non esporre una chiave provider che aggiri la contabilità. Applica la stessa regola a ricerca, sandbox, esecuzione e recupero a pagamento. ## Prenotare prima e riconciliare dopo Stima il massimo da token di input noti e output massimo. Prenota in modo atomico, esegui la chiamata e sostituisci la prenotazione con l'uso reale. ```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) ``` La prenotazione atomica impedisce a due sottoagenti di spendere lo stesso saldo. ## Usare un tariffario versionato Conserva il prezzo usato con ogni stima. Le tariffe cambiano e il passato non va ricalcolato con il prezzo odierno. Se il provider restituisce il costo finale, conserva stima e importo. Se restituisce solo token, usa il tariffario scelto prima della chiamata. Aggiungi margine per costi incerti o rifiuta ciò che non può essere limitato. ## Rendere sicuro lo streaming Prenota l'intero costo di output consentito prima di aprire lo stream. Riconcilia l'uso, ma non presumere che chiudere il client interrompa subito la fatturazione. L'annullamento è un'ottimizzazione, non il confine di controllo. Imposta limite di output e timeout per chiamata. Il tetto dell'attività include tutti gli stream, tentativi e fallback. ## Includere tentativi e sottoagenti Ogni tentativo addebita lo stesso registro padre. Un nuovo budget per tentativo annulla il limite. Usa budget gerarchici: | Registro | Limite | Regola | |---|---:|---| | Attività padre | $1.00 | Tetto assoluto | | Sottoagente di implementazione | $0.55 | Non supera il saldo padre | | Analisi test | $0.25 | Restituisce la prenotazione inutilizzata | | Revisione finale | $0.20 | Si esegue solo se resta saldo | I limiti figli sono allocazioni, non denaro aggiuntivo. ## Fermarsi con un checkpoint utile Se l'azione non rientra, restituisci un errore tipizzato e non ripetere la chiamata rifiutata. Genera dal contesto presente un checkpoint con: * modifiche concluse e test; * lavoro restante e azione bloccata; * stato attuale del repository; * budget aggiuntivo stimato; * token di ripresa o ID attività. Così l'arresto diventa un passaggio controllato. ## Usare i controlli provider come riserva I limiti account riducono il danno ma raramente sono precisi per attività. Possono aggregare repository, aggiornarsi tardi o omettere strumenti. Anche con un gateway multimodello come Atlas Cloud, mantieni il registro autorevole nell'orchestrazione e salva gli ID di utilizzo per la riconciliazione. Il limite resta valido quando cambia il modello. ## Testare il limite come controllo finanziario Prova concorrenza, stream lunghi, timeout, uso mancante, tentativi, fallback e guasti del registro. Rifiuta per impostazione predefinita se il servizio budget non è disponibile. Costi confermati più prenotazioni non devono mai superare il tetto. ## Conclusione Un vero limite rigido si applica prima della spesa con prenotazioni atomiche e un registro per ogni azione fatturabile. Se il sistema avvisa solo dopo, è monitoraggio, non un limite rigido. ## FAQ ### max_tokens è un limite monetario rigido? No. Limita una singola risposta, non il costo totale, i token di input, i tentativi, i cambi di modello o gli strumenti. Un limite monetario richiede un registro per ogni azione fatturabile. ### Dove va applicato il budget dell'agente? In un gateway lato server o in un livello di orchestrazione attraverso cui passano tutte le chiamate a modelli e strumenti a pagamento. I contatori client possono essere aggirati o incorrere in race condition. ### Come si gestisce il budget per lo streaming? Prenota il costo massimo consentito prima di aprire lo stream e riconcilia l'uso riportato alla chiusura. Annulla presso il provider se possibile, ma non affidarti solo all'annullamento. ### I tentativi condividono il budget originale? Sì. Tentativi, fallback, sottoagenti e valutazioni addebitano lo stesso registro, salvo approvazione esplicita di un budget separato. ### Cosa accade quando il saldo non basta? Rifiuta la chiamata fatturabile successiva e chiedi un checkpoint dal contesto esistente con lavoro completato, elementi aperti e budget aggiuntivo necessario. ### I limiti dell'account provider possono sostituire quello per attività? Di solito no. Proteggono l'intero account e possono aggiornarsi in ritardo. Un gateway per attività isola subito; il limite account resta una protezione aggiuntiva.