Perché delego il codice ai sotto-agenti di Claude Code?

Il mio sistema di deleghe per Claude Code è un orchestratore multi-agente: Opus progetta, assegna e verifica, e i sotto-agenti (subagents) con modello Sonnet o Haiku scrivono il codice, ognuno nella propria finestra di contesto (context window). Lo uso da agosto 2026. Il metodo generale è in Come lavoro con l'AI nello sviluppo. Qui racconto il sistema di deleghe e i token che misura.

Ho cominciato a studiare il problema a luglio, perché consumavo troppi token, e da agosto uso questo approccio: le prove di quelle settimane mi hanno mostrato dove si perdevano i token, e lo studio ha ripagato. Passare all'abbonamento successivo mi sembrava la risposta sbagliata: il lavoro banale poteva andare a modelli meno pregiati, e il modello più potente poteva restare per le decisioni. Volevo anche che lo smistamento avvenisse da solo, senza cambiare modello a mano a ogni richiesta.

Agente singolo o orchestratore: che cosa cambia in Claude Code?

Con un agente singolo il modello principale fa tutto, e ogni file letto, ogni tentativo e ogni output restano nel suo contesto fino alla fine della sessione. Con un orchestratore il modello principale scompone il lavoro, lo affida a sotto-agenti con un contesto proprio e ne integra i risultati: Anthropic chiama questo schema orchestrator-workers (si apre in una nuova scheda).

Il contesto pulito conta anche per la qualità. Anthropic descrive il calo con il nome di «context rot»: con l'aumento dei token nel contesto il modello richiama con meno precisione le informazioni che contiene, in modo graduale. Il grafico mette a confronto i due flussi sullo stesso lavoro.

Perché un sotto-agente parte già con il contesto giusto?

Quando Opus delega, Claude Code apre per il sotto-agente un prompt nuovo, e quel prompt comincia con la specifica: obiettivo, file da toccare, vincoli, comando di verifica, forma del resoconto. La storia della sessione resta fuori. Il sotto-agente legge i file che la specifica indica e lavora su quelli, con un contesto fatto apposta per il compito.

È il concetto su cui si regge tutto il sistema. Opus scrive che cosa serve in una specifica di circa 920 token, la mediana delle mie deleghe a Sonnet, e il sotto-agente parte da lì. In una sessione unica, invece, ogni nuovo compito si aggiunge a tutto quello che c'era prima.

Quanti token restano fuori dal contesto di Opus?

Un turno con una delega aggiunge al contesto di Opus 18.914 token in mediana, verifica compresa. Lo stesso lavoro fatto da Opus ne aggiungerebbe circa 67.000. Il primo valore viene da 580 turni con una delega. Il secondo è una stima: un turno di Opus senza deleghe, 5.829 token in mediana, più il lavoro del sotto-agente, cioè il suo picco di contesto meno i circa 13.000 token con cui parte.

Un compito che torna indietro costa altri token, e li conto. Fra gli esiti che registro dopo ogni revisione, 4 su 18 sono «corretto»: Opus ha sistemato il lavoro con un turno in più, in mediana 5.829 token. Spalmato su tutte le deleghe, il turno delegato sale a circa 20.200 token, e la delega fa risparmiare a Opus il 70% del contesto.

Nei 18.914 token c'è tutto quello che Opus fa per la delega: legge i file che servono alla specifica, la scrive, riceve il resoconto e verifica il risultato leggendo il diff e l'output dei test. La verifica in lettura della risposta la tengo apposta, perché è il punto in cui controllo il lavoro.

Il sotto-agente lavora con molto più contesto di quello che restituisce. In mediana un sotto-agente coder-sonnet ha lavorato con 85.283 token e ha restituito a Opus un resoconto di circa 1.150 token, settantaquattro volte meno, su 1.127 deleghe con resoconto riconosciuto.

I valori cadono dentro quelli che Anthropic indica per i sotto-agenti (si apre in una nuova scheda): decine di migliaia di token esplorati, un riassunto di 1.000-2.000 token. I token letti dal sotto-agente restano nel conto complessivo. Cambia il modello che li legge. Uno studio di The Infinity (si apre in una nuova scheda) su 23.747 turni arriva alla stessa conclusione: a parità di contesto un token costa uguale, e la delega conviene quando il contesto principale è già grande.

