Come Databricks gestisce la spesa dei propri agenti di codifica con i budget di Unity AI Gateway

In Databricks, il modo in cui sviluppiamo il software sta cambiando rapidamente a causa dell'adozione massiccia dell'AI nell'ingegneria. Migliaia di nostri ingegneri usano ogni giorno coding agent, alternando Claude Code, Codex, Cursor e altri, spesso usandone diversi contemporaneamente. Questa adozione è fantastica, ma crea un nuovo problema: la spesa per i coding agent è ora una delle voci in più rapida crescita nella R&D, e un singolo ciclo di automazione fuori controllo può consumare un mese di budget in un pomeriggio.

Questo post spiega come abbiamo risolto questo problema internamente, utilizzando gli stessi Unity AI Gateway Budgets che offriamo ai clienti. Poiché ogni coding agent in Databricks, indipendentemente dallo strumento o dal modello, instrada il proprio traffico attraverso il nostro gateway, possiamo applicare un'unica policy di spesa a tutta la flotta senza dover intervenire sulle singole console di amministrazione dei coding agent.

Le lezioni principali apprese dal lancio di questa iniziativa sono state:

1. Separare la protezione dalle spese fuori controllo dai limiti di spesa mensili. Si tratta di compiti diversi che richiedono limiti diversi con cicli di ripristino differenti.
2. La maggior parte dei superamenti dei limiti non rappresenta un problema. Si tratta di normali ingegneri che svolgono il loro normale lavoro, quindi la procedura di sblocco dovrebbe essere self-service, non una coda di approvazione.
3. Le approvazioni dovrebbero essere riservate ai casi davvero eccezionali e dovrebbero essere limitate nel tempo, in modo che un progetto di un mese non diventi un'autorizzazione permanente.
4. Nulla di tutto questo funziona se tutto il traffico degli agent non passa attraverso un unico punto di controllo. Il gateway è ciò che consente di applicare un'unica policy a ogni coding agent.

Vediamo nel dettaglio come siamo arrivati a questo punto.

Nota: le cifre in dollari in questo post sono a scopo illustrativo e non rappresentano i nostri numeri interni reali.

Il problema dei limiti di spesa mensili

All'inizio del nostro percorso di gestione dei costi, abbiamo impostato esattamente un limite: ogni ingegnere aveva un limite di spesa mensile predefinito (diciamo $500) e, una volta raggiunto, presentava una richiesta di aumento. Sulla carta sembra ragionevole, ma all'atto pratico abbiamo scoperto che questa strategia crea attriti ovunque.

Poiché questo limite era anche la nostra unica protezione contro le spese fuori controllo, ogni aumento del limite veniva effettuato con gli stessi incrementi di $500. Gli utenti intensivi dovevano presentare una nuova richiesta ogni volta che raggiungevano il nuovo limite, a volte più volte in un mese, e qualsiasi cifra superiore a $2500 richiedeva una revisione manuale. Peggio ancora, ogni aumento era permanente. Un ingegnere che commetteva un errore costoso o lavorava a un progetto ad alta spesa manteneva un limite elevato a tempo indeterminato, aumentando silenziosamente la quota dell'azienda esposta a errori costosi. Inoltre, non esisteva una procedura di emergenza ("break glass") che consentisse agli ingegneri di sbloccarsi autonomamente per attività critiche e urgenti, come l'uso dell'AI per il debug degli incidenti dei clienti.

Alla nostra scala, tra i 500 e i 1.000 ingegneri raggiungevano il limite ogni mese. Parliamo di centinaia di ticket, centinaia di sessioni di lavoro interrotte e un canale Slack #ai-devtools decisamente scontento.

Prima i principi

Prima di progettare qualsiasi cosa, abbiamo messo per iscritto ciò in cui credevamo riguardo alla spesa per l'AI, e tutto si riduceva a due principi:

1. In genere, consentire agli ingegneri di spendere senza l'ostacolo di approvazioni e passaggi di livello. Sfruttare l'AI è l'obiettivo principale. I guardrail che rallentano tutti per intercettare rari errori rappresentano una perdita netta.
2. Evitare gli sprechi, che si presentano esattamente in due forme.
   • Lo spreco a breve termine è una spesa rapida che potrebbe essere accidentale, come un'automazione che avvia involontariamente un centinaio di sessioni di agent.
   • Lo spreco a lungo termine è una spesa distribuita su giorni o settimane che suggerisce l'uso di una tecnica eccessivamente costosa, come l'esecuzione di sub-agent paralleli basati su modelli di frontiera per lavori che non ne hanno bisogno.

Mettere questo per iscritto ha fatto emergere il conflitto. Per intercettare le spese fuori controllo, un limite deve essere abbastanza basso da essere attivato da poche ore di incidenti. Ma un limite così basso interrompe costantemente il normale utilizzo mensile. Nessun singolo numero può svolgere entrambi i compiti.

