L'Illusione dei Token

C'è un pattern che continua a emergere nelle sessioni di agenti in produzione: dai a un assistente AI un task semplice, fa un buon lavoro, e poi guardi il conteggio dei token e ti gira la testa.

Un developer di recente ha instrumentato una sessione dove un agente ha chiuso una issue su GitHub. Ha letto l'issue, modificato un file, eseguito i test, fatto il commit, aperto una pull request. Lavoro pulito, completo, utile.

Il output? Circa 10.300 token di ragionamento e generazione effettiva.

Il contesto totale processato? Poco più di 1,55 milioni di token.

Fammi entrare. Siamo a un rapporto lavoro-overhead di circa 1:150. L'agente non stava pensando con 1,5 milioni di token. Li stava trascinando dietro come mobili in un truck dei traslochi che non riusciva a scaricare.

Se stai usando agenti di coding nel tuo workflow — che sia per startup development, automazione DevOps, o solo per accelerare le code review — questo rapporto sta silenziosamente divorando il tuo budget, gonfiando la latenza, e aumentando il rischio di context rot (dove il modello inizia a perdere il filo perché la finestra di conversazione è troppo affollata per essere parsata in modo pulito).

Quindi smontiamo dove quei token effettivamente finiscono.

Anatomia di una Sessione Gonfiata

Dopo aver analizzato dati di sessione su diverse run di agenti, il pattern diventa chiaro. La maggior parte del consumo di token non viene dal ragionamento del modello. Viene dal context scaffolding — l'infrastruttura che l'agente necesita solo per operare.

L'esplosione del catalogo tool. Questo è il problema principale, e tende a coglierti di sorpresa. Più server MCP (Model Context Protocol) connetti, più definizioni di tool vengono iniettate nella context window. In una sessione, nove server MCP erano connessi, esponendo circa 260 tool. Quando due di loro si sono attaccati a metà sessione, un server da solo elencava circa 180 nomi di tool. Questo succede una volta per connessione, ma non esce mai dalla history della conversazione. Resta lì, si accumula, aggiunge peso a ogni turno successivo.

La tassa del catalogo skills. A differenza dei dump di tool, che sono un costo una-tantum, il catalogo skills è una spesa per-turno. Decine di skill, ognuna con descrizioni di più frasi, caricate su ogni singola interazione. Questo non fa spikare drammaticamente il conteggio — alza semplicemente il floor. Sessione dopo sessione, gonfia silenziosamente la tua baseline.

System prompt e overhead infrastrutturale. Prima che il tuo agente faccia qualsiasi cosa, in molte configurazioni sei già oltre 100k token. Il system prompt, le safety policy, gli schemi dei tool, e le istruzioni di formatting si caricano ogni turno. Sono necessari, ma non sono il lavoro.

Il task vero e proprio. Ecco la parte scomoda: il testo dell'issue, le modifiche ai file, l'output dei test, il messaggio di commit — tutto combinato potrebbe essere qualche migliaio di token. Il task è minuscolo rispetto all'officina.

Perché Conta Più di Quanto Pensi

Potresti essere tentato di scrollare le spalle. "I token sono economici, no?"

Lo sono — finché non stai facendo girare venti sessioni di agenti al giorno, ognuna gonfiata da fattori che non sapevi di poter controllare. La matematica si compounds veloce. E non è solo una questione di costi.

Alto volume di contesto significa maggiore latenza. Il modello deve processare di più a ogni turno, rallentando i tempi di risposta proprio quando hai bisogno di velocità.

Più criticamente, il context rot diventa un problema reale. Quando il contesto di lavoro del tuo agente è pieno di definizioni di tool, descrizioni di skill, e history di conversazione che non servono per il task immediato, inizia a perdere signal-to-noise. Potrebbe dimenticare contexto rilevante dall'inizio della sessione, fraintendere cosa gli stai chiedendo, o prendere decisioni basate su informazioni vecchie sepolte in fondo alla finestra di conversazione.

Per startup che si muovono veloci, non è un inconveniente minore — è un problema di affidabilità.

Come Misurare Davvero Cosa Stai Spendendo

L'istinto è indovinare. "Forse questa sessione è grande perché il task è complesso." Di solito, non lo è. Di solito, è l'infrastruttura.

Tre approcci che funzionano davvero:

1. Leggi il blocco usage sulla tua risposta API finale. Ogni risposta dal tuo modello porta statistiche di usage: output token (cosa il modello ha generato), input token (cosa hai inviato), e cache_read_input_tokens (cosa è stato prelevato dalla history della conversazione). Quel numero cache_read è la tua smoking gun. Se legge 1,5 milioni di token e il tuo output era 10k, hai un quadro chiaro del rapporto di overhead.

2. Controlla lo stato del contesto della sessione a metà run. La maggior parte dei framework di agenti moderni ha un comando come /context che mostra esattamente cosa sta occupando la tua window in questo momento, categorizzato. Questo è come catturi i costi per-turno — il catalogo skills e gli schemi — che un blocco usage finale non può separare cleanly dal task effettivo.

3. Audit delle tue connessioni tool prima di aggiungerne altre. Prima di connettere un altro server MCP o aggiungere un'altra capability al tuo agente, chiediti: quanto mi costerà per turno? Una singola definizione di tool potrebbe andare bene. Cento definizioni di tool attraverso decine di server è un silenciosus budget killer.

Modi Pratici per Ridurre il Rapporto

Ora la parte utile. Se hai identificato che le tue sessioni di agenti sono token-heavy, ecco da dove iniziare a tagliare.

Semplifica le tue connessioni tool. Audit ogni server MCP e chiediti se sta tirando il suo peso. Se un server espone 50 tool e il tuo agente ne ha usati 3, c'è una disconnect. Considera se ti servono tutti quei tool connessi sempre, o se potresti scoped them by fase di task.

Usa contesti focalizzati invece di quelli globali. Invece di caricare l'intero catalogo tool e libreria skills in ogni sessione, considera configurazioni specifiche per task. Un agente che aiuta con code review non ha bisogno dello stesso contesto di uno che scrive infrastructure code.

Monitora per-sessione, non solo per-mese. Controllare costi aggregati nasconde gli outlier. Guarda i conteggi token di sessioni individuali e inizi a vedere pattern — quali task fanno spikare, quali connessioni si gonfiano, quali skill non vengono mai usate ma sono sempre caricate.

Considera modelli e framework costruiti per l'efficienza. Alcuni framework di agenti sono più token-efficient di altri by design. L'ambiente di sviluppo AI-assisted di Vibe Hosting è costruito tenendo a mente questo — dandoti il power dei workflow agentic senza l'overhead nascosto che mangia i tuoi margini.

Il Bottom Line

La prossima volta che fai girare un agente di coding e senti che il rapporto intelligenza-costo è sbilanciato, probabilmente hai ragione. I token non stanno andando dove pensi. La maggior parte sta trasportando l'officina — i tool, le skill, gli schemi, e lo scaffolding della conversazione — non facendo il lavoro vero.

Misura prima. Il blocco usage e i comandi /context non mentono. Una volta che puoi vedere dove vanno i token, puoi fare decisioni informate su cosa tagliare. Nella maggior parte dei casi, troverai spazio significativo per ottimizzazione senza sacrificare capability.

Il tuo agente non ha bisogno di trasportare l'intera officina. Ha solo bisogno dei tool giusti per il job. Assicurati di dargli esattamente quello.