Subagenti di Claude Code: quanto costano davvero, dove conviene tenerli e quando smettono di lavorare

Un subagente di Claude Code è una sessione separata, con il suo contesto, a cui deleghi un compito e che ti restituisce un riassunto. Costa più di quanto sembra, e non per il motivo che immagini: su 858 esecuzioni che ho misurato, il 94,4% dei token è contesto riletto e solo lo 0,78% è quello che l'agente scrive. Il costo segue i turni, non le risposte.

Questo pezzo è il secondo di una serie sulla configurazione di Claude Code. Il primo, sugli hook, parlava di cosa il modello non può fare. Questo parla di chi esegue, di quanto ti costa, e di quando conviene smettere.

Una premessa sul perimetro, perché è la prima cosa che andrei a controllare io. Tutti i numeri che seguono vengono da un conteggio sui transcript di Claude Code di una mia macchina, dal 19 luglio al 5 settembre 2026, 24 giornate di lavoro su 12 progetti. Sono la mediana del mio lavoro, non una costante del prodotto: usali per capire la forma del problema, non per stimare la tua bolletta. E siccome lavoro su più computer, non sono nemmeno tutto il mio uso: sono quello che sta su questa macchina.

Quanto costa davvero un subagente?

La risposta utile non è un numero, è una forma.

Il subagente mediano attraversa 359.969 token di contesto. La media è 1.712.629, cioè 4,8 volte la mediana. Il p99 è 17,5 milioni e il peggiore che ho misurato è arrivato a 61.468.112 token, 171 volte la mediana.

Quando una distribuzione ha la media cinque volte la mediana, la media non descrive niente che ti capiterà: descrive la coda. Chi ti dice "un subagente costa circa X" ti sta raccontando i suoi outlier.

Il peggiore vale la pena guardarlo da vicino, perché è istruttivo: un agente di aggiornamento della documentazione, lanciato a mano su un codebase grande, senza un perimetro dichiarato. 202 turni di modello, 255 chiamate a strumenti, 31,6 minuti. Non ha sbagliato niente. Ha solo continuato a leggere.

Perché quasi tutto il conto è contesto riletto?

Perché a ogni turno il modello riceve di nuovo l'intera conversazione. La documentazione di Claude Code sui costi lo dice per esteso: la conversazione viaggia intera a ogni richiesta, e una domanda da una riga in una sessione aperta da ore attinge comunque per tutta la conversazione.

Sui 1.368.390.396 token attraversati dai subagenti nel periodo misurato, la scomposizione è questa:

• rilettura di contesto: 94,4%
• input fresco e creazione di cache: 4,8%
• output: 0,78%

Quel filo sottile in fondo alla barra è tutto quello che i subagenti hanno scritto. La conseguenza pratica è la prima regola che ho ricavato: non ti fa male quanto scrive, ti fa male quanti turni fa. Un agente a cui dai un obiettivo esplorativo farà molti turni, e ogni turno ripaga l'intero contesto accumulato fino lì.

Il profilo delle chiamate lo conferma. Su 16.314 chiamate a strumenti: Bash 5.419, Read 4.049, Grep 1.522, Glob 947, Edit 896, Write 216. Le scritture sono il 6,8% del totale. I subagenti leggono, e il costo segue la lettura.

C'è però il rovescio della medaglia, ed è il motivo per cui i subagenti esistono: proprio perché l'output verboso resta nel loro contesto e a te torna solo il riassunto, delegare le operazioni rumorose fa risparmiare. Il subagente conviene quando l'input è voluminoso e il ritorno è una pagina.

Quanto paghi prima che l'agente abbia fatto qualcosa?

Questo è il numero che ha cambiato il mio modo di lavorare più di tutti gli altri.

Misurato sul primo turno di ogni esecuzione: mediana 37.063 token, p10 36.537. Fra il decimo percentile e la mediana c'è meno del 2% di scarto. Non è una variabile: è una tariffa.

Dentro ci sono, e la documentazione li elenca uno per uno, il system prompt, il messaggio di delega, i file CLAUDE.md di ogni livello della gerarchia, uno scatto del git status preso all'avvio della sessione madre e le skill precaricate.

Rileggi la parte in grassetto e poi guarda il tuo CLAUDE.md. Non lo paghi una volta: lo paghi moltiplicato per ogni agente che lanci. La documentazione consiglia di tenerlo sotto le 200 righe spostando le istruzioni specialistiche nelle skill, che si caricano solo quando servono. Con i subagenti quel consiglio vale moltiplicato per la dimensione dell'ondata.