Come abbiamo separato la protezione dalle spese fuori controllo dai limiti di spesa mensili

Abbiamo ristrutturato il sistema attorno a un principio semplice: lasciare che gli ingegneri spendano senza impedimenti e intervenire solo per i due tipi di spreco che contano davvero, lo spreco a breve termine e lo spreco a lungo termine.

La soluzione per queste due modalità di guasto si mappa su due budget in Unity AI Gateway:

Un limite giornaliero per intercettare le spese fuori controllo. Questo limite è deliberatamente basso rispetto alla spesa mensile. Quando un ingegnere lo raggiunge, non diamo per scontato che ci sia qualcosa che non va. Riceve una notifica Slack, conferma che la spesa era intenzionale e il limite si alza automaticamente di un ulteriore incremento. Nessuna approvazione, nessun ticket, nessuna attesa. Se la spesa è stata un incidente, la notifica è esattamente l'allarme di cui aveva bisogno. Il budget giornaliero si azzera ogni sera nell'ora di minor utilizzo e si cancella completamente all'inizio di ogni mese.

Un limite mensile per gestire le spese straordinarie. Questo limite è impostato a un livello sufficientemente alto da non essere mai raggiunto dall'ingegnere medio. Superarlo significa che qualcuno sta chiedendo di spendere significativamente più dei propri colleghi, il che va bene, ma dovrebbe essere riconducibile a una specifica priorità aziendale. Questi aumenti passano attraverso l'approvazione del manager anziché di un comitato di approvazione centralizzato e sono strutturati in pochi livelli generali anziché in infiniti piccoli incrementi; inoltre, aspetto fondamentale, sono limitati alla durata del progetto. Al termine del progetto, il limite viene ripristinato.

I due limiti rimangono accoppiati attraverso un rapporto fisso. Nella nostra implementazione, un ingegnere che spende in modo regolare durante il mese non attiverà mai il limite giornaliero, poiché il budget mensile suddiviso per i giorni lavorativi rimane ampiamente al di sotto della soglia giornaliera. Se un manager aumenta il limite mensile di qualcuno per un progetto importante, il relativo limite giornaliero e l'incremento aumentano proporzionalmente, in modo che la protezione dalle spese fuori controllo rimanga efficace senza diventare un fastidio.

Dietro le quinte, il limite effettivo in qualsiasi momento è semplice da definire. La spesa di un utente è regolata da entrambi i budget, quindi sarà limitata al valore minimo tra due limiti: il consumo effettuato finora nel mese in corso più un incremento di sicurezza, e il massimo mensile consentito. Quando un utente viene bloccato, questa formula ci dice anche esattamente in quale situazione ci troviamo. Se ha raggiunto il limite di sicurezza, l'utilizzo può essere ripreso dopo una conferma self-service. Se ha raggiunto il massimo mensile, dovrà parlarne con il proprio manager.

Il flusso di lavoro di conferma self-service

Il limite giornaliero funziona solo se lo sblocco è davvero privo di attriti, quindi abbiamo concentrato la maggior parte dei nostri sforzi di progettazione su questo percorso. Ecco cosa sperimenta concretamente un ingegnere.

Una volta che un utente supera circa il 90% del proprio limite giornaliero, diventa idoneo per un aumento prima ancora di essere bloccato. Arriva una notifica Slack con il contesto (quanto ha speso oggi, qual è il margine rimanente) e un singolo pulsante per confermare che la spesa è intenzionale. Facendo clic su di esso, il limite giornaliero viene aumentato immediatamente di un incremento. Lo stesso aumento autonomo è disponibile dal nostro portale di budget interno e dalla CLI, che stampa la quota giornaliera e mensile rimanente insieme ai link per aumentare l'una o l'altra.

Non c'è un limite al numero di conferme autonome al giorno. Un ingegnere che gestisce un carico di lavoro davvero pesante potrebbe confermare due o tre incrementi in un solo giorno, e va bene così. Ogni conferma è un segnale umano deliberato che dice "sì, sono io e voglio farlo davvero". Un cron job non presidiato non può fare clic su un pulsante di Slack. La dimensione dell'incremento è importante in questo caso: se è troppo piccola, le notifiche diventano rumore di fondo che abitua le persone a fare clic senza pensare; se è troppo grande, la protezione smette di proteggere. Abbiamo dimensionato la nostra in modo che un ingegnere che spende in modo regolare rispetto al proprio budget mensile non veda alcuna notifica.

Livelli di override anziché limiti arbitrari

