Vai al contenuto
Parliamo del tuo progetto

28 Ottobre 2026

Consumo di token dei coding agent: come ridurre costi e limiti senza perdere qualità

Limiti settimanali esauriti in pochi giorni, piani da 200 o 500 dollari che non bastano: il consumo di token è diventato il vero vincolo di chi lavora con gli agenti. Ecco dove finiscono i token e come usarli meglio.

Il coniglio Creattivo taglia il flusso di token sprecati tra un indicatore di consumo e un terminale

A fine settembre Cole Medin ha raccontato di aver esaurito i limiti di due piani da 200 dollari, Claude e Codex, giorni prima del rinnovo settimanale. A inizio ottobre Theo ha spiegato di aver speso 600 dollari per rivedere due piccole pull request con la nuova modalità Ultrafast di OpenAI. E proprio mentre i modelli diventano più capaci, cresce la sensazione che l’AI, invece di costare meno, costi sempre di più.

Il consumo di token è diventato il vero vincolo di chi lavora con gli agenti di coding. Non il modello, non gli strumenti: il budget. La buona notizia è che gran parte del consumo dipende da abitudini e configurazioni che si possono cambiare, spesso senza perdere qualità e a volte migliorandola.

In questa guida vediamo dove finiscono davvero i token, quali leve hanno l’impatto maggiore e come impostare un sistema che usi il modello giusto per ogni compito.

Per un’azienda il consumo di token è una nuova voce di costo, variabile e spesso non governata: abbonamenti individuali, chiavi API sparse nei progetti, automazioni che girano di notte. Capire da dove viene e come si controlla è la base per rispondere alla domanda che conta: l’AI ci fa guadagnare o ci costa e basta?

In breve

  • Ogni richiesta di un agente invia tutto il contesto della sessione: una sessione lunga costa anche quando fai domande brevi.
  • La maggior parte dei token si spende per leggere e cercare codice, non per scriverlo.
  • Le leve più efficaci sono: sessioni brevi, modello adatto al compito, livello di effort ridotto per i compiti semplici, output filtrati e meno strumenti caricati.
  • La cache dei prompt abbatte il costo del contesto ripetuto, ma si perde dopo le pause: una ripresa dopo un’ora rielabora tutto.
  • Combinare modelli diversi (uno potente per pianificare, uno economico per eseguire) è ormai una necessità, non un’ottimizzazione.
  • Prima di ottimizzare, misura: gli agenti offrono strumenti per vedere dove va il consumo.
  • Per chi decide: il costo degli agenti si governa come qualsiasi costo operativo: budget, limiti, attribuzione per progetto e una metrica che lo colleghi al valore prodotto, come il costo per attività completata.

Perché i limiti finiscono così in fretta

Il consumo di token di un agente di coding non cresce in modo lineare con il lavoro svolto. Cresce con la dimensione del contesto moltiplicata per il numero di richieste. Ogni volta che l’agente usa uno strumento (legge un file, esegue un comando, cerca nel codice) invia una nuova richiesta al modello con tutta la conversazione precedente più il nuovo risultato.

Facciamo un esempio. Una sessione ha accumulato 80.000 token di contesto. L’agente esegue dieci passi per completare un piccolo task. Sono dieci richieste da almeno 80.000 token di input ciascuna: 800.000 token per una modifica di poche righe. Con la cache dei prompt il costo per token del contesto ripetuto scende molto, ma il volume resta, e sui piani in abbonamento pesa sui limiti.

La documentazione di Claude Code lo dice chiaramente nella pagina sulla gestione dei costi: una domanda di una riga in una sessione aperta da tutto il giorno consuma comunque in proporzione all’intera conversazione. La stessa pagina riporta un dato utile come riferimento: nelle installazioni aziendali il costo medio è di circa 13 dollari per sviluppatore per giorno di utilizzo attivo, tra 150 e 250 dollari al mese, e resta sotto i 30 dollari al giorno per il 90% degli utenti. Chi supera di molto questi valori ha quasi sempre margini di miglioramento.

Come governare il costo degli agenti in azienda

Il consumo di token è una questione tecnica nei dettagli, ma di direzione nella sostanza. Ecco come impostarne il controllo.

1. Fai la mappa delle spese

Elenca tutte le voci: abbonamenti individuali agli strumenti AI, account API dei fornitori di modelli, strumenti di terzi che usano l’AI e la fatturano. In molte aziende la prima mappa rivela abbonamenti duplicati, chiavi dimenticate e automazioni che nessuno controlla più.

2. Scegli il modello di acquisto giusto per ogni uso

Per le persone che usano gli agenti ogni giorno, gli abbonamenti offrono costi prevedibili. Per i processi automatici (assistenti sul sito, classificazione di documenti, integrazioni) l’API a consumo, con limiti di spesa, permette di pagare per l’uso reale e di attribuire i costi ai singoli processi.

3. Attribuisci i costi

Chiavi API separate per progetto, reparto o cliente permettono di sapere quanto costa ciascuno. Per le agenzie e i fornitori di servizi è anche la base per ribaltare correttamente i costi sui progetti dei clienti.

4. Misura il ritorno

Il costo da solo non dice nulla. Va confrontato con il valore prodotto: tempo risparmiato, attività completate, tempi di consegna ridotti. Una formula semplice è sufficiente all’inizio: costo mensile degli agenti diviso per il numero di attività completate, confrontato con il costo del tempo che quelle attività avrebbero richiesto senza agenti. Come riferimento, Anthropic indica per Claude Code una spesa media aziendale tra 150 e 250 dollari al mese per sviluppatore: per valutare se è alta o bassa serve sapere quanto lavoro produce.

5. Rivedi ogni mese

I prezzi dei modelli cambiano spesso, così come i piani e i limiti. Una revisione mensile di spesa, utilizzo e risultati permette di adattare scelte di modelli e piani prima che i costi sfuggano.

Domande da fare ai fornitori di servizi basati sull’AI

  • Il costo dei modelli è incluso nel prezzo o fatturato a parte?
  • Cosa succede se i consumi raddoppiano? Esistono tetti?
  • Possiamo vedere i consumi per progetto o per processo?
  • Usate modelli diversi per compiti diversi, o il più costoso per tutto?

Dove finiscono davvero i token

Prima di ottimizzare conviene sapere cosa ottimizzare. In una sessione tipica di un agente di coding, le voci principali sono queste.

Voce Peso tipico Perché cresce
Lettura e ricerca del codice Molto alto L’agente legge file interi per capire quali contano
Output di comandi e test Alto e variabile Log lunghi, stack trace, output completi dei test
Cronologia della sessione Cresce nel tempo Ogni passo resta nel contesto fino a compattazione o chiusura
Ragionamento (thinking) Alto con effort elevato I token di ragionamento si pagano come output
Istruzioni e strumenti Fisso per ogni richiesta File di istruzioni lunghi, molti server MCP
Subagent e agenti paralleli Moltiplicativo Ogni agente ha il proprio contesto e le proprie richieste

Cole Medin ha dedicato un video proprio alla prima riga, Your Coding Agent Wastes SO MANY Tokens Just Finding Code: la ricerca è veloce, ma leggere tutto per capire cosa modificare consuma contesto prima ancora di iniziare a scrivere.

Per vedere i numeri reali della tua sessione, in Claude Code il comando /usage mostra token, costo stimato, statistiche della cache e, sui piani in abbonamento, una ripartizione per skill, subagent e server MCP con raccomandazioni concrete. Il comando /context mostra come è distribuito il contesto. Due minuti con questi comandi valgono più di qualsiasi consiglio generico.

Leva 1: sessioni brevi e contesto pulito

La leva più semplice è anche la più efficace: una sessione per task. Quando passi a un lavoro diverso, chiudi la sessione e aprine una nuova. In Claude Code /clear riparte da zero senza costi; /compact invece è esso stesso una richiesta pesante, perché deve leggere tutta la conversazione per riassumerla. Se non ti serve continuità, ripartire costa meno che compattare.

Per i task lunghi, un file di avanzamento aggiornato a fine fase permette di ripartire con poche centinaia di token invece di decine di migliaia. Abbiamo descritto il metodo nella guida al context engineering: un contesto pulito migliora la qualità e riduce i costi allo stesso tempo.

Leva 2: il modello giusto per ogni compito

Usare il modello più potente per tutto è come prendere un taxi per attraversare la strada. Cole Medin, nel video AI Coding Rate Limits are RIDICULOUS Now, ha costruito le stesse applicazioni in tre modi diversi per capire dove il modello migliore fa davvero la differenza e dove un modello più piccolo dà lo stesso risultato. La conclusione: non si può più usare il modello più potente per tutto.

Una divisione pratica dei compiti:

Compito Modello consigliato Perché
Pianificazione, architettura, debug complesso Il più capace disponibile Gli errori qui costano ore di lavoro successivo
Implementazione di task ben definiti Modello intermedio Con un buon piano, la differenza di qualità è piccola
Esplorazione del codice, ricerca, riassunti Modello piccolo e veloce Compiti semplici con molto input
Classificazioni e decisioni sì/no Modello decisionale o piccolo Non serve generare testo

In Claude Code si può cambiare modello durante la sessione con /model e assegnare un modello più piccolo ai subagent nella loro configurazione. La documentazione stessa suggerisce di riservare il modello più potente alle decisioni di architettura e al ragionamento in più passi.

Attenzione ai listini con soglie

I prezzi non sono sempre lineari. Haiku 5.5, il modello piccolo di Anthropic, secondo la scheda ufficiale costa 0,10 dollari per milione di token in input fino a 100.000 token di prompt e 0,50 oltre quella soglia. Come nota l’analisi di eesel, il nuovo tokenizer produce più token per lo stesso testo, e superare la soglia di poco può moltiplicare il costo della richiesta. Theo ha discusso proprio questo aspetto nel video su Haiku 5.5. Morale: un modello economico resta economico solo con contesti piccoli.

Leva 3: il livello di effort

I modelli recenti ragionano prima di rispondere, e i token di ragionamento si pagano come output. Il livello di effort controlla quanto ragionano. Matt Pocock, nel video Your effort level is STILL TOO HIGH, sostiene che per esplorare il codice e per le modifiche semplici un effort più basso dà spesso risultati migliori, oltre che più rapidi ed economici: il modello non si perde in ragionamenti inutili.

La documentazione di Anthropic sull’effort lo descrive come un segnale di comportamento, non un budget rigido: anche a effort basso il modello ragiona se il problema è difficile, ma meno. In Claude Code si imposta con /effort. La regola che suggeriamo: effort alto per pianificazione e debug difficili, medio o basso per implementazione di task chiari, esplorazione e modifiche meccaniche.

Leva 4: output filtrati e strumenti leggeri

Filtrare prima che arrivi al modello

Un test che fallisce può produrre migliaia di righe di output. All’agente servono le prime righe di ogni errore. Un hook o uno script che filtra l’output riduce il contesto da decine di migliaia di token a poche centinaia. La documentazione di Claude Code mostra un esempio di hook che riscrive i comandi di test per restituire solo i fallimenti:

#!/bin/bash
# Hook PreToolUse: per i comandi di test, mostra solo errori e fallimenti.
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')
if [[ "$cmd" =~ ^(npm test|pnpm test|pytest|go test) ]]; then
  filtered="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "$input" | jq --arg f "$filtered" \
    '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "allow",
      updatedInput: (.tool_input + {command: $f})}}'
else
  echo "{}"
fi

CLI invece di server MCP, quando possibile

Strumenti da riga di comando come gh, aws o gcloud non aggiungono definizioni di strumenti al contesto: l’agente li usa come qualsiasi comando. I server MCP restano indispensabili per i sistemi senza CLI, ma vanno attivati per progetto e disattivati quando non servono.

Navigazione semantica del codice

Per i linguaggi tipizzati, un language server permette all’agente di andare direttamente alla definizione di un simbolo invece di cercare con grep e leggere più file candidati. Claude Code lo supporta tramite plugin di code intelligence, che segnalano anche gli errori di tipo dopo ogni modifica senza dover lanciare il compilatore.

Leva 5: la cache dei prompt e le pause

La cache dei prompt memorizza la parte iniziale del contesto (istruzioni, strumenti, cronologia) e la fa pagare molto meno nelle richieste successive. È il motivo per cui le sessioni lunghe non costano ancora di più. Anthropic e OpenAI la descrivono nelle rispettive guide: prompt caching di Claude e prompt caching di OpenAI.