Da qui la regola operativa: se il compito si chiude in due minuti nella sessione che hai già aperto, delegarlo significa comprare un biglietto da 37.000 token per un viaggio da un isolato. Si ripaga quando l'agente fa molti turni su materiale che nella tua sessione non deve entrare: la trascrizione lunga, il PDF impaginato, il log da diecimila righe.

Perché lo stesso lavoro costa quattro volte tanto se lo chiedi a voce?

Delle 799 esecuzioni di cui ho potuto ricostruire il costo, 700 giravano dentro un workflow scritto e 99 erano lanciate a mano dalla sessione. Stesso tipo di lavoro, stessa metrica.

Sono token pesati, cioè un proxy di costo che conta l'input, la creazione di cache, un decimo della rilettura e l'output. Non è il contatore ufficiale di Anthropic, ed è dichiarato come stima.

3,8 volte, e la differenza non è il modello. È che scrivere un workflow ti costringe a ritagliare il compito prima di lanciarlo: dichiari le fasi, dici a ogni agente cosa deve tornare, e quello che non serve resta fuori. Quando chiedi a voce, il perimetro lo decide l'agente mentre lavora, e lo decide largo.

Quando conviene lanciarne cinquanta invece di uno?

Quando uno solo non ce la farebbe.

L'esempio più chiaro che ho è un lavoro sul JSON schema di tutti gli articoli di questo blog: parametri da rivedere e correggere, uno per articolo, cinquantaquattro articoli. L'ho fatto lanciando un agente Sonnet per articolo, e in venti minuti era finito. Questo lo racconto come esperienza diretta, non come misura: è successo su un'altra macchina e nei transcript che ho analizzato non c'è.

Ma la ragione per cui l'ho fatto così non era la velocità. Era che un agente solo non sarebbe arrivato in fondo. Cinquantaquattro articoli in sequenza, dentro una finestra di contesto sola, significano un contesto che cresce fino a degradare: gli ultimi articoli li avrebbe trattati peggio dei primi, e con ogni probabilità sarebbe morto prima. Il fan-out non serviva a fare la stessa cosa più in fretta, serviva a renderla possibile.

È il criterio che uso adesso per decidere se aprire un'ondata: il lavoro si spezza in parti indipendenti che non hanno bisogno di sapere l'una dell'altra? Se sì, tante teste piccole battono una testa grande, e il costo per parte scende perché ognuna porta solo il suo pezzo. Se le parti devono parlarsi, l'orchestrazione diventa spesa e basta.

Un limite tecnico da conoscere, e va letto con attenzione perché è controintuitivo: quando in una sessione ci sono 20 subagenti attivi, crearne un altro fallisce, e l'errore dice esplicitamente di non riprovare. Non si accodano. Il numero si cambia con CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. Se lanci ondate grandi, l'accodamento devi gestirtelo tu, o lo fa per te lo strumento di orchestrazione che stai usando.

Dove metti gli agenti: dentro il progetto o sopra i progetti?

Io li ho messi sopra, in un plugin aziendale che tutti i repo caricano, e continuo a pensare che sia la scelta giusta. Il criterio è questo: nel livello aziendale va il mestiere, nel progetto resta l'oggetto.

Un revisore di brand, un verificatore visivo, un revisore di sicurezza, un analista funzionale sono mestieri: esistono identici in qualunque progetto, e una lezione che impari su un cliente serve al cliente dopo. Se quell'agente vive dentro .claude/agents/ di un repo, la lezione muore lì. Il test è veloce: se lo sposti in un altro repo e perde il suo oggetto, allora è locale. Un agente che conosce lo schema del database di quel gestionale resta dov'è.

Il catalogo oggi è di 17 agenti: 13 Sonnet, 4 Opus, nessun Haiku. Sette dichiarano uno sforzo di ragionamento alto, gli altri ereditano quello della sessione. Undici su diciassette non hanno né Write né Edit, ed è deliberato: a un revisore togli la possibilità di riscrivere quello che sta giudicando, altrimenti smette di giudicare e comincia a sistemare.

Adesso la parte scomoda, che è anche la più utile.

Nove di quei diciassette agenti non sono mai partiti, e nessuno è mai stato cancellato. Peggio: su 42 script di orchestrazione, uno solo chiama un agente del plugin per nome, e il 92% delle esecuzioni è andato a lavoratori anonimi definiti al volo dentro il workflow.

Cioè: il catalogo è la scelta giusta e io per primo lo sto scavalcando. Quando scrivo un workflow definisco l'agente lì dentro, perché è più veloce, e il ruolo curato con la sua motivazione e il suo toolset resta a guardare. È un difetto di disciplina, non di architettura, e il fatto che si veda solo contando è esattamente il motivo per cui ho contato.