Invece di lasciare che i limiti fluttuino verso valori arbitrari per singolo utente, entrambi i budget si muovono attraverso un piccolo insieme di livelli fissi, implementati come appartenenza a gruppi nel gateway. Tutti iniziano dal livello base e ogni livello successivo aumenta la soglia di uno step fisso. Questo mantiene il sistema leggibile: un elenco di gruppi risponde a chi si trova al di sopra del valore predefinito e di quanto.

I due budget si muovono attraverso i rispettivi livelli in modo diverso, in linea con i loro differenti compiti.

I livelli giornalieri cambiano automaticamente. Tutti iniziano il mese dal livello base. Ogni auto-approvazione fa avanzare l'utente di un livello, e un job pianificato promuove gli utenti in modo proattivo quando la loro spesa si avvicina al limite massimo attuale, al massimo una volta al giorno, così l'utilizzo normale non viene mai interrotto. Alla fine del mese, un altro job ripristina tutti al livello base. L'incremento del mese scorso non si trasferisce come margine per questo mese.

I livelli mensili cambiano in modo mirato. Ce ne sono solo alcuni, circa 2x, 5x, fino a un livello praticamente illimitato, e ogni promozione richiede l'approvazione del manager o di un livello superiore. Le promozioni sono limitate al progetto che le giustifica, in genere per uno, tre o sei mesi, per poi essere ripristinate. Questi passaggi più ampi impongono un confronto reale sulla spesa, anziché piccoli incrementi che nessuno controlla. L'aumento del livello mensile adegua proporzionalmente anche l'incremento giornaliero, mantenendo calibrato il sistema di controllo dei costi.

Applicazione tramite il gateway

Il motivo per cui questo funziona quasi senza infrastrutture personalizzate è che Unity AI Gateway vede già tutto. Ogni richiesta da parte di ciascun coding agent, che si tratti di Claude, GPT, Gemini o modelli open source, viene attribuita a un'identità utente e misurata in un unico posto. I budget configurati per il gateway si applicano a tutti gli strumenti utilizzati da un ingegnere e la spesa non può superare nessuno dei budget applicabili. Quest'ultima proprietà implementa automaticamente il comportamento del "minimo dei due limiti": definiamo entrambi i budget ed entrambi sono efficaci in qualsiasi momento.

I livelli giornalieri e mensili vengono implementati assegnando le eccezioni alle soglie per utente del budget a gruppi diversi. E la promozione di livello si ottiene rendendo l'utente membro del gruppo del livello superiore, tramite automazione giornaliera, auto-approvazioni e approvazioni dei manager.

Poiché il gateway inserisce tutti questi dati di utilizzo in Unity Catalog, otteniamo automaticamente anche la parte di osservabilità. I manager vedono la spesa a livello di team nelle stesse tabelle Lakehouse in cui abbiamo creato il nostro benchmark interno per i coding agent, e il dipartimento finanziario riceve un'unica fattura invece di cinque.

Cosa è cambiato

La coda di approvazione basata sulle interruzioni non esiste più. Con il nuovo modello, prevediamo che solo una minima parte dei nostri utenti più attivi raggiungerà il limite giornaliero in un determinato mese, e ciascuno di questi casi si risolverà con un solo clic di approvazione. Gli aumenti del limite mensile sono passati dall'essere un'incombenza ricorrente per ogni ingegnere a una decisione rara, limitata al progetto, che un manager prende una sola volta.

Gli ingegneri hanno smesso di razionare le risorse. L'obiettivo di queste barriere protettive non è mai stato quello di ridurre l'uso dell'AI. Era eliminare il timore di costi illimitati, in modo da poter continuare a promuovere l'adozione. Ora la spesa è qualcosa che modelliamo con i dati, anziché qualcosa che limitiamo per prudenza.

Cosa ci aspetta

Continuiamo a ottimizzare i numeri man mano che i modelli di utilizzo si evolvono, e i pattern che si sono dimostrati efficaci internamente stanno influenzando il prodotto Budgets stesso: cicli di budget giornalieri nativi, eccezioni temporanee che scadono con il ciclo di budget e un modello di autorizzazioni che consente agli utenti finali di aumentare autonomamente la propria soglia giornaliera direttamente tramite l'API del budget, con maggiore flessibilità rispetto ai gruppi di eccezioni predefiniti.

Stiamo anche lavorando per rendere meno necessario il percorso più costoso attraverso un routing dei modelli più intelligente, in modo che le attività quotidiane vengano indirizzate su modelli efficienti e i modelli di frontiera siano riservati al lavoro che ne ha effettivamente bisogno. Maggiori dettagli in un prossimo post.

Se la tua organizzazione sta scalando i coding agent e ogni strumento ha la propria console di budget, la soluzione è la stessa che abbiamo adottato noi. Il supporto per i coding agent in Unity AI Gateway è disponibile oggi per tutti i clienti Databricks. Consulta la documentazione per iniziare.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale