AIDiveIntro: il worker economico che nessuno chiama
I subagent di Claude Code ignorano Haiku 5.5 finché due file non dicono il contrario. È tutto il risultato, e il resto di questo articolo è la misura che lo sostiene: sette task quotidiani su un repository reale, con Haiku 5.5, Sonnet 5.5 e Opus 5.5 a turno nel ruolo di worker, e il contatore del piano letto dopo ogni blocco di run.
Haiku 5.5 è uscito il 7 ottobre 2026, presentato da Anthropic come il modello per i subagent, a un decimo del prezzo per token del vecchio Haiku. Un mese di log di un solo account racconta l'altra metà della storia: 2.631 run di subagent, 42 su Haiku, perché ogni subagent eredita il modello principale. Spostare tutti i subagent su Haiku solleva una domanda ovvia: quanto restituisce davvero il contatore del piano? Due file mettono l'agente Explore su Haiku, e l'impostazione a cui la maggior parte delle persone pensa per prima da sola non fa nulla. Il pannello di ripartizione dell'uso, quello di cui tutti si fidano, è calcolato a partire da quattro numeri incorporati nel binario.
Quanto costa un task su ogni modello
Haiku 5.5 costa $0,10 per milione di token in input e $0,50 per milione di token in output, contro $1 e $5 di Haiku 4.5. Il prezzo vale per prompt fino a 100.000 token; oltre quella soglia l'intera richiesta costa cinque volte di più. La cifra del "90%" di Anthropic non è uno sconto: è la quota di richieste al precedente Haiku che restavano sotto quella soglia.
| Modello | Input per 1M di token | Output per 1M di token |
|---|---|---|
| Haiku 5.5 (prompt fino a 100k) | $0,10 | $0,50 |
| Haiku 5.5 (prompt oltre 100k) | $0,50 | $2,50 |
| Haiku 4.5 | $1,00 | $5,00 |
| Sonnet 5.5 | $2,00 | $10,00 |
| Opus 5.5 | $4,00 | $20,00 |
Dal campo arrivano altre due insidie. Il nuovo tokenizer conta lo stesso testo come circa il 30% di token in più rispetto a Haiku 4.5. E con effort max, una run indipendente ha misurato circa 162.000 token di output per task, circa tre volte un modello concorrente. La frase di Anthropic è prudente: Sonnet e Opus restano la scelta migliore per il coding agentico complesso. Su Terminal-Bench 4.0, Haiku 5.5 ottiene il 39,2% contro il 70,6% di Sonnet 5.5.
Il test copre i task che un subagent riceve davvero. Un repository reale, tinydb, con 226 test nella suite. Sette tipi di task: esplorare il codice, correggere un test che fallisce, ripulire gli errori di lint, scrivere un commit message, aggiungere una piccola feature, rivedere un diff, riassumere l'architettura. Quattro worker: Haiku 5.5 con effort medium, Haiku 5.5 con effort low, Sonnet 5.5, Opus 5.5. In tutto 182 run, ognuna verificata da un test nascosto o da una regola fissa, mai a occhio.
| Configurazione | Run | Accettate | Piccola feature, prezzo di listino | Piccola feature, tempo reale |
|---|---|---|---|---|
| Haiku 5.5, effort low | 70 | 70 | $0,0052 | 17,1 s |
| Haiku 5.5, effort medium | 70 | 70 | $0,0078 | 26,3 s |
| Sonnet 5.5 | 21 | 21 | $0,1050 | 30,3 s |
| Opus 5.5 | 21 | 21 | $0,1675 | 30,3 s |
Esplorare il codebase è costato $0,0035 su Haiku low e $0,1454 su Opus, circa quaranta volte di più. Haiku non è mai stato più lento: sette task, tutti accettati, a una frazione del prezzo, veloce uguale o di più.
Perché nulla gira su Haiku di default
Nulla va su Haiku da solo, ed è voluto. Dalla release 2.1.198 l'agente Explore integrato eredita il modello della sessione principale, con tetto Opus; prima di quella release girava su Haiku. Ogni subagent personalizzato fa lo stesso. La documentazione indica l'ordine di risoluzione: il modello indicato all'avvio, poi il modello nel file dell'agente, poi la variabile CLAUDE_CODE_SUBAGENT_MODEL, e solo dopo il modello principale.
In quell'elenco c'è una trappola, e la documentazione la dice chiaramente: impostare da sola la variabile del modello dei subagent non cambia il modello su cui girano gli agenti Explore e Plan integrati. Due run headless confermano entrambe le affermazioni. Con la sessione principale sul modello Fable e una sola domanda (usa l'agente Explore per trovare dove viene svuotata la cache delle query), il risultato del tool indica il modello che ha girato davvero: Opus 5.5. La stessa run con la variabile del modello dei subagent impostata su Haiku 5.5 e nient'altro: di nuovo Opus 5.5.
Per questo un mese di log ha l'aspetto che ha. Su 2.631 run di subagent, 42 sono andate su Haiku. I subagent hanno consumato il 48,1% di tutti i token dell'account, e la quota di Haiku sul costo ponderato era dello 0,27%. Il default è una scelta difendibile: un esploratore sul tuo modello principale legge il codice bene quanto il modello principale. Quello che nessuno stampa è quanto costa.
I due file
Due file risolvono il problema, e puoi prenderne uno o entrambi. Il più piccolo è un singolo file di agente nel tuo progetto: crea .claude/agents/Explore.md, chiamalo Explore, dagli una descrizione, imposta il modello su claude-haiku-5-5 con l'id completo, imposta l'effort su low e limita i tool a Read, Glob, Grep e Bash. Da quel momento Claude Code tratta il tuo file come l'agente Explore, e la documentazione lo dice senza giri di parole: definisci un subagent di progetto chiamato Explore e dagli il modello Haiku. La stessa run headless riporta allora resolvedModel: claude-haiku-5-5.
Il secondo file sono le tue impostazioni. Un blocco env in .claude/settings.json con due variabili: CLAUDE_CODE_SUBAGENT_MODEL impostata su claude-haiku-5-5 e CLAUDE_CODE_SUBAGENT_MODEL_FORCE impostata su 1. Il force è la parte che la gente trascura. Dalla release 2.1.257, quel flag applica il modello dei subagent a ogni subagent, ignorando le sostituzioni impostate all'avvio o in un file di agente. La stessa run con queste due variabili nell'ambiente e senza file di agente legge di nuovo Haiku 5.5.
| Cosa vuoi | Usa | Effetto collaterale |
|---|---|---|
| Ogni subagent economico | Il blocco env delle impostazioni con il flag force | Anche i tuoi agenti volutamente su Opus scendono a Haiku |
| Solo l'esploratore economico | Il file dell'agente Explore | Gli altri agenti mantengono il proprio modello |
Fissa l'id completo del modello. L'alias haiku significa Haiku 5.5 solo sull'API di Anthropic; su Bedrock, Vertex e Foundry significa ancora Haiku 4.5. Una issue aperta nel repository di Claude Code segnala 1.149 subagent su 1.371 che giravano sul modello Opus del genitore nonostante il file dicesse altro, in modo intermittente su una dozzina di build (da 2.1.277 a 2.1.290), senza risposta da parte di Anthropic. Sulla build attuale, la 2.1.293, tutte le 182 run hanno usato il modello configurato. Controlla comunque: il comando /tasks mostra il modello su cui ha girato ogni subagent, e anche il risultato del tool di una run headless lo riporta. L'effort è la leva che resta, perché su questi modelli il thinking non si può disattivare; l'effort low nel file Explore è una scelta deliberata, e quello che offre è misurato più avanti.
Cosa ha visto il contatore reale
Ogni run headless con output in streaming emette un rate_limit_event. Al suo interno ci sono due frazioni, la finestra di cinque ore e la finestra di sette giorni, con due decimali ciascuna. Arrivano direttamente dagli header di risposta che Anthropic invia a ogni risposta, con la risoluzione di un punto e niente di più fine. I quattro worker sono stati eseguiti come quattro blocchi, uno dopo l'altro, senza che nient'altro toccasse l'account.
| Blocco | Run | Finestra di cinque ore prima | Finestra di cinque ore dopo | Finestra settimanale |
|---|---|---|---|---|
| Haiku 5.5, effort low | 70 | 21% | 21% | 67% |
| Haiku 5.5, effort medium | 70 | 21% | 21% | 67% |
| Sonnet 5.5 | 21 | 21% | 22% | 67% |
| Opus 5.5 | 21 | 22% | 23% | 67% |
A prezzo di listino l'intera matrice è costata $4,09. Sul contatore è costata due punti di una finestra di cinque ore e zero punti della settimana. La metà Haiku è costata $0,54 e non ha spostato nulla: un punto della finestra di questo account vale più di 140 di questi task su Haiku.
Anthropic pubblica una sola frase sul peso dei modelli: Opus costa diverse volte più di Sonnet per turno, e Sonnet più di Haiku. Diverse. Nessun numero, da nessuna parte. Le finestre sono un unico pool per tutti i modelli, quindi cambiare modello a metà sessione non restituisce nulla. Ogni blocco porta con sé fino a un punto di arrotondamento, il che significa che il punto di Sonnet e il punto di Opus non si distinguono. Quello che il contatore dimostra con certezza è che un task circoscritto, con uno qualsiasi di questi modelli, è invisibile a questa risoluzione. Il peso di ciascun modello va letto altrove.
Il riepilogo di /usage è una stima
Apri il pannello /usage e ottieni una ripartizione: percentuali attribuite a skill, subagent, plugin e server MCP. Sembra un dato del server. Non lo è. La documentazione dice che le cifre sono approssimative e calcolate dalla cronologia delle sessioni locale su questa macchina, quindi la formula vive nel binario. Esegui strings sull'eseguibile e ne escono due funzioni.
| Fattore | Peso |
|---|---|
| Livello del modello: Fable | 10 |
| Livello del modello: Opus | 5 |
| Livello del modello: Haiku | 1 |
| Livello del modello: qualsiasi altro | 3 |
| Token in cache | 1 |
| Token di input nuovi | 10 |
| Scritture in cache | 12,5 |
| Token di output | 50 |
Il peso del record è la somma dei token moltiplicata per il livello del modello. Sono i pesi di attribuzione del client, non la prova di come il server fattura la tua quota, e il divario si vede. Applica la formula ai blocchi qui sopra: 70 run Haiku medium ottengono 29,5 unità, 21 run Opus ne ottengono 27,3. Il pannello classificherebbe il blocco Haiku sopra il blocco Opus; il contatore reale ha detto zero punti contro uno.
Sotto c'è un secondo difetto. Una issue aperta segnala che le trascrizioni dei subagent registrano l'uso del primo chunk di streaming: una run ha registrato 461 token di output dove la stessa run in headless ne ha registrati 15.575. Una trascrizione su questa macchina mostra 16 token di output su ogni voce dell'assistente. La formula moltiplica per 50 questa cifra sottostimata, quindi i subagent che scrivono molto spariscono dal pannello. Usalo per quello che è: quale skill o agente consuma la tua cronologia locale, con le chiavi di giorno e settimana. Per il peso di un modello nella tua quota reale, è una congettura.
Dove va davvero la quota di una giornata
La scala che il contatore riesce a vedere è un giorno. Andrea Grandi ha pubblicato i suoi numeri il giorno in cui è uscito Haiku 5.5, su un piano Pro. La sua sessione principale gira su Opus 5.5 con effort medium; un agente implementer su Sonnet 5.5 scrive il codice; due agenti Haiku 5.5 fanno il resto, uno scoper in plan mode senza tool di modifica e con al massimo dodici turni, e uno shipper con effort low che fa commit, push e apre la PR.
| Misura | Valore |
|---|---|
| Pull request su sessioni | 13 su 10 |
| Finestra di cinque ore per PR | circa 6% |
| Contatore settimanale per sessione con una sola PR | circa 1% |
| Costo stimato per PR con i subagent | $2,31 |
| Costo stimato per PR solo con Opus | $3,59 |
| Richieste per sessione, prima e dopo | da 75 a 54 |
| Token per richiesta, prima e dopo | da 119.000 a 107.000 |
La sua frase è il punto: se valuta i token dei subagent a tariffa Opus, le dieci sessioni diventano solo il 5% più care. Il risparmio è venuto dal contesto principale che è rimasto piccolo. Un mese di log dice lo stesso dall'altro lato: i subagent hanno consumato il 48,1% dei token, e il 96% di tutti i token erano letture di cache. Ogni subagent parte con un prompt di avvio; su questo account la mediana è di 47.000 token, ed è lo stesso stack che il worker sia Opus, Sonnet o Haiku. Cambiare modello non lo riduce.
L'effort invece cambia l'appetito. Sulla piccola feature, Haiku con effort medium ha letto 233.000 token in 14 turni; Haiku con effort low ne ha letti 140.000 in 8 turni per lo stesso risultato accettato; Opus ne ha richiesti 88.000. Una run indipendente ha misurato la stessa curva più in alto: 55.000 token di output per task con effort high, 162.000 con max. Economico per token, più vorace per task, e la manopola è tua. Due avvertenze: i dollari di Grandi sono una stima su un piano Pro, e la matrice qui è un piccolo repository. Nessuno dei due è una settimana su un piano Max.
La tabella di routing, i limiti, il pack
La tabella di routing: esplorare il codice, correggere un test che fallisce, ripulire il lint, scrivere il commit message, aggiungere una piccola feature, rivedere un diff, riassumere l'architettura. Tutti e sette vanno a Haiku 5.5 con effort low, con 70 run su 70 accettate sia a low sia a medium. Per task sono tra un quinto di centesimo e mezzo centesimo a prezzo di listino, contro i sei-diciassette centesimi di Opus. Quello che resta su Sonnet o Opus è il coding agentico complesso, nelle parole di Anthropic, dove Terminal-Bench porta Haiku a 39,2 contro 70,6; l'unica recensione testata del lancio si chiudeva sulla stessa riga: resta su Sonnet per il coding difficile.
I due file stanno accanto alla tabella: il file dell'agente Explore con l'id completo di Haiku e l'effort low, e il blocco env delle impostazioni con il modello dei subagent e il flag force. La verifica è il comando /tasks, che mostra il modello su cui ha girato ogni subagent. Fidati di quella riga, mai del file.
Torniamo alla domanda iniziale. Sposta ogni subagent su Haiku, e cosa restituisce il contatore? Per un task circoscritto, meno di un punto su qualsiasi modello. L'intera matrice di 182 run ha spostato la finestra di cinque ore di due punti e la settimana di zero. La settimana vera arriva dal contesto principale e dal prompt di avvio che ogni subagent si porta dietro. Cambiare modello è la parte economica, e prenderla non costa nulla.
| Limite | Dettaglio |
|---|---|
| Repository | Un piccolo repo, tinydb, 226 test |
| Dimensione dei task | Sette task circoscritti sotto il minuto ciascuno, non una giornata di coding agentico |
| Contatore | Un punto di risoluzione, più o meno un punto per blocco |
| Moltiplicatore | Nessuno pubblicato da Anthropic per modello |
| Versione | Claude Code 2.1.293 l'8 ottobre 2026; le build precedenti ignoravano il modello del file dell'agente (issue aperta) |
Il pack gratuito contiene la tabella di routing, i due file e l'harness che l'ha misurata: i sette prompt, i controlli e il runner.