Quando una cosa è un agente, e quando è un hook o una skill?

Tre domande in fila, e la prima che risponde sì decide.

Si può verificare a macchina e deve valere sempre? Allora è un hook, e costa quasi niente. Un controllo che filtra prima del modello riduce il contesto da decine di migliaia di token a centinaia: il pezzo sugli hook racconta dove va messo e perché il primo lo metterai nel posto sbagliato.

È una procedura che tu invochi quando serve? Allora è una skill, e ha il vantaggio di caricarsi solo al momento dell'uso invece di stare sempre in contesto.

Serve un giudizio che una regex non dà? Solo allora è un agente. E c'è una seconda ragione legittima per crearne uno, indipendente dal giudizio: l'isolamento del contesto, cioè quando ti serve un contenitore che si prenda i megabyte e ti restituisca una pagina.

Sul modello, la regola che applico è a tre livelli: modello caro solo dove sbagliare costa soldi, dati o una contestazione; modello medio come default per il giudizio qualitativo; per i compiti meccanici, prima di scegliere un modello, chiediti se non sia un hook. E prima di alzare il modello, chiediti come fallisce davvero quell'agente: se fallisce stancandosi a metà, alzare lo sforzo di ragionamento costa una frazione e compra esattamente quello che ti serve.

Cosa succede quando il limite arriva a metà di un fan-out?

Succede che gli agenti ancora in coda muoiono senza produrre niente, e il lavoro va ripagato per intero, perché non esiste un riavvio automatico.

Nel periodo misurato: 59 subagenti su 858, il 6,9%, uccisi dal limite prima di produrre un solo token. Cinquantacinque di quei cinquantanove su due soli progetti, cioè il problema non è diffuso, si concentra dove le ondate sono grandi. Ho contato 166 messaggi di limite, di cui 158 di sessione, 3 settimanali e 5 di crediti esauriti; 121 sono arrivati dentro un subagente e 45 nel thread principale.

Sul conteggio delle giornate devo allargare il perimetro dichiarato all'inizio, altrimenti il numero non torna: i muri hanno toccato 16 giornate su 56, e quelle 56 sono l'archivio intero di Claude Code su questa macchina, che parte dal 12 maggio 2026. È una finestra più larga di quella dei subagenti perché ai limiti ci arrivavo anche prima di usarli.

Tutto questo mi è successo mentre stavo su un piano Max 5x. Sono passato al Max 20x a inizio settembre 2026, quando ho cominciato a usare i subagenti in modo massiccio. Non ti dico che il 20x risolve, perché ci sto sopra da pochi giorni e non ho i dati per affermarlo. Ti dico due cose separate: sul 5x i muri arrivavano una giornata di lavoro su tre e mezzo, e le ondate di agenti sono il modo più rapido che conosco per arrivarci, come dicono i 55 morti su due soli progetti.

C'è una terza via, e l'ho provata: i crediti a consumo. Ne ho comprati un centinaio di euro fra maggio e giugno 2026, e sono evaporati in tre ore di agenti. Servono a sfondare un muro in un momento in cui non puoi fermarti, non a cambiare regime di lavoro.

Quale abbonamento serve, allora?

I prezzi ufficiali, verificati il 5 settembre 2026 sulla pagina di Anthropic, sono in dollari e al netto delle imposte applicabili: Pro 17 USD al mese con sconto annuale (20 se mensile), Max 5x 100 USD, Max 20x 200 USD. Claude Code è incluso in tutti i piani a pagamento e condivide i limiti con il resto del piano, con una finestra che si azzera ogni cinque ore più un limite settimanale.

E qui devo dirti una cosa che nessuna guida dice, perché non fa comodo: quei moltiplicatori non sono convertibili in niente. Il Max 5x dà cinque volte l'uso del Pro e il 20x venti volte, ma la base non è pubblicata, quindi non esiste alcun modo onesto di tradurli in ore, messaggi, token o numero di agenti. Chiunque ti scriva "con il piano X puoi lanciare N agenti" se lo sta inventando.

Quello che le fonti reggono è questo: Anthropic stessa consiglia il passaggio dal 5x al 20x a chi colpisce i limiti con costanza. Se lanci ondate di agenti, li colpisci. Il resto lo devi misurare tu, e il comando /usage ti mostra l'attribuzione del consumo recente a skill, subagenti, plugin e server MCP, su 24 ore o 7 giorni. Con un caveat che la documentazione dichiara: sono cifre approssimate, calcolate sulla cronologia locale di quella macchina, quindi non comprendono l'uso da altri dispositivi.

Come ti accorgi che un workflow ha finto di andare bene?

Non guardando il risultato, perché il risultato arriva comunque.

