L'inflazione silenziosa dei token.

Simon Willison, in un breve intervento del 20 aprile 2026, segnala un fatto che la maggior parte dei team che usano Claude in produzione non ha ancora misurato: il nuovo tokenizzatore di Opus 4.7 conta lo stesso testo in modo diverso. Misurazioni alla mano, lo stesso prompt di sistema passa da cinquemila a settemila token. A parità di prezzo per token, è un aumento operativo del quaranta per cento, mascherato da aggiornamento di modello.

Il dato, in breve

Anthropic ha annunciato che il nuovo tokenizzatore introduce un moltiplicatore compreso tra 1.0 e 1.35 a seconda del tipo di contenuto. Le verifiche di Willison, condotte con uno strumento pubblico che mette a confronto i modelli sullo stesso input, restituiscono un'osservazione meno rassicurante: su un prompt di sistema reale, il moltiplicatore è risultato 1.46. I PDF densi di testo si comportano meglio, intorno a 1.08. Le immagini ad alta risoluzione esplodono, ma in quel caso il consumo aggiuntivo è giustificato da una maggiore capacità di analisi. La conclusione pratica è semplice e spiacevole: aggiornare a Opus 4.7 senza ricalibrare i prompt significa pagare una bolletta più cara per lo stesso risultato.

Un esempio aritmetico per capire l'ordine di grandezza. Un agente di qualifica lead inbound, ben strumentato, fa girare circa 30.000 chiamate al mese, con un prompt di sistema medio di 4.500 token sul vecchio tokenizzatore. Il costo input mensile su Opus 4.7 al listino corrente è grossomodo: 30.000 chiamate × 4.500 token × prezzo input per milione di token. Aggiornando al nuovo tokenizzatore, lo stesso prompt vale 6.300 token (moltiplicatore 1.4 medio sul testo italiano). Stesso esito funzionale, stesso prezzo di listino, ma costo input mensile salito del quaranta per cento. Su scala annuale, alcune migliaia di euro che spariscono dal margine senza che nessuno abbia firmato un aumento.

Perché conta più di quanto sembri

Il prezzo per milione di token è rimasto invariato. Questo è il dettaglio intelligente. La narrativa pubblica resta "stesso costo, modello migliore", ma il costo reale per richiesta sale, perché la stessa frase produce più token. Per chi gira un agente in produzione su volumi seri — outreach, classificazione, estrazione, supporto — il margine si erode senza che nessun listino cambi. È un'inflazione silenziosa: non la vedi nel preventivo, la vedi nella fattura mensile due cicli dopo.

Il secondo strato del problema è meno tecnico e più organizzativo. La maggior parte delle aziende che hanno adottato Claude negli ultimi dodici mesi non ha una funzione interna che monitora il costo per richiesta, il numero medio di token per chiamata, o la deriva mensile di queste metriche. Quando un fornitore cambia tokenizzatore, queste aziende lo scoprono dal commercialista, non dai log. È la stessa incoscienza con cui si firmavano contratti cloud nel 2018, moltiplicata per la velocità con cui i modelli si aggiornano oggi.

I tre tipi di prompt più colpiti

Non tutti i prompt soffrono allo stesso modo. Avendo audit-ato decine di stack negli ultimi mesi, vediamo emergere tre categorie chiare di prompt che pagano di più il cambio di tokenizzatore.

1 · Prompt di sistema lunghi e ridondanti. Tipici degli agenti scritti da poco o ereditati: tre paragrafi di "tu sei un assistente professionale che…", quattro esempi few-shot non più necessari ora che i modelli sono più capaci, una lista di vincoli ripetuta in tre forme diverse. Sono i prompt che si gonfiano per inerzia, non per necessità. Il moltiplicatore qui è il peggiore — intorno a 1.4-1.5 — perché il testo didascalico contiene molte parole comuni con tokenizzazione meno efficiente della media.

2 · Documenti in italiano densi di terminologia di settore. Manuali tecnici, contratti, documentazione clinica, normative. La terminologia di settore (radici latine lunghe, sigle, nomi propri tecnici) si segmenta in più token rispetto alle parole comuni. Tipicamente moltiplicatore 1.25-1.35.

3 · Conversazioni multi-turn lunghe. Ogni turno aggiunge contesto. Se il tokenizzatore conta ogni messaggio leggermente più del precedente, l'effetto si compone. Una conversazione che a turno 1 costava X a turno 12 costa 1.4X solo per via dell'accumulo, prima ancora che la nuova risposta sia generata. Per agenti che mantengono memoria conversazionale estesa, è la situazione peggiore.

I prompt al sicuro, invece, sono quelli brevi e diretti su PDF densi di testo, dove il moltiplicatore resta vicino a 1.05-1.08. Spesso sono i task di estrazione strutturata da documenti già tokenizzati efficientemente.

