Passa al contenuto principale

Perché gli agenti AI bruciano token (e come mettere un tetto al conto)

Intermedio

Un turno di chat costa una frazione di centesimo. La stessa domanda affidata a un agente — uno che legge file, chiama tool e cicla finché non ha finito — può costare dollari. I team lo scoprono nel modo più duro: un coding agent lasciato girare accumula un conto che un umano alla tastiera non farebbe mai. La parte spaventosa non è la media; è che non puoi prevederlo in anticipo, e il costo dello stesso task può oscillare enormemente.

Questa pagina spiega perché gli agenti bruciano token (il meccanismo non è quello che quasi tutti immaginano), mostra i numeri che sorprendono anche i builder esperti e ti dà le quattro leve che tagliano davvero il conto — le stesse leve, che tu sia su Claude Code, Cursor, Codex o un loop fatto in casa su qualsiasi modello.

What you'll learn
  • Spiegare la valanga di contesto — perché il costo dell'agente cresce all'incirca in modo QUADRATICO con i passi, non lineare
  • Citare i moltiplicatori reali: i task agentici ~1000x i token di una chat, e lo STESSO task che varia fino a 30x
  • Sapere quando un secondo agente vale la pena — e il benchmark che mostra che di solito non la vale
  • Tirare le quattro leve di costo che funzionano: tetti di budget, prompt caching, routing per tier di modello, potatura del contesto
  • Diagnosticare un conto agente fuori controllo e mettergli un tetto rigido

La valanga di contesto: perché il costo cresce in modo quadratico​

Ecco la trappola. Una chat è un turno — un input, un output, finito. Un agente è un loop: legge un task, compie un'azione, legge il risultato, compie l'azione successiva e così via finché il lavoro non è finito. Il punto è che a ogni passo il modello ri-legge l'intera conversazione accumulata finora — il prompt originale, ogni azione precedente e ogni risultato dei tool — prima di decidere cosa fare dopo.

Quindi l'input cresce a ogni passo, e paghi di nuovo l'intera valanga ogni volta che rotola avanti:

  • Il passo 1 elabora il prompt.
  • Il passo 2 ri-legge il prompt + l'azione e il risultato del passo 1.
  • Il passo 3 ri-legge tutto quello + l'azione e il risultato del passo 2.
  • …e così via.

Somma l'input su tutto un run e il totale scala all'incirca con il quadrato del numero di passi, non linearmente. Lo Stanford Digital Economy Lab ha trovato che i task agentici sono "uniquely expensive, consuming 1000x more tokens than code reasoning and code chat" — e, cosa cruciale, sono i token di input a dominare, non l'output. L'agente non scrive di più; ri-legge di più.

What you'll learn
  • Il driver del costo è la ri-lettura, non il pensiero. Ogni passo del loop ri-elabora l'intera trascrizione, quindi un run di 20 passi paga il contesto iniziale ~20 volte.
  • È per questo che 'lascia che l'agente se la sbrogli' è costoso: ogni passo in più che fa si moltiplica contro tutto ciò che è venuto prima.
  • I task output-heavy (scrivimi un saggio) sono economici al confronto; i loop input-heavy (esplora questo repo, poi correggi il bug) sono dove finiscono i soldi.

I numeri che sorprendono le persone​

Tre cifre resettano l'intuizione di quasi tutti:

  • ~1000x. I task agentici possono consumare all'incirca mille volte i token di una chat o code-completion equivalente, secondo l'analisi di Stanford — guidati dalla valanga di cui sopra, non da un modello più grande.
  • Fino a 30x di varianza sullo stesso task. Lo stesso agente, eseguito sullo stesso task, può costare fino a 30x in più una volta rispetto a un'altra — perché il percorso che prende (quanti tool chiama, quanto vaga) è non deterministico. Non puoi davvero sapere il conto finché non è finito. È per questo che il "pricing basato sul risultato" per gli agenti è così difficile: vedi il costo solo dopo che tutto è girato.
  • Più agenti raramente si ripagano. I benchmark di produzione del 2026 hanno trovato che una configurazione multi-agente aggiungeva solo ~2,1% di accuratezza a 2x il costo rispetto a un singolo agente ben configurato sul 64% dei task. Un pattern gerarchico con supervisore ha spinto un task documentale dall'85% → 95% di accuratezza — ma a circa $0,15/task contro $0,003 per il singolo agente (~50x). Più agenti comprano un po' di accuratezza per molti soldi.