In pratica, nello stesso contesto di Opus entrano più turni. Nel grafico la compattazione automatica arriva dopo quattordici turni senza deleghe, e allo stesso punto con le deleghe Opus ha circa 337.000 token, il 66% in meno. Per me è questo il guadagno: a parità di token spesi da Opus, nella mia esperienza porto avanti più lavoro e con una qualità più alta.

Un token di Sonnet o di Haiku costa meno di un token di Opus, quindi i token dei diversi modelli si guardano separati e senza sommarli.

Quanto spendo in meno con i sotto-agenti di Claude Code?

Nei 36 giorni misurati la spesa è scesa fra il 12 e il 30%, a seconda del contesto delle sessioni, con lo smistamento messo a punto per tipo di richiesta. Il lavoro che resta a Opus, cioè specifica, verifica e decisioni, costa uguale nei due casi e resta fuori dal conto.

Il 12% viene dal costo reale delle 1.141 deleghe a Sonnet, raddoppiato come se le avesse fatte Opus. Il resto è una stima, perché gli stessi turni senza deleghe non li ho mai eseguiti. Più una sessione è lunga, più il risparmio si avvicina al 30%: ogni token lasciato nel contesto di Opus si paga di nuovo a ogni chiamata.

Quanto budget di token di Opus libero con i sotto-agenti?

Sul budget di token di Opus le deleghe ne liberano fra il 22 e il 51%: con lo stesso budget porto avanti da 1,3 a 2 volte i turni. È il conto che conta in abbonamento, dove l'uso ha un limite invece di una fattura.

Il conto somma tutti i token che Opus elabora: input, output, scritture e letture dalla cache. Anthropic non pubblica quanto pesa ciascuna voce sul limite di un piano, quindi la percentuale vale per il volume di token, non per il limite esatto.

Quando Opus arriva alla compattazione automatica?

Opus 5.5 ha una finestra di contesto di un milione di token (si apre in una nuova scheda), e Claude Code la compatta in automatico (si apre in una nuova scheda) a circa 967.000 token, riassumendo la storia della sessione. Su 135 sessioni delle mie due macchine, 16 sono arrivate alla compattazione anche con le deleghe attive. Un fork della sessione, che eredita tutto il contesto del padre, è partito in mediana da circa 521.000 token.

Quale modello uso per ogni sotto-agente di Claude Code?

Il codice piccolo e meccanico va a Haiku, quello con il contesto del repository a Sonnet, i rami irreversibili a un Opus dedicato, e Opus come orchestratore tiene architettura, revisione e commit. A decidere è Opus, con criteri che si possono osservare: quanti file tocca il compito, quanto contesto del repository serve, quanto è reversibile. Da lì sono nate cinque scelte di progetto.

1. La regola sta in un file, una volta sola. Nel CLAUDE.md globale una tabella dice quale compito

va a chi, e vale in ogni sessione senza ripeterla.

1. Un modello per tipo di lavoro. Il codice piccolo e meccanico va a Haiku, quello con il contesto

del repository a Sonnet, i rami irreversibili a un Opus dedicato. I riassunti di log e i testi vanno a un modello locale con Ollama, a costo zero in token Claude. A Opus restano architettura, modifiche di poche righe, revisione e commit. Quando i compiti sono indipendenti, Opus lancia più Sonnet in parallelo, ognuno con il proprio contesto.

1. Ogni esecutore conosce i propri limiti. Quando un compito li supera, l'agente lo rifiuta e lo

rimanda al livello sopra, invece di tentarlo male.

1. Il promemoria arriva nel turno. Il CLAUDE.md resta contesto di sfondo, e un hook ripete la

regola breve accanto a ogni richiesta di codice, dove pesa quanto la richiesta.

1. Ogni delega lascia un esito. Senza un verdetto registrato il sistema si giudica a sensazione.

Con l'esito si vede quante deleghe arrivano integrate, ritoccate o rifatte.

Come ho realizzato il sistema di deleghe in Claude Code?

L'ho realizzato con funzioni native di Claude Code: agenti in ~/.claude/agents/, regole nel CLAUDE.md, hook in settings.json, più un piccolo comando per gli esiti e un registro sul mio server, condiviso dai computer della rete da cui lavoro.

Una riga della tabella delle regole, così come la legge Opus:

| codice con **contesto del repo**,
  coerenza multi-file,
  test da far girare
| Sonnet
| `Agent(subagent_type: "coder-sonnet")`
  con specifica precisa |

Il frontmatter dell'esecutore piccolo, con il limite che lo fa fermare:

---
name: coder-haiku
description: >-
  Esecutore economico per lavoro PICCOLO e MECCANICO.
  [...] in quel caso risponde FUORI LIMITE
  e va usato coder-sonnet.
model: haiku
tools: Read, Edit, Write, Bash, Grep, Glob
---

**Se il compito esce dai limiti non lo tenti**:
la prima riga della risposta è
`FUORI LIMITE, passa a coder-sonnet: <motivo>`
e ti fermi lì (niente modifiche ai file).

L'hook che porta la regola nel turno, in settings.json:

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "$HOME/.local/bin/delega-hint"
          }
        ]
      }
    ]
  }
}

E il verdetto che Opus registra dopo ogni revisione:

ai-mcp esito <agent_id> \
  ok|corretto|rifatto|fuori-limite \
  [nota]

La differenza l'ho sentita sui compiti lunghi. Passo spesso da un progetto all'altro, con contesti molto diversi e profondi, e prima i miei task si accumulavano in disordine nella stessa sessione: anche lavorando con OpenSpec, a volte ripartivo da zero per riavere un lavoro pulito. Rileggere tutto il contesto era l'unica alternativa, e costava proprio il contesto che volevo salvare. Oggi Opus fa da mentore: tiene lo stato del lavoro, assegna i pezzi, controlla quello che torna e lo rivede.

Come controllo il lavoro dei sotto-agenti?

Ogni delega passa da due controlli: la revisione di Opus e gli strumenti di qualità del progetto. Opus legge la specifica che ha scritto, il resoconto e il diff, rilancia i test, e solo dopo committa. Sui moduli Drupal che pubblico su drupal.org il codice passa da phpcs con gli standard Drupal e DrupalPractice, da phpstan, da cspell e dalla suite phpunit, prima di ogni push.

Il controllo pesa poco perché sta dalla parte della lettura. Nel listino di Anthropic (si apre in una nuova scheda) un token di output di Opus 5.5 costa cinque volte un token di input e cento volte un token letto dalla cache. Nei 36 giorni misurati i sotto-agenti hanno scritto il 77% dei caratteri finiti nei file. In token di output il rapporto si rovescia: Opus ne ha prodotti 39,5 milioni, il 74,7%, e i sotto-agenti 13,4 milioni, perché l'output di Opus comprende ragionamento, specifiche, revisioni e chiamate agli strumenti.

Come dichiaro l'uso degli agenti nei miei progetti l'ho scritto in Che cosa chiede l'AI Act a chi sviluppa software con agenti AI?

Come uso i log per regolare le deleghe?

Ogni delega lascia una traccia nel registro: chi l'ha ricevuta, con quale specifica, quanti token ha usato e con quale esito. Con quei log metto a punto le regole invece di cambiarle a sensazione, e alcune scelte del sistema sono nate così.

• Haiku per il lavoro piccolo. I compiti brevi e meccanici andavano tutti a Sonnet: da ottobre li

riceve Haiku, che ha la stessa finestra ufficiale di un milione di token, con un limite stretto, un file nuovo di al massimo 150 righe o un piccolo refactoring meccanico. Nei miei test, con questi limiti, sbaglia di rado. Nel campione misurato conta per ora due deleghe, troppo poche per una statistica, e il registro dirà se il limite regge.

• Il modello più potente solo su richiesta. Fable costa più di Opus per ogni token, secondo il

listino, quindi parte solo quando lo chiedo io.

• Il classificatore davanti al prompt, tolto. Sui turni reali i prompt con il suo suggerimento

delegavano quasi quanto quelli senza: le regole prendevano già la stessa decisione.

