Claude Code manda 33k token prima di leggere il prompt, OpenCode ne manda 7k
Un test controllato ha messo Claude Code e OpenCode sullo stesso modello e sugli stessi compiti. Risultato: quando chiedi a entrambi una risposta di una riga, Claude Code invia circa 33.000 token di system prompt, schemi di tool e scaffolding prima che il tuo prompt arrivi al modello. OpenCode ne invia circa 7.000. Con Claude Fable 5 il divario si stringe (circa 3,3x), perché Claude Code invia un system prompt più corto ai modelli nuovi, ma resta comunque molto più pesante.
Perché ti riguarda. Ogni token di overhead è costo, latenza e spazio sottratto al contesto utile. Se usi agenti in produzione, o se la voce «prompt cache» del dashboard cresce senza che tu capisca perché, questa analisi spiega dove vanno i token. Claude Code riscrive decine di migliaia di token di cache a ogni giro, mentre OpenCode mantiene un prefisso stabile che si paga una volta sola per sessione. Su un compito piccolo eseguito con due subagent, il costo è passato da 121.000 a 513.000 token, perché ogni subagent ripaga il proprio costo di bootstrap e il parent consuma poi l’intera trascrizione.
Una nota di continuità. Come raccontavamo il 12 luglio, Claude Code ha appena ricevuto il browser integrato; questa analisi mostra il costo nascosto di quella potenza in più. Il test non misura la qualità del risultato finale, solo quanto pesa portarsi dietro l’infrastruttura a ogni richiesta.
Nel dettaglio
Il metodo
La misurazione è stata fatta intercettando ogni richiesta fra l’harness e l’API: un proxy di logging cattura il payload JSON completo (system blocks, schemi tool, messaggi) e il blocco usage restituito dall’API (token in input, cache write, cache read, output). Test su Claude Sonnet 4.5, poi ripetuto su Claude Fable 5 per verificare se il modello cambia il quadro.
Condizioni di isolamento: config vuote, nessun MCP server, nessun file di istruzione (AGENTS.md), workspace vuoto, permessi bypassati. Tre task: T1 (“Rispondi esattamente: OK”), T2 (leggere un file e riassumerlo), T3 (ciclo scrivi-esegui-testa-correggi su FizzBuzz). Una variante senza tool per separare il peso del system prompt da quello degli schemi.
I numeri sul tavolo
Sul task minimo (T1), Claude Code parte da 33.000 token prima di leggere il prompt dell’utente. OpenCode da 7.000. Con Fable 5 Claude Code scende attorno ai 10.000-11.000 (Anthropic ha ridotto il system prompt per i modelli nuovi), ma il divario resta 3,3x. Il sistema più leggero resta sempre OpenCode, indipendentemente dal modello.
I moltiplicatori
Questo è il baseline a configurazione vuota. In una repository di produzione, ogni componente aggiunge il suo peso:
- Instruction file (AGENTS.md o CLAUDE.md): un file da 72KB aggiunge circa 20.000 token a ogni richiesta.
- MCP servers: cinque server modesti (calendario, email, filesystem, ricerca, database) aggiungono 5.000-7.000 token di schemi.
- Subagent: un compito che costa 121.000 token fatto direttamente costa 513.000 token quando viene scomposto su due subagent, perché ogni subagent ha il proprio overhead e il parent consuma poi la trascrizione completa.
Con una configurazione reale, il contatore parte da 75.000-85.000 token prima che l’utente abbia digitato una parola.
La cache: dove si gioca la partita
OpenCode mantiene un prefisso di richiesta identico byte per byte in ogni run della stessa sessione: si paga la cache write una volta, poi si legge per pochi centesimi. Claude Code invece riscrive decine di migliaia di token di cache mid-sessione, run dopo run. Su uno dei task del test, Claude Code ha scritto 54 volte più token di cache di OpenCode. I cache write sono tariffati con un premium, e spiegano perché il dashboard cresce anche quando pensi di star riusando il contesto.
Una nota a favore di Claude Code
Su un task multi-step, Claude Code è uscito con un totale inferiore a OpenCode, perché raggruppa le chiamate a tool in un numero minore di richieste, mentre OpenCode ripaga il proprio baseline (più piccolo) a ogni turno. Il metro parte più alto, ma come si svolge la sessione decide chi spende di più alla fine.
Cosa manca
Questo test non misura la qualità del risultato finale: misura solo il costo dell’infrastruttura. Un harness che costa di più può produrre risultati migliori, più velocemente, o con meno necessità di correzione. La domanda giusta è: per il mio caso d’uso, quella potenza in più vale il sovrapprezzo di token?
La fonte completa (Systima) pubblica i dati grezzi e il metodo di misurazione, permettendo a chiunque di riprodurre il test sulla propria configurazione. È il tipo di trasparenza che serve quando devi giustificare una voce di spesa crescente in produzione.