Watch out
  • Poiché lo stesso task varia fino a 30x, un budget basato sulla media VERRÀ sfondato dalla coda. Metti un tetto al massimo, non fare budget sulla media.
  • Aggiungere agenti 'per sicurezza' di solito moltiplica il costo molto più in fretta di quanto aggiunga accuratezza. Ricorri a un secondo agente solo quando il task si decompone davvero in sottotask paralleli e indipendenti.

La tua superficie di tool è parte del conto​

Prima ancora che il loop parta, il modo in cui l'agente raggiunge i suoi tool fissa un pavimento di costo. Collegare un set di server MCP può iniettare decine di migliaia di token di definizioni dei tool in ogni passo della valanga. Un confronto grezzo che molti builder incontrano: un semplice comando CLI fa in media ~200 token, mentre l'operazione MCP equivalente può costare 32k–82k token una volta contati gli schemi dei tool e il wrapping. Quel divario viaggia insieme a ogni passo del loop.

Questo non rende MCP sbagliato — è la scelta giusta per auth, multi-tenancy e accesso governato. Significa che la superficie di tool è una leva di costo che hai scelto in fase di design. AILmanac ha un approfondimento dedicato: La tassa dei token MCP copre Tool Search, il caricamento differito e l'esecuzione di codice come i tre rimedi.

Le quattro leve che tagliano davvero il conto​

I consigli di ottimizzazione sono infiniti; solo quattro leve muovono il numero in modo materiale. In ordine approssimativo di leva:

Guided walkthrough1 of 4
  1. Imposta un tetto di token/dollari per-run o per-utente che FERMI DI NETTO l'agente. Poiché lo stesso task può costare 30x in più su un run sfortunato, un tetto è l'unica cosa che delimita la coda. Quasi tutti gli harness per agenti espongono un limite di max-tokens o max-steps — usalo. È il singolo controllo più importante.

Audit di un agente fuori controllo (incolla la ripartizione dei token del tuo run)

You are a cost engineer. Here is a token-usage breakdown of one agentic run
(input vs output tokens per step, tool calls, model used).

Diagnose where the money went, in priority order:
1. Is input or output driving cost? (Agents are almost always input-heavy.)
2. Which repeated content should be prompt-CACHED (system prompt, tools, rules)?
3. Which steps could run on a CHEAPER model without losing correctness?
4. Where is context snowballing — what can be pruned, compacted, or summarized?
5. What is a safe per-run token CAP that stops the worst tail without hurting the median run?

Give me the estimated % saving per fix and the ONE change to make first.

Quando un agente è lo strumento sbagliato​

Il run agentico più economico è quello che non fai. Se un task è una singola trasformazione ben specificata — riassumi questo, classifica quello, riscrivi questo — una semplice chiamata chat/completion lo fa a una frazione del costo, con nessuna valanga. Ricorri a un agente quando il lavoro richiede davvero leggere, decidere, agire e ri-controllare in un loop contro un ambiente che cambia (esplora un repo, fai debug su più file, guida un browser). Se puoi scrivere tu stesso i passi esatti, mettili in uno script — non pagare un modello per ri-derivarli a ogni run.

Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 5

Check yourself

0/3
  1. Perché un run agentico costa molto più di un singolo turno di chat per la stessa domanda?
  2. Un collega vuole aggiungere un secondo e un terzo agente 'per sicurezza' su un task che un singolo agente già gestisce all'85% di accuratezza. Cosa suggeriscono i benchmark del 2026?
  3. Dato che lo STESSO task può costare fino a 30x in più su un run rispetto a un altro, qual è il modo giusto di controllare la spesa?

Fonti e approfondimenti​