Nel mio archivio ci sono una revisione chiusa con stato completato che aveva perso nove verificatori su ventidue al limite, e una in cui tutti e tre gli agenti sono morti insieme dopo aver consumato 339.196 token e 113 chiamate a strumenti, consegnando un log che diceva "confermati zero su zero". Nessuna delle due si è presentata come fallita.

Dopo un'ondata controllo tre cose, e mi ci vogliono venti secondi: lo stato di ogni agente (quanti ne sono partiti e quanti hanno consegnato), la corrispondenza fra il numero di rilievi e il numero di verdetti, e che tutte le fasi dichiarate siano davvero partite. Se il conto non torna, il risultato non è sbagliato: è incompleto, che è peggio, perché sembra completo.

Un'ultima cosa sulla qualità, e vale come avvertimento. Ho fatto verificare i rilievi di una revisione da agenti indipendenti, tre per rilievo, con il mandato di provare a smontarli. Su una relazione in prosa, su 46 rilievi ne sono caduti 29, il 63%. Sullo stesso schema applicato al codice, dove il verificatore può aprire il file e contare, i respinti sono stati zero su settanta. La lezione: il verificatore avversariale vale quanto vale ciò che può controllare. Dagli un fatto verificabile e ti evita un errore; dagli un'opinione e ti restituisce una seconda opinione travestita da verdetto.

Domande frequenti

Quanto costa lanciare un subagente in Claude Code?

Sulla misura fatta su 858 esecuzioni reali, il subagente mediano attraversa 359.969 token di contesto, ma la media è 1.712.629, cioè 4,8 volte tanto, e il caso peggiore misurato è arrivato a 61.468.112. La media descrive la coda, non il caso tipico: conviene pianificare sulla mediana. Sono numeri di un uso specifico su una macchina, non una costante del prodotto.

Perché un subagente consuma tanto anche se scrive poco?

Perché quasi tutto il consumo è rilettura di contesto. Sulla stessa misura, il 94,4% dei token è cache read, il 4,8% è input fresco più creazione di cache e solo lo 0,78% è output. Ogni turno ripaga l'intero contesto accumulato fino a quel punto, quindi il costo segue il numero di turni, non la lunghezza della risposta.

Conviene sempre delegare a un subagente?

No. Un subagente parte da circa 37.000 token di contesto prima di aver fatto qualsiasi cosa, ed è un costo fisso: system prompt, messaggio di delega, i CLAUDE.md della gerarchia, il git status della sessione madre e le skill precaricate. Se il compito si chiude in due minuti nella sessione già aperta, quel biglietto non si ripaga. Si ripaga quando l'agente fa molti turni su materiale voluminoso che nella tua sessione non deve entrare.

Quanti subagenti si possono lanciare in parallelo?

Con 20 subagenti gia' attivi in una sessione, crearne un altro fallisce con un errore che dice di non riprovare: non si accodano da soli. Il numero si cambia con la variabile CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. Ma il tetto tecnico non è il budget: quanti te ne puoi permettere dipende dalla finestra del tuo piano, e nessuna fonte ufficiale pubblica quel numero.

Quale abbonamento Claude serve per usare i subagenti in modo intensivo?

Claude Code è incluso in tutti i piani a pagamento e condivide i limiti del piano. I prezzi verificati il 5 settembre 2026 sono Pro 17 dollari al mese con sconto annuale, Max 5x 100 dollari e Max 20x 200 dollari, al netto delle imposte. Anthropic consiglia il passaggio dal 5x al 20x a chi colpisce i limiti con costanza. I moltiplicatori però sono relativi a una base che non viene pubblicata, quindi non sono convertibili in ore, messaggi, token o numero di agenti.

Da dove partire

Se non hai mai contato quanto ti costano, comincia da lì: /usage ti dà l'attribuzione, e i tuoi transcript ti danno il resto. La misura richiede un accorgimento, altrimenti i conti vengono gonfi: lo stesso turno di modello compare su più record con lo stesso identificativo di richiesta, quindi vanno raggruppati e non sommati. Sui miei transcript di subagente, sommare i record così come stanno gonfia il totale di 2,24 volte.

Poi tre regole, in ordine di quanto mi hanno fatto risparmiare:

1. Guarda il tuo CLAUDE.md e taglialo. È il moltiplicatore che paghi su ogni agente.
2. Scrivi il compito prima di delegarlo. La differenza fra 82.337 e 313.958 token è tutta lì.
3. Apri un'ondata solo se le parti non devono parlarsi, e dopo controlla quanti agenti hanno davvero consegnato.

Gli strumenti che pubblichiamo stanno nell'Open Lab.