Italiano o inglese con Claude Code? I numeri che non ti aspetti

È una domanda che mi sento fare almeno una volta a settimana, da quando ho cominciato a scrivere su questo blog: "ma se uso Claude Code in italiano, perdo qualcosa?" La risposta breve è "sì, ma forse non quello che pensi". Quella lunga sta in tre paper, due dichiarazioni ufficiali Anthropic, e una sorpresa che cambia il modo in cui dovresti gestire CLAUDE.md e prompt nel tuo workflow.

Le dimensioni in gioco sono due, e vanno tenute distinte: efficienza dei token (quanto costa l'italiano in input/output) e qualità della risposta (l'italiano "perde contesto" rispetto all'inglese?). Si parla sempre solo della seconda, ma è la prima a fare la differenza pratica più grossa.

Vediamo i numeri.

Token efficiency: l'italiano costa il 40-50% in più

Partiamo da quello che si misura facilmente. La tokenizzazione è il processo per cui un LLM spezza il testo in unità (token) prima di processarlo. Tokenizer diversi rappresentano lingue diverse con efficienze diverse.

Il paper di riferimento è Petrov et al. NeurIPS 2023, "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv:2305.15425). Hanno testato 17 tokenizer su decine di lingue. Per il GPT-4 di OpenAI (cl100k_base), il dato per noi rilevante è secco: processare testo italiano costa circa il 50% in più di token rispetto allo stesso testo in inglese.

Un paper più recente, di Moroni et al. della Sapienza, "Optimizing LLMs for Italian: Reducing Token Fertility" (arXiv:2504.17025), ha quantificato la cosa con numeri operativi. Misura "token fertility" — token per parola, dove più basso = più efficiente:

Tokenizer	EN (CulturaX)	IT (CulturaX)	Overhead IT
Mistral-7B-v0.1	1.32	1.88	+42,4%
Llama-3.1-8B	1.15	1.67	+45,2%
Minerva (IT-native)	—	1.39	-26% vs Mistral su IT

Tradotto operativamente: assumi un fattore moltiplicativo di 1.4x-1.5x quando prompti in italiano vs inglese sullo stesso contenuto.

Importante: questo è il costo sul testo naturale, non sul totale

Prima di applicare meccanicamente il "+45%" al costo della tua sessione Claude Code, va detta una cosa che pochi articoli su questo tema esplicitano. Quel +45% si applica al testo naturale italiano vs testo naturale inglese. In un agent loop reale, il context Claude Code è invece un mix:

Componente	% tipico	Sensibile alla lingua?
Codice sorgente	30-50%	NO (token-neutro)
Tool output (JSON, log, stack traces, file paths)	20-30%	NO
System prompt + tool definitions Claude Code	10-15%	NO (inglese fisso)
`CLAUDE.md` di progetto	5-10%	SÌ
Prompt utente + commenti naturali	5-15%	SÌ

Solo l'ultimo 10-25% del context è effettivamente "testo naturale a scelta linguistica". Quindi l'overhead reale di una sessione Claude Code tutta-italiana vs tutta-inglese, su un task tipico, è probabilmente più simile a +8-15% sul totale, non +45%.

Cosa significa per il tuo portafoglio (con i numeri giusti)

Su Sonnet 4.5 ($3 input / $15 output per milione di token), un agent loop reale che chiude un task con 100K token di input + 30K di output costa circa $0.75 in inglese. In italiano, applicando un +12% realistico al totale (non +45%), sale a ~$0.84. Su 50 task al giorno per un team la "tassa linguistica" è dell'ordine di qualche centinaio di euro all'anno, non i $5K di una stima worst-case dove tutto il context è testo naturale.

Resta però vero — e questa è la parte da non liquidare — che il fattore +45% si moltiplica sulle parti che sono effettivamente in italiano: prompt utente, commenti, CLAUDE.md. Su quelle parti specifiche pesi davvero il costo. Se il tuo CLAUDE.md di progetto è 8K token in italiano contro 5.5K in inglese, hai 2.5K token in più caricati a ogni chiamata dell'agent loop. Su trecento chiamate, fanno 750K di token aggiuntivi consumati nel ciclo. Lì il numero conta.

Tradotto: non temere il +45% come moltiplicatore della bolletta totale. Temi (e gestisci) il +45% sui pezzi specifici dove ti pesa, soprattutto i file di istruzione caricati ad ogni step.

Cosa significa per il context window

Lo stesso file PDF, lo stesso CLAUDE.md, la stessa documentazione: in italiano occupa circa il 40-50% in più del context. Su una finestra da 200K token, questo si traduce in circa 140K token "equivalenti inglese" se il content è italiano.

Su task con repository grandi, log estesi, documentazione tecnica caricata in context, può fare la differenza fra entrare o non entrare nel budget.

Il caso Claude Opus 4.7 — peggiora di nuovo

Una nota a margine importante. Simon Willison ha scoperto a metà aprile che Claude Opus 4.7 ha cambiato tokenizer rispetto alla famiglia precedente. Lo stesso testo richiede 1.46x più token su Opus 4.7 rispetto a Opus 4.6. Sopra il range 1.0-1.35x dichiarato da Anthropic.

Non c'è ancora un dato pubblico specifico sull'effetto del nuovo tokenizer Claude su italiano vs inglese, ma la dinamica è chiara: il premium linguistico si moltiplica sopra a un premium di base già aumentato. Tradotto: chi prompta in italiano su Opus 4.7 oggi sta pagando l'overhead linguistico più l'overhead della nuova tokenizzazione. (Ne avevo scritto in dettaglio qui qualche giorno fa.)

Qualità: il numero che sorprende è alto

Adesso veniamo all'altra dimensione, quella su cui si fanno più ipotesi e meno test. "Claude perde contesto se gli parlo in italiano?"

I dati ufficiali di Anthropic sono pubblici, ma vengono citati raramente. Sulla pagina docs.anthropic.com/en/docs/build-with-claude/multilingual-support c'è una tabella di MMLU tradotto da umani, con performance relativa all'inglese (= 100%) per ogni lingua. Per l'italiano:

Modello	Italian relative score
Claude Opus 4.1	97,7%
Claude Sonnet 4.5	97,9%
Claude Sonnet 4	97,3%
Claude Haiku 4.5	96,0%

Tradotto: sul knowledge/reasoning generale, Claude in italiano performa al 97-98% del Claude in inglese. Il gap è di 2-3 punti percentuali. Non è zero, ma è molto meno di quello che molti immaginano.

Per contesto, le altre lingue europee high-resource:

Spagnolo: 96,4-98,2% (leggermente meglio dell'italiano sui modelli top)
Francese: 95,7-97,9% (paragonabile)
Tedesco: 94,3-97,7% (range più ampio, Haiku 4.5 cala a 94,3%)
Cinese (Semplificato): 94,2-97,1%
Yoruba: 52,7-80,3% (low-resource, gap enorme — Haiku 4.5 crolla al 52,7%)

L'italiano è solidamente in fascia "high-resource Class A". Per dare un'idea della distanza: se chiedi a Claude di spiegarti un concetto, scrivere documentazione, fare summary, ragionare su un problema — in italiano ti aspetti di perdere 2-3 punti su 100 di qualità. Non significa che la sentirai sempre. Significa che statisticamente è quello.

Però sul coding il gap è più grande

Qui inizia la parte interessante, ed è dove cambia il gioco rispetto al "97.7%" rassicurante.

Il MMLU misura conoscenza generale e reasoning logico. Il coding specifico è una bestia diversa. Tre dati che mostrano il fenomeno:

GitHub Copilot ha pubblicato in passato dati di "acceptance rate" per lingua del prompt: 30% in inglese, 22% in spagnolo, 18% in cinese. Sono dati industriali, non peer-reviewed, e Copilot non è Claude — ma il trend è coerente con la letteratura. L'italiano non ha numeri pubblici diretti, ma essendo cugino linguistico dello spagnolo si stima realisticamente in fascia 25-28%.
HumanEval-XL (arXiv:2402.16694), il benchmark multilingue di code generation, include l'italiano e mostra gap consistenti rispetto all'inglese su tutti i modelli testati. Il gap aumenta con la complessità del task: più il problema è complesso, più la lingua del prompt incide.
Uno studio della Carnegie Mellon University su un dataset di 80.000 coppie di commenti tradotti (codename CO-RE) ha misurato l'effetto della lingua dei commenti del codice sull'accuratezza dei modelli. Il risultato: commenti in inglese battono commenti in lingua nativa quasi sempre, anche quando il codice resta identico.

C'è una spiegazione plausibile. Il dataset di pre-training di un coding model è pesantemente sbilanciato sull'inglese — Stack Overflow, documentazione tecnica, repository GitHub commits, README, Hacker News. Letteralmente l'80-90% del training material di coding è in inglese. La conoscenza tecnica del modello, anche quando parla italiano, è rappresentata internamente in inglese.

Il che ci porta al terzo dato.

"I LLM pensano in inglese?" — paper Oxford / Google DeepMind

Il paper "Do Multilingual LLMs Think In English?" (arXiv:2502.15603) ha provato a guardare dentro la scatola. La risposta, abbastanza solida nei modelli testati, è: sì, in larga parte.

Findings tecnici:

I modelli multilingue fanno scelte semantiche chiave in uno spazio di rappresentazione più vicino all'inglese, indipendentemente dalla lingua di input/output.
Logit lens (un metodo per "vedere" cosa pensa il modello a metà processing): le parole "semantically loaded" — sostantivi, verbi — appaiono prima in inglese e poi vengono tradotte verso la lingua finale.
Routing inglese: 41-72% a seconda del modello. Più training multilingua = meno routing inglese, ma resta dominante.

Tradotto in pratica: anche quando parli a Claude in italiano, e Claude ti risponde in italiano, una parte significativa del processing interno è in inglese. La traduzione avviene all'ingresso e all'uscita; il "pensiero" sta in mezzo. E quando devi formulare un concetto tecnico complesso che il modello ha visto un milione di volte in inglese e dieci volte in italiano, partire in inglese ti dà accesso più diretto.

Per il coding, dove il "pensiero del modello" è densamente tecnico, questo conta più che per il general reasoning.

Il caso Claude Code — l'agent loop amplifica tutto

Qui aggiungo il pezzo che secondo me è il più sottovalutato della discussione, ed è specifico del modo in cui usiamo Claude Code (e ogni agent moderno).

Claude Code non fa una singola chiamata. Fa decine, centinaia, talvolta migliaia di chiamate dentro un singolo task. Plan, leggi file, esegui tool, valuta output, ripianifica, leggi altro, esegui altro. Ogni step include il tuo prompt iniziale + tutto lo storico + il tool output + la nuova generazione.

Su un agent loop di un'ora reale, il context cumulativo passa facilmente per centinaia di migliaia di token. Su quel volume, un overhead del 40-50% sull'input e sull'output si traduce in costi di compute proporzionali. Il +50% di token sull'inglese che sembrava "$1.10 vs $0.75 per task" diventa, su un team di tre dev che fanno 100 task al giorno per cinque giorni, una differenza di centinaia di dollari a settimana. E in latenza pure — più token = più tempo = pause più lunghe nelle sessioni interattive.

C'è un secondo effetto sottile. In un agent loop, il modello a ogni step usa il context recente per decidere il prossimo step. Se quel context è italiano, il modello sta facendo ad ogni step quel piccolo ma reale routing extra inglese-italiano-inglese descritto sopra. Su una singola chiamata si perde nel rumore. Su trecento chiamate, gli errori si accumulano.

Cognitive efficiency: il rovescio del costo che pochi nominano

Fin qui ho parlato del costo dei token, che è il dato più facile da misurare. Ma c'è un fattore opposto e altrettanto reale, e bisogna tenerlo sul tavolo per onestà: la lingua in cui pensi influenza la qualità del prompt che scrivi.

Se sei un dev italiano fluente professionale ma non bilingue C2, e ti forzi a promptare in inglese, succede questo:

Traduci mentalmente, e nella traduzione perdi sfumature di dominio
Usi terminologia tecnica generica perché non sai dire in modo elegante in inglese cose che in italiano formuleresti con tre parole
Eviti costruzioni complesse perché in inglese ti suonano insicure, e finisci con prompt più piatti
Il modello capisce al 70-80% e ti chiede chiarimenti, oppure ti dà un output che non centra esattamente
Iteri due-tre volte. Ogni iterazione è un'altra chiamata. Costa.

Lo stesso prompt in italiano fluente ti costa il +45% sul testo, sì — ma se chiude il task in una iterazione invece che in tre, il costo totale della task in italiano è inferiore al costo totale in inglese mediocre. 1.45x un'iterazione batte 1.0x tre iterazioni.

Non c'è un paper accademico definitivo su questo punto specifico (e non lo invento), ma la dinamica è coerente con tutta la letteratura su prompt clarity → output quality. Inoltre c'è un effetto cognitivo a monte: pensare in italiano ti fa pianificare meglio un task complesso. Sbagliare la pianificazione perché in inglese ti sfugge una sfumatura tecnica che in italiano coglieresti subito ti costa intere catene di chiamate. Quel costo non lo recuperi col -45% sulla singola chiamata.

Quando vince l'inglese, allora? Quando sei davvero a tuo agio nella tecnica scritta in inglese, oppure quando il task è in un dominio dove il modello "vive in inglese" così tanto (libreria specifica, framework di nicchia, edge case poco documentato) che ogni dettaglio della formulazione conta. In quei casi l'inglese paga sia in efficienza token sia in qualità di matching col training data.

Per la maggior parte dei dev italiani, il punto vero è: prompt italiano fluente >> prompt inglese mediocre, anche pagando il token tax. Prompt inglese fluente >> prompt italiano fluente, sui task tecnici densi, ma vale solo se l'inglese è davvero fluente.

La strategia ibrida che secondo me ha senso

Detto tutto questo — e tenendo presente che il gap di qualità è del 2-3% sul reasoning generale e qualcosa di più sul coding — la strategia che adotto, e che ha senso per la maggior parte dei dev italiani, è ibrida. Non binaria.

In inglese vanno:

CLAUDE.md delle istruzioni tecniche (architettura, naming convention, librerie, pattern, lint rules). Il modello le processa meglio in inglese, e le riusa a ogni step dell'agent loop. È il pezzo dove l'efficienza paga di più.
Commenti del codice che riguardano logica tecnica. "// returns the user's score after applying the discount". Più chiaro al modello, e più interoperabile con qualunque membro internazionale del team.
Prompt di task tecnici complessi ("rifattorizza la classe X usando il pattern Y"). Soprattutto se il task tocca librerie, framework, concetti tecnici dove l'inglese è la lingua dominante della documentazione.

In italiano vanno:

Domain context: la richiesta del cliente, le user story, il vocabolario di business. "Il cliente vuole che l'utente possa annullare il bonifico entro 24 ore". Tradurre questo in inglese sterilizzerebbe sfumature semantiche e perderebbe terminologia legale italiana che il cliente userà di sicuro.
Output finale al lettore italiano: documenti per il cliente, email, comunicazioni. Ovviamente.
Conversazione di pair programming informale: quando stai pensando ad alta voce con Claude, spiegando un'intuizione vaga, raccontando il problema. Lì il pensiero in italiano è più ricco del pensiero in inglese forzato.

In tutte e due:

Se hai un team misto Italia + estero, scegli inglese come default e tieni l'italiano per il dominio specifico. È più robusto a lungo termine.
Se sei singolo dev italiano: prova a tradurre i tuoi CLAUDE.md tecnici e vedi se la velocità migliora. Probabilmente sì.

Tre test pratici che puoi fare oggi

Per non lasciarci nelle ipotesi, tre test concreti:

Conta i token: prendi un tuo CLAUDE.md italiano e contalo con tiktoken (Python) o con il Claude token counting endpoint ufficiale. Poi prendi la versione inglese (o falla tradurre). Confronta. Se vedi 1.4x-1.5x, sei nella media.
Translation tax test: prendi un task non banale (refactor, bug fix complesso, design di una piccola feature) e fallo due volte, una volta in italiano e una volta in inglese, partendo dallo stesso codice. Cronometra. Confronta i token consumati. Confronta la qualità dell'output. Replica un paio di volte. Se la differenza non è significativa per te, vai in italiano. Se vedi cose tipo che in inglese ti suggerisce librerie più moderne o pattern più puliti, hai trovato il tuo "translation tax".
Mixed-language CLAUDE.md: prova a tenere il tuo CLAUDE.md per metà in inglese (sezioni tecniche) e metà in italiano (sezioni di dominio/business). Vedi se il modello reagisce meglio o peggio. Per quel che ho testato io, reagisce meglio — ma è aneddotico, non è uno studio.

In chiusura

L'italiano con Claude (e con LLM in generale) non è una scelta sbagliata. Anthropic stesso ti dice che la qualità è al 97-98%. Il punto non è "usa l'inglese sempre", il punto è capire quanto stai pagando, dove, e perché.

Riassumendo i numeri di questo articolo:

+40-50% di token in italiano vs inglese, dato robusto su multipli tokenizer.
2-3 punti di MMLU persi in italiano vs inglese, dato Anthropic ufficiale.
Gap maggiore sul coding specifico, dato HumanEval-XL e industriali Copilot.
41-72% routing inglese interno dei modelli multilingua, dato Oxford/Google DeepMind.
Effetto cumulativo amplificato in agent loop come Claude Code.

E un'unica regola pratica: mescola consapevolmente. Inglese dove conta l'efficienza tecnica e la fluenza del modello sul dominio (CLAUDE.md tecnici, commenti, prompt di refactor). Italiano dove conta la fedeltà al dominio di business e al tuo modo di pensare (domain context, conversazione informale, output utente). Non è una scelta ideologica. È un'allocazione di risorse.

E se ti era venuto il dubbio leggendo questo articolo che starei meglio se scrivessi in inglese — be', no. Per parlare a un dev italiano dell'italiano, l'italiano è la scelta giusta. Anche se mi è costato il 45% in più di token a Claude per buttarlo giù in coautorato.

Fonti: