Il costo di esecuzione di un AI Agent: valutare l'intero ciclo, non solo i token

Il costo di esecuzione di un AI agent raramente è dominato dal modello. Negli agent che progettiamo e costruiamo, le voci principali sono le chiamate agli strumenti che circondano il modello (ricerca, scraping, enrichment dei dati, verifica email), i retry che rifatturano quegli strumenti, e l'hosting e il tracing necessari prima di potersi fidare che il sistema funzioni senza supervisione. Se volete un numero che possa resistere davanti a un board, valutate l'intero ciclo per task completato e trattate il prezzo per milione di token come una delle sei variabili in gioco.

Cosa compra davvero un singolo task dell'agent

Prendiamo un esempio semplice: un agent che qualifica un lead in ingresso. Un'esecuzione potrebbe recuperare il sito del prospect tramite un'API di scraping, eseguire due o tre ricerche web, estrarre dati aziendali da un provider di enrichment, verificare un indirizzo email, e fare tre o quattro chiamate al modello per pianificare, estrarre, scrivere e verificare. Ognuna di queste è un evento tariffato. Il modello è probabilmente l'unico che avete effettivamente prezzato.

Il bill of materials completo per un singolo task di solito è così:

• Token del modello, divisi in input, output e input in cache, su ogni chiamata del ciclo
• Chiamate a strumenti e API, ciascuna con il proprio prezzo a richiesta o una licenza seat con una quota
• Retry e re-esecuzioni causati da timeout degli strumenti, output malformato del modello o rate limit
• Infrastruttura: coda, worker, database, vector store se lo usate
• Observability: span di tracing e retention dei log, spesso tariffati per evento
• Tempo di revisione umana per la quota di task che vengono segnalati

Il problema con gli agent, a differenza di una pipeline fissa, è che è l'agent a decidere quante chiamate agli strumenti fare. Il vostro costo per task è una distribuzione, non un numero. Due task che dall'esterno sembrano identici possono differire di diverse volte in termini di costo perché uno ha effettuato cinque ricerche e l'altro una sola.

Perché le chiamate agli strumenti crescono più dei token

I prezzi dei token sono scesi costantemente e potete ridurli ulteriormente con prompt caching e batch processing. Anthropic documenta entrambi nella sua pagina dei prezzi. I prezzi a richiesta per le API di ricerca, scraping ed enrichment non si muovono in quel modo. Sono tariffate per chiamata, pensate per il consumo da parte di macchine, e l'agent le chiama ripetutamente dove un essere umano avrebbe scorso una sola pagina.

Il mercato si sta muovendo nella stessa direzione. Brave ha recentemente annunciato che la sua Search API accetta pagamenti agentici tramite il protocollo x402, un caso di fornitore di strumenti progettato esplicitamente per agent che pagano per chiamata senza un essere umano nel ciclo. Aspettatevi che altri fornitori dei vostri agent adottino questo tipo di fatturazione. È comodo per l'agent e pericoloso per il budget, a meno che non lo limitiate.

Il caching aiuta solo sul lato modello. Il modello legge il vostro system prompt una volta e la cache assorbe le ripetizioni. Una chiamata API di terze parti non viene mai memorizzata in cache a meno che non costruiate voi stessi quella cache, indicizzata per dominio, query o record, con una scadenza sensata.

Cosa abbiamo imparato dal nostro motore di outreach

Gestiamo internamente uno strumento di outreach che esegue lo scraping del sito di ogni prospect e scrive una email personalizzata per ogni azienda. La prima vera domanda di design è stata il costo marginale per prospect, perché sia il prezzo per pagina dello scraping sia il prezzo per chiamata del modello crescevano con la lista. Abbiamo finito per auto-ospitare Firecrawl ed eseguire un modello locale, così il costo marginale per prospect è in gran parte compute che già pagavamo. Il secondo riscontro è stato meno ovvio: una singola chiamata che estrae i fatti e scrive l'email in un solo passaggio ha superato una catena multi-step sia in costo sia in qualità. Meno chiamate significavano meno punti di guasto, il che significava meno retry, che era esattamente dove la catena stava silenziosamente spendendo. Abbiamo descritto il pattern generale in single call vs agent chains.

Il moltiplicatore dei retry

I retry sono la voce che nessuno budgettizza. Un'API di scraping va in timeout, il modello restituisce JSON con una virgola finale, un rate limit scatta alla terza ricerca. Ogni retry rifattura tutto ciò che è dentro il ciclo che riavvia. Se la vostra policy di retry riavvolge l'intero task invece del singolo step fallito, uno strumento instabile può triplicare il costo di quel task.

Due metriche individuano questo problema in anticipo. La prima è chiamate agli strumenti per task completato, tracciata come distribuzione con la sua coda, non solo come media. La seconda è tentativi per task completato, che vi dice quante volte il ciclo è stato riavviato. Quando la coda di una delle due cresce, la vostra bolletta cresce prima dei vostri dashboard. Limiti rigidi su entrambe, applicati nel codice e non nel prompt, sono il controllo più economico che esista. Anche rendere idempotenti le azioni a pagamento, in modo che una re-esecuzione non le ripeta, conta allo stesso modo, e lo abbiamo trattato in AI agent duplicate actions and idempotency.

Costi fissi che sembrano piccoli finché non riducete la scala

Una coda, due worker, un'istanza Postgres e una piattaforma di tracing sono economici in termini assoluti. Divisi su qualche migliaio di task al mese sono quasi gratuiti. Divisi su duecento task al mese possono costare più per task di tutte le chiamate API messe insieme. Le piattaforme di tracing che tariffano per span sono la versione più estrema di questo fenomeno: un agent con dodici step emette dodici span per task, più i retry.

In quale regime vi trovate decide gran parte della vostra architettura. A basso volume, un runtime per agent gestito che fattura per esecuzione è spesso più economico che gestire il proprio stack, e i costi fissi scompaiono nel margine di qualcun altro. Ad alto volume l'aritmetica si inverte e auto-ospitare gli strumenti più pesanti comincia a convenire. I trade-off sono spiegati in managed vs self-hosted agent runtimes.

Come stimare prima di costruire

Potete arrivare a un intervallo ragionevole prima ancora di scrivere codice, a condizione di fare il lavoro su carta prima:

1. Scrivete il ciclo come una lista di chiamate. Per ogni step, annotate il provider e l'intervallo atteso di chiamate per task (minimo, tipico, caso peggiore).
2. Valutate ogni step al prezzo di listino. Segnate quali sono a chiamata, quali sono per seat con una quota e quali sono fisse mensili.
3. Moltiplicate per i tentativi attesi. Scegliete un'assunzione onesta sui retry per il pilota e sostituitela con dati misurati entro la prima settimana.
4. Distribuite i costi fissi sul volume mensile. Infrastruttura, tracing e qualsiasi licenza, divisi per il numero di task completati che vi aspettate realmente, non per il numero del pitch deck.
5. Confrontate con il valore di un task completato. Se un lead qualificato o un ticket risolto vale meno del costo nel caso peggiore per produrlo, ridisegnate il ciclo prima di costruirlo.

Poi eseguite un pilota di qualche centinaio di task con il cost tracking per step attivato dal primo giorno. Il pilota serve a sostituire le vostre stime negli step uno e tre. Se durante il pilota tracciate solo i token, arriverete in produzione con una bolletta del modello che capite e una bolletta degli strumenti che non capite.

Le leve che muovono davvero la bolletta

Una volta ottenuti numeri misurati, la maggior parte dei risparmi viene da una lista breve:

• Riducete gli step. Ogni chiamata al modello che eliminate elimina anche i suoi retry e i suoi span.
• Memorizzate in cache i risultati degli strumenti. Fate lo scraping di un dominio una volta e riutilizzatelo tra i task. Date ai risultati di ricerca un time-to-live misurato in giorni per tutto ciò che non è notizia.
• Auto-ospitate lo strumento pesante quando il volume lo giustifica. Scraping e piccoli modelli di estrazione sono i candidati tipici, come nel nostro motore di outreach.
• Batchate tutto ciò che non è urgente. Enrichment e classificazione notturni possono passare attraverso endpoint batch scontati invece di chiamate live.
• Limitate le chiamate agli strumenti per task nel codice. Un'istruzione nel prompt che dice "cerca al massimo tre volte" è un consiglio. Un contatore nel ciclo è un controllo.
• Instradate per step. Usate un modello piccolo per estrazione e formattazione e riservate il modello di frontiera alla valutazione che richiede giudizio, seguendo il ragionamento in small LLM vs frontier model.

Notate che i consigli incentrati sui token nella maggior parte delle guide ai costi si trovano in fondo a questa lista per gli agent. Vale ancora la pena seguirli, e teniamo una guida separata all'ottimizzazione dei costi LLM, ma riguarda la bolletta più piccola.

Cosa chiedere prima di firmare

Se un fornitore o un'agenzia vi quota un prezzo per token e una fee mensile per la piattaforma, la stima è incompleta. Chiedete il costo previsto per task completato e le assunzioni dietro quel numero. Chiedete quante chiamate agli strumenti fa un task tipico e come si presenta il caso peggiore. Chiedete come sono limitati i retry e se le azioni a pagamento sono idempotenti. Chiedete quali costi sono fissi e cosa succede al costo per task se il vostro volume è la metà di quanto pianificato.

Un team che ha fatto girare un agent in produzione risponderà a queste domande con numeri presi da un dashboard. Un team che ha costruito solo demo risponderà con i prezzi dei token. Se state valutando il prezzo di un agent in questo momento e volete un secondo parere sul ciclo prima di impegnarvi su uno stack, parliamone.