La cache però ha una durata limitata. Se fai una pausa più lunga della sua vita, la prima richiesta successiva rielabora tutto il contesto a prezzo pieno. Tre abitudini aiutano:

  • prima di una pausa lunga, chiudi il task o salva lo stato in un file e chiudi la sessione;
  • evita di modificare istruzioni o server MCP a metà sessione: cambiare la parte iniziale del contesto invalida la cache;
  • controlla le statistiche della cache (in Claude Code sono in /usage): una percentuale bassa di token serviti dalla cache è un campanello d’allarme.

Leva 6: subagent e agenti paralleli con criterio

I subagent proteggono il contesto dell’agente principale, ma ogni subagent fa le sue richieste. I team di agenti moltiplicano il consumo: la documentazione di Claude Code stima circa 7 volte i token di una sessione normale quando i compagni di squadra lavorano in modalità pianificazione. Regole pratiche:

  • assegna ai subagent un modello più piccolo quando il compito è esplorativo o meccanico;
  • scrivi istruzioni di avvio brevi e mirate;
  • chiudi gli agenti paralleli appena hanno finito;
  • usa il parallelismo per compiti davvero indipendenti, non per accelerare un lavoro sequenziale.

Le modalità veloci: quando valgono il prezzo

A inizio ottobre OpenAI ha introdotto Ultrafast, una modalità che secondo la copertura di AI Catchup fa girare GPT-6 Astra fino a 8 volte più velocemente in Codex, ma consuma i limiti inclusi a 8 volte la velocità standard ed è disponibile solo nel piano da 500 dollari. Theo ne ha parlato in tre video, dal titolo eloquente “I love Ultrafast (it’s unusable)”, e ha concluso che per ora, con i prezzi attuali, non conviene aggiornare il piano solo per questa funzione.

Anche Claude Code offre una modalità veloce. La valutazione è sempre la stessa: la velocità vale quando sei tu ad aspettare l’agente in un ciclo interattivo stretto (debug dal vivo, iterazioni rapide sull’interfaccia). Non vale per lavori in background, dove nessuno sta guardando l’orologio.

Il punto di vista opposto: usare più token, ma meglio

Non tutti pensano che l’obiettivo sia spendere meno. Theo, nel video If you have a Claude sub, watch this, sostiene che con un abbonamento il limite alla produttività è quanti token riesci a usare in modo utile, e invita a sfruttare il piano al massimo. E nel video I thought AI was gonna get cheaper? spiega che il costo per unità di intelligenza scende davvero, ma la spesa totale sale perché facciamo fare agli agenti molto di più.

I dati di mercato vanno nella stessa direzione: IndyDevDan, commentando le classifiche di OpenRouter nel video OpenRouter State Of Models, cita 146 mila miliardi di token elaborati in una sola settimana contro 4,5 mila miliardi un anno prima.

Le due posizioni non sono in contrasto. Il punto non è spendere poco, è non sprecare: ogni token risparmiato su contesto inutile, output non filtrati e modelli sovradimensionati è un token disponibile per lavoro che produce valore.

Errori comuni

Una sessione aperta tutto il giorno

È la causa più frequente di consumi anomali. Ogni domanda, anche banale, porta con sé tutta la giornata.

Il modello più potente come default per tutto

Comodo, ma costoso, e non sempre migliore: per i compiti semplici un modello più piccolo è più rapido e spesso altrettanto preciso.

Effort massimo fisso

Ragionare a lungo su una rinomina di variabile non migliora il risultato e consuma output.

Compattare invece di ripartire

La compattazione è una richiesta pesante. Se non serve continuità, una sessione nuova con un breve riepilogo costa meno.

File di istruzioni enormi

Ogni riga del file di progetto viene inviata a ogni richiesta. La documentazione di Claude Code consiglia di restare sotto le 200 righe e spostare le procedure in skill caricate al bisogno, come abbiamo visto nella guida alle agent skills.

Ottimizzare senza misurare

Senza dati si finisce a ottimizzare la voce sbagliata. Guarda prima cosa consuma di più.

Portarlo in produzione nel team

  • Limiti di spesa per persona o per gruppo, e avvisi prima del limite. Sui piani API, limiti per workspace.
  • Visibilità: esporta le metriche di utilizzo (Claude Code supporta OpenTelemetry) e guardale insieme al team una volta al mese.
  • Configurazione condivisa: modelli predefiniti, effort e server MCP decisi a livello di progetto, non lasciati alle abitudini di ciascuno.
  • Linee guida brevi: una pagina con le cinque regole d’oro (una sessione per task, modello adatto, effort adatto, output filtrati, pause gestite).
  • Costo per risultato: misura il costo per task completato o per pull request accettata, non per sviluppatore. È la metrica che collega la spesa al valore.