Caso reale anonimizzato · prima e dopo

Un agente di outreach in produzione presso uno dei nostri clienti, attivo da sette mesi su Opus 4.6, generava email personalizzate a partire da un prompt di sistema di 5.200 token (descrizione del cliente target, regole di voce, esempi few-shot, vincoli legali su quello che l'agente può promettere). Su volume di 18.000 email/mese, costo input mensile circa cinquecentotrentadue euro.

Aggiornamento a Opus 4.7 senza ricalibrazione: stesso prompt, stesso volume, costo input mensile salito a settecentoquarantacinque euro. Il cliente l'ha visto solo dopo due cicli di fatturazione, su grafici settimanali che il fornitore non aveva mai mostrato. Differenza annua estesa: oltre duemilacinquecento euro su un singolo agente, su un cliente di taglia media.

Cosa abbiamo fatto in mezza giornata di lavoro. Letto il prompt di sistema riga per riga. Tagliati due paragrafi di istruzioni didascaliche ridondanti (l'agente non era nuovo, non aveva bisogno di essere "ricordato"). Rimossi tre esempi few-shot su quattro (Opus 4.7 non li richiede più per la stessa qualità). Compattate le regole di voce da sei frasi a due. Prompt finale: 2.900 token contro i 5.200 originali. Costo mensile sceso a quattrocentodiciotto euro, sotto al baseline precedente all'aggiornamento. Stessa qualità di output, misurata su un campione di cento email confrontate a doppio cieco.

Morale operativa: un aggiornamento di modello è il momento giusto per rivedere il prompt, non per ignorarlo. La maggior parte dei prompt in produzione è gonfia per ragioni storiche che il nuovo modello rende obsolete.

L'inflazione invisibile non è solo Anthropic

Sarebbe consolatorio se questo fosse un problema specifico di un singolo provider. Non lo è. Lo stesso pattern lo abbiamo visto su transizioni storiche di OpenAI (cambi di tokenizzatore fra major version) e di Google (modifica della finestra di contesto effettiva su Gemini 3). Ogni provider, ogni due-quattro release, aggiusta qualcosa che muove il consumo senza muovere il listino. La narrativa pubblica resta sempre "stesso prezzo, modello migliore". Il costo reale per il task si muove per un fattore diverso da zero.

Per chi gira un sistema multi-provider — il pattern operativo Jigen — la conseguenza è doppia. Da un lato l'inflazione token può colpire qualunque componente. Dall'altro, esiste sempre un'opzione di re-routing: se Opus si inflaziona del quaranta per cento su un task, e Sonnet 4.6 fa lo stesso task a un costo che, anche col suo moltiplicatore, resta inferiore, il flusso si sposta. Per chi è legato a un singolo provider, questa via di fuga semplicemente non esiste — paga l'inflazione e basta.

La posizione di Jigen

Ogni progetto che entra nei nostri ventuno giorni viene strumentato, dalla prima settimana, con tre numeri obbligatori: token medi per richiesta, costo per esito utile, e percentuale di chiamate in cui il prompt di sistema pesa più del messaggio dell'utente. Sono metriche banali, eppure la maggior parte degli stack visti in audit non le tiene. Si guarda al risultato, non al consumo. È esattamente l'errore che rende fragili gli agenti AI in produzione: funzionano finché non aggiorni il modello, poi smettono di funzionare a margine accettabile.

L'aggiornamento di Opus 4.7 è un buon esercizio di disciplina. Chi tiene i propri prompt sotto controllo di versione, con log dei token per chiamata, può rispondere all'aumento in due modi: ricalibrare il prompt di sistema — spesso gonfiato per abitudine, non per necessità — o cambiare modello sulla parte del flusso che non richiede Opus. Chi non tiene nulla sotto controllo paga il quaranta per cento e attende il prossimo aggiornamento.

Come ricalibrare un prompt di sistema in 30 minuti

Una procedura pratica per chi vuole agire subito sul proprio stack. Funziona indipendentemente dal provider — è applicabile a OpenAI, Anthropic, Google nello stesso modo.

Minuti 0-5 · misura il baseline. Conta i token del prompt di sistema attuale sul tokenizzatore del modello corrente. La maggior parte dei provider espone un endpoint o un tool pubblico. Annota il numero. È il tuo punto di partenza.

Minuti 5-15 · taglia il didascalismo. Cerca queste tre pattern e cancellale senza pietà: (a) frasi che spiegano al modello cosa è ("tu sei un assistente"), (b) ripetizioni in forme diverse dello stesso vincolo, (c) esempi few-shot pre-2025 che il modello attuale non richiede più per la stessa qualità. Tipicamente, su un prompt di 5.000 token, si tagliano fra 1.500 e 2.500 token senza alcuna perdita misurabile di qualità.

Minuti 15-22 · sostituisci parole comuni con parole dense. Il tokenizzatore conta meno token su parole comuni e di radice tecnica standard. "Per favore, valuta con attenzione" diventa "valuta". "Il sistema deve assicurarsi di" diventa "assicurati di". Sono dieci o quindici sostituzioni che, su un prompt di sistema, valgono ulteriori 200-400 token.

Minuti 22-28 · valida l'output. Fai girare il prompt accorciato su un campione di trenta-cinquanta input reali. Confronta gli output con quelli del prompt originale. Se la qualità è identica (definizione operativa: il revisore umano non sa distinguere quale è quale), il prompt accorciato passa in produzione. Se peggiora, ripristina i pezzi necessari uno alla volta.

Minuti 28-30 · committa, logga, monitora. Il nuovo prompt viene versionato in repository, con commit message che dichiara il delta in token. Una dashboard interna registra il consumo per chiamata prima e dopo. Il risparmio diventa misurabile la prima settimana.

Trenta minuti. Spesso il risparmio supera il valore di mezza giornata di lavoro entro il primo mese.

Test rapido · sei al sicuro dall'inflazione token?

Una griglia diagnostica per il vertice di un'azienda che vuole sapere se il proprio agente AI è amministrato bene. Cinque domande:

1. Sai, oggi, quanti token in media consuma il tuo agente per richiesta? Risposta sana: una cifra precisa (es. "4.500 token medi in input, 350 in output"). Risposta sospetta: "non sappiamo, dipende".
2. Quando il provider aggiorna il modello, qualcuno misura il consumo prima e dopo? Sana: sì, sempre, con report scritto. Sospetta: "guardiamo se funziona ancora bene".
3. Il prompt di sistema è sotto controllo di versione (git o equivalente)? Sana: sì, ogni modifica ha un commit. Sospetta: "vive in un campo di configurazione che modifichiamo a runtime".
4. Esiste un grafico settimanale del costo per richiesta? Sana: dashboard interna o report del fornitore. Sospetta: "lo vedi nel consuntivo mensile".
5. Avete identificato il flusso più costoso del vostro stack e sapete perché? Sana: sì, è X, costa Y, perché Z. Sospetta: "tutti i flussi sono simili".

Tre sì su cinque: stai gestendo bene. Due o meno: c'è inflazione che ti sta erodendo margine senza che tu lo sappia. La prima settimana per misurare, la seconda per ricalibrare, la terza per stabilizzare. Tre settimane — coincidenza — del ciclo Jigen.

L'implicazione per chi guida

Per un CEO o un fondatore che sta integrando AI in produzione, il punto non è capire come funziona un tokenizzatore. È pretendere che il proprio team operativo, interno o esterno, mostri tre cose entro il prossimo lunedì: il grafico del costo per richiesta nelle ultime quattro settimane, la lista dei prompt di sistema attivi con il loro peso in token, e l'identificazione del flusso più costoso oggi. Se questi tre output non esistono, il problema non è Anthropic. Il problema è che si sta spendendo un budget AI senza contabilità.

Il consiglio operativo è specifico. Non aggiornate i modelli in produzione senza una misura prima e dopo. Non assumete che il prezzo per token coincida con il prezzo per richiesta. Tenete uno strumento di conteggio — quello pubblico di Willison è un buon punto di partenza — agganciato al prompt di sistema più trafficato, e fatelo girare ogni volta che un modello cambia versione. È un investimento di mezza giornata di lavoro che protegge decimali di margine sui dodici mesi successivi.

Il dato di Willison è piccolo, ma indicativo. L'AI in azienda non si gestisce con la stessa logica del software tradizionale, dove un aggiornamento minore è gratuito per definizione. Qui ogni release del fornitore è una negoziazione di costo. Chi lo capisce per tempo, paga ciò che vede. Gli altri scoprono il conto a esercizio chiuso.

Spunto: Simon Willison, "Claude Token Counter, now with model comparisons", simonwillison.net, 20 aprile 2026 — leggi l'originale ↗. Strumento collegato: claude-token-counter ↗. Lettura Jigen: l'osservazione di Willison non è un caso isolato — è il segnale di una dinamica che ogni provider AI ripete ogni due-quattro release. La risposta operativa non è demonizzare un fornitore, è strumentare lo stack: token medi per chiamata, costo per esito utile, controllo versionato dei prompt, dashboard settimanale. Chi non lo fa firma un assegno in bianco al prossimo aggiornamento. Multi-provider e prompt sotto controllo sono le due leve che neutralizzano l'inflazione silenziosa.