Questo post é stato letto 100 volte!
Un recente studio indipendente ha messo a confronto le performance di Claude Code e OpenCode, entrambi collegati al modello Claude Sonnet 4.5, rivelando un aspetto cruciale riguardo al loro consumo di token.
I risultati indicano che Claude Code mostra un consumo token elevato, utilizzando fino a 32.800 token prima ancora di elaborare il prompt dell’utente, un dato significativamente superiore ai 6.900 token registrati da OpenCode per lo stesso task.
Differenze strutturali e impatto sui consumi
La marcata differenza nei consumi è attribuibile principalmente al “corredo” di sistema che ogni “harness” porta con sé.
Claude Code, infatti, carica un “system prompt” di 27.344 caratteri, suddiviso in tre blocchi, a cui si aggiungono le definizioni di 27 strumenti che da sole pesano quasi 100.000 caratteri.
OpenCode, al contrario, si limita a un singolo blocco di 9.324 caratteri e dieci strumenti essenziali, per un totale di soli 20.856 caratteri di schemi.
Il divario persiste anche senza strumenti
Anche eliminando gli strumenti, il divario nel consumo di token rimane considerevole.
Con zero tool attivi, il “system prompt” di Claude Code pesa circa 6.500 token, più del triplo rispetto ai 2.000 di OpenCode.
Questa differenza è dovuta alla “dottrina comportamentale” di Claude Code, che include regole di tono, istruzioni di sicurezza e una gestione più complessa dei task.
Complessità dei task e gestione della cache
Nei task più articolati, il quadro si complica ulteriormente.
In una prova di scrittura, esecuzione e correzione di codice, Claude Code ha completato il lavoro in sole 3 richieste, raggruppando le chiamate agli strumenti in un unico blocco parallelo.
OpenCode, invece, ha impiegato 9 richieste, procedendo sequenzialmente.
Nonostante ciò, il totale dei token si è quasi pareggiato (121.000 per Claude Code contro 132.000 per OpenCode).
Tuttavia, ripetendo lo stesso test su Claude Fable 5, Claude Code ha registrato un aumento a 298.000 token, contro i 133.000 di OpenCode, a causa di una riscrittura della cache di 85.686 token a metà sessione.
L’impatto dei sottoagenti e della cache instabile
L’uso di sottoagenti amplifica notevolmente il consumo di Claude Code.
Delegando lo stesso lavoro a due sottoagenti paralleli, il consumo è passato da 121.000 a 513.000 token, un moltiplicatore di 4,2 volte.
Questo accade perché ogni sottoagente ricarica il proprio “system prompt” e i propri strumenti a ogni turno.
I sottoagenti di OpenCode, invece, presentano un profilo più leggero, con un prompt di sistema di soli 1.379 caratteri contro i 3.554 di Claude Code.
Un’altra criticità emerge nella gestione della cache dei prompt.
Mentre OpenCode mantiene un prefisso identico “byte per byte” in ogni sessione, scrivendo la cache una sola volta, Claude Code riscrive la cache più volte durante il lavoro, arrivando fino a 54 volte i token di scrittura del rivale nello stesso task.
Lo studio attribuisce questo fenomeno a tre distinte classi di richieste generate da Claude Code, ciascuna con il proprio prefisso di cache.
Costi e qualità: una questione di budget
In una configurazione realistica, con un file di istruzioni da 72 KB e alcuni server MCP, Claude Code ha “speso” circa 75.000 token, contro i 90.817 di OpenCode (appesantito da undici server MCP), ma con un moltiplicatore complessivo di circa 12 volte rispetto alla base di OpenCode.
Un “benchmark” di qualità su dieci sessioni ha mostrato risultati equivalenti per entrambi, con 5 prove su 5 superate.
Tuttavia, il costo medio per sessione è stato di 268.000 token per Claude Code contro i 72.000 di OpenCode.
In sintesi, sebbene la qualità del codice prodotto non differisca significativamente, il divario nei consumi è notevole.
Tra le funzioni di orchestrazione avanzate e un consumo quasi quattro volte superiore a parità di risultato, la scelta tra i due “harness” diventa principalmente una questione di budget.
Questo post é stato letto 100 volte!