In cosa il mio sistema di deleghe si differenzia dai router di modelli?

Il mio sistema si differenzia perché tiene insieme quattro pezzi: regole di smistamento per tipo di lavoro, limiti per ogni esecutore con la risalita al livello sopra, una verifica obbligatoria fatta dall'orchestratore che ha scelto l'esecutore, e un registro degli esiti. Nei documenti ufficiali che ho letto gli altri strumenti ne coprono una parte.

I router scelgono il modello e lasciano fuori il risultato. Gli strumenti con una verifica, come Aider, il coding agent di Copilot (si apre in una nuova scheda) o Bugbot, la affidano a test, linter o a un secondo passaggio di revisione, separato da chi ha scelto l'esecutore.

Perché ho costruito un sistema di deleghe invece di usare un router pronto?

Ho costruito il mio per avere il controllo del risultato. Un router decide il modello e la sua responsabilità finisce lì. Io volevo che chi assegna il lavoro sia anche chi lo verifica, con la specifica in mano e il repository sotto gli occhi, e che ogni verdetto resti scritto. Claude Code offre già tutti i mattoni: i sotto-agenti accettano un modello per ciascuno, e la documentazione (si apre in una nuova scheda) lascia la scelta a chi li scrive, senza un criterio automatico di difficoltà. La verifica invece la deve costruire chi usa lo strumento.

Ho provato anche Rizzo Flow (si apre in una nuova scheda), un motore locale di decisioni tipizzate, come classificatore davanti a ogni prompt. Nel mio contesto era superfluo: la classificazione la faccio già a monte con le regole, e i miei contesti sono ben delimitati, quindi resta poco da indovinare su che compito sia. In più costava tempo: dal suo log, su 3.748 prompt dal 2 ottobre, il ritardo mediano era di 1,97 secondi, con il 90° percentile a 3,75 secondi, 18 timeout e circa 150 minuti di attesa in tutto. Il mio hook di promemoria impiega circa un centesimo di secondo.

Opus segue sempre la regola di delega?

Opus segue la regola in parte: il promemoria è comparso in 533 turni, e in 149 di questi Opus ha delegato, il 28%. Il comportamento è noto anche fuori dal mio caso: nell'issue #42856 (si apre in una nuova scheda) del repository di Claude Code un utente descrive regole di delega obbligatorie scavalcate «per efficienza». L'esito registrato serve anche a questo: mostra i giorni in cui le deleghe calano.

Da quali transcript vengono i numeri sulle deleghe?

I numeri vengono da 36 giorni di transcript di Claude Code sulle mie due macchine, dal 17 settembre al 22 ottobre 2026: 5.145 prompt scritti da me e 1.390 deleghe, 1.141 delle quali a coder-sonnet. I token vengono dai campi usage che Claude Code scrive in ogni transcript.

Il campione copre un mese perché Claude Code cancella i transcript più vecchi di trenta giorni. Dentro il campione il risultato è stabile: in ognuna delle sei settimane il resoconto di un coder-sonnet è rimasto fra 1.030 e 1.270 token in mediana, e il rapporto con il contesto non è mai sceso sotto 44 a 1. La struttura delle deleghe è la stessa da agosto, e nella mia esperienza il risultato è lo stesso in tutti i mesi in cui uso questo approccio. Gli esiti li registro da ottobre.

Fonti

• Building effective agents (si apre in una nuova scheda), Anthropic, 19 dicembre 2024. Consultata il 22/10/2026.
• Effective context engineering for AI agents (si apre in una nuova scheda), Anthropic, 29 settembre 2025. Consultata il 22/10/2026.
• Sotto-agenti di Claude Code (si apre in una nuova scheda), documentazione ufficiale. Consultata il 22/10/2026.
• Listino dei modelli Claude (si apre in una nuova scheda), Anthropic. Consultata il 22/10/2026.
• The Subagent Tax, Measured: 23,747 Turns of Real Billing Data (si apre in una nuova scheda), The Infinity, 19 agosto 2026. Consultata il 22/10/2026.
• Model overrides mandatory delegation triggers in CLAUDE.md (si apre in una nuova scheda), issue #42856. Consultata il 22/10/2026.