Il tuo team spende troppo in agenti AI o finisce i limiti a metà settimana? Con la formazione aziendale trasferiamo pratiche e configurazioni che riducono gli sprechi; nella consulenza AI analizziamo i dati di utilizzo e impostiamo limiti e modelli per progetto.

Da dove partire questa settimana

  1. Apri una sessione tipica e guarda /usage e /context (o gli strumenti equivalenti del tuo agente). Annota le tre voci più pesanti.
  2. Adotta la regola “una sessione per task” per cinque giorni.
  3. Imposta un modello più piccolo per i subagent di esplorazione e riduci l’effort per le modifiche semplici.
  4. Aggiungi un filtro sugli output dei test e disattiva i server MCP non usati.
  5. A fine settimana confronta il consumo con la settimana precedente e la qualità percepita del lavoro.

Checklist per un uso efficiente dei token

  • Conosci le voci che consumano di più nelle tue sessioni.
  • Ogni task ha la sua sessione; le sessioni non restano aperte tutto il giorno.
  • Il modello più potente è riservato a pianificazione e problemi difficili.
  • I subagent esplorativi usano un modello più piccolo.
  • L’effort è adeguato al compito, non fisso al massimo.
  • Gli output di test e comandi sono filtrati prima di entrare nel contesto.
  • Sono attivi solo i server MCP necessari al progetto.
  • Il file di istruzioni è sotto le 200 righe; le procedure sono in skill.
  • Le pause lunghe chiudono la sessione o salvano lo stato.
  • Esistono limiti di spesa e una revisione periodica dei consumi.

Domande frequenti

Perché il mio agente consuma così tanti token per modifiche piccole?

Perché ogni passo dell’agente invia al modello tutto il contesto accumulato nella sessione. In una sessione lunga, anche una modifica di poche righe richiede molte richieste con decine di migliaia di token ciascuna. Chiudere la sessione tra un task e l’altro è la correzione più efficace.

Conviene passare a un modello più economico?

Per alcuni compiti sì: esplorazione del codice, riassunti, implementazione di task ben definiti. Per pianificazione e debug complessi il modello più capace spesso fa risparmiare, perché sbaglia meno e riduce il lavoro successivo. La soluzione è combinare modelli diversi, non sceglierne uno solo.

Ridurre l’effort peggiora la qualità?

Per i compiti semplici di solito no, e a volte la migliora perché il modello non si perde in ragionamenti superflui. Per problemi difficili un effort alto resta utile. Conviene adattarlo al compito invece di tenerlo sempre al massimo.

Cos’è la cache dei prompt e perché si perde?

È un meccanismo che memorizza la parte iniziale del contesto e la fa pagare molto meno nelle richieste successive. Ha una durata limitata: dopo una pausa più lunga, la prima richiesta rielabora tutto a prezzo pieno. Anche modificare istruzioni o strumenti a metà sessione la invalida.

I piani in abbonamento convengono rispetto all’API a consumo?

Per un uso quotidiano e intenso di solito sì, perché il costo è prevedibile. L’API a consumo conviene per uso saltuario, per automazioni e quando serve controllo preciso su modelli e limiti. Molti team usano entrambi: abbonamenti per le persone, API per i processi automatici.

Come controllo la spesa di un team intero?

Con limiti di spesa per persona o gruppo, avvisi prima del limite, esportazione delle metriche di utilizzo e una revisione mensile. La metrica più utile è il costo per task completato, che collega la spesa al lavoro effettivamente consegnato.

Quanto costa in media un agente di coding per sviluppatore?

Anthropic indica per Claude Code, nelle installazioni aziendali, una media di circa 13 dollari per giorno di utilizzo attivo e tra 150 e 250 dollari al mese per sviluppatore, con il 90% degli utenti sotto i 30 dollari al giorno. Sono valori indicativi: il costo reale dipende da modello scelto, dimensione del codice e abitudini di lavoro.

Fonti e approfondimenti

Vuoi che gli agenti lavorino di più spendendo meno? Raccontaci come li usate oggi: partiamo dai vostri dati di consumo.