Una funzione AI gratuita ha portato un piccolo studio a spendere oltre 1.000 dollari al giorno. Easy Fox ha raccontato su Steam che i giocatori della demo di Teach My Little Sister How To Drive sono cresciuti più di venti volte in un mese. Le chiamate AI sono aumentate con loro, fino a richiedere un prestito bancario per tenere il servizio online. Il caso riguarda un videogioco, ma il rischio è identico in un chatbot sul sito, in un assistente per preventivi o in un’automazione WordPress: se ogni utilizzo produce un costo e l’applicazione non sa fermarsi, il successo può trasformarsi in una fattura ingestibile.

Calcola il costo prima di aprire il rubinetto

Il primo numero utile non è il costo di un singolo token. È il costo massimo di una sessione completa. Somma trascrizione, input, output, eventuali chiamate agli strumenti e retry. Poi moltiplica il risultato per le sessioni giornaliere che il servizio può accettare. Una stima prudente deve includere anche i casi lunghi: un utente che ripete la domanda, un modello che restituisce un errore o un workflow agentico che esegue più passaggi del previsto.

Per una PMI conviene fissare tre valori nel codice: costo stimato per richiesta, tetto per utente e budget giornaliero del prodotto. Registra almeno identificativo del progetto, modello, token usati, costo stimato ed esito. Senza questa telemetria vedi la spesa nel pannello del provider, ma non sai quale funzione o cliente l’ha generata. Se usi più fornitori, normalizza i dati nello stesso registro. Il confronto tra modelli deve misurare costo e qualità sul tuo compito, non il prezzo nominale dell’API.

Metti un circuit breaker davanti all’API AI

Il controllo va eseguito prima di ogni chiamata. L’applicazione legge la spesa accumulata per utente e progetto; se supera una soglia, blocca la richiesta costosa e restituisce un percorso sicuro. Può mostrare un modulo tradizionale, mettere il lavoro in coda o chiedere un’approvazione. Un’implementazione minima segue questi passaggi:

  1. separa ogni prodotto in un progetto API dedicato;
  2. imposta alert anticipati e, dove disponibile, un limite di spesa rigido;
  3. applica rate limit per utente, IP e organizzazione;
  4. stima il costo prima della chiamata e aggiorna il contatore dopo la risposta;
  5. apri il circuito quando il budget giornaliero è esaurito e avvisa una persona.

OpenAI distingue gli alert, che notificano senza fermare il traffico, dagli hard spend limit, che possono restituire un errore 429 quando il tetto viene raggiunto. L’enforcement può avere un piccolo ritardo. Per questo il limite del provider è l’ultima rete, mentre il controllo applicativo deve intervenire prima.

Un fallback economico deve superare lo stesso test

Passare in automatico a un modello più economico non risolve il problema se l’output peggiora il servizio. Easy Fox ha segnalato risposte lente, dialoghi poco naturali e comandi eseguiti male durante l’uso più intenso del modello di fallback. Il circuito deve quindi scegliere tra opzioni già verificate: modello più piccolo per richieste semplici, risposta da cache per domande ripetute, elaborazione asincrona o intervento umano per i casi ad alto valore.

Prepara una batteria corta di esempi reali e assegna a ogni fallback una soglia minima di qualità. Misura anche latenza, errori e numero di retry, perché un modello economico che richiede tre tentativi può costare più del modello principale. Per automazioni che inviano email, modificano WordPress o toccano dati clienti, il fallback non deve ampliare i permessi. L’outbox con approvazione prima dell’invio resta una protezione utile quando il budget o la qualità spingono il sistema fuori dal percorso previsto.

Errore da evitare e take finale

L’errore più comune è configurare un avviso mensile e chiamarlo limite. Un alert letto il giorno dopo non protegge da un picco che si consuma in poche ore. Anche i budget cloud non hanno tutti lo stesso comportamento: Google documenta sia budget che inviano avvisi sia spend cap che bloccano servizi idonei. Devi verificare cosa fa il controllo scelto, in quale intervallo aggiorna la spesa e quali richieste restano in corso.

La mia regola è semplice: nessuna funzione AI a consumo entra in produzione senza un percorso degradato che mantenga operativo il servizio. Il budget è un requisito di affidabilità, come timeout e backup. Prima del lancio, simula dieci volte il traffico atteso e prova l’apertura del circuito. Se il tetto scatta, l’utente deve ricevere un’alternativa comprensibile e il team un avviso con prodotto, soglia e consumo. Una crescita improvvisa deve generare una decisione, non un prestito.

Fonti: aggiornamento ufficiale di Easy Fox su Steam; guida OpenAI agli spend limit; documentazione Google Cloud sui budget con spend cap.