Opus 4.7: Il Tokenizer Nascosto che Ti Costa il 46% in Più
Stesso prezzo. Stesso input. Ma il nuovo tokenizer produce fino al 46% di token in più su system prompt, +201% su immagini. Le misure di Simon Willison.
Alessandro Saiani
Human in the Loop
Il pricing non è cambiato. $5 per milione di token in input, $25 in output. Identico a Opus 4.6. Eppure la tua prossima fattura Anthropic potrebbe essere più salata del 46%. Non perché hai mandato più richieste. Non perché hai aumentato il contesto. Perché il tokenizer "nuovo e migliorato" di Opus 4.7 conta diversamente lo stesso identico testo.
Lo ha misurato Simon Willison, pubblicando ieri i numeri reali su un campione di chiamate API. Anthropic aveva dichiarato un range di 1.0x-1.35x. I numeri sul campo raccontano un'altra storia: 1.46x sui system prompt, fino a 3.01x sulle immagini ad alta risoluzione. È un aumento silenzioso di costi che non appare in nessun changelog.
Nel nostro articolo del 16 aprile avevamo segnalato il problema, usando il range ufficiale. Oggi sappiamo che quel range era ottimista.
Cosa ha Misurato Willison
Simon Willison — uno dei più rigorosi cronisti dell'ecosistema LLM — ha pubblicato il 20 aprile un confronto diretto tra Opus 4.6 e Opus 4.7 usando l'endpoint ufficiale count_tokens di Anthropic.
Il metodo è semplice e ripetibile. Prendi lo stesso identico payload, lo mandi al tokenizer di 4.6 e poi a quello di 4.7, confronti i numeri. Niente benchmark costruiti, niente prompt ingegnerizzati: un system prompt reale, un PDF di 30 pagine, due immagini. Il tipo di input che chiunque usi l'API per agenti o RAG processa ogni giorno.
I risultati sono a disposizione di chiunque voglia replicare l'esperimento. E il dato aggregato è netto: il nuovo tokenizer non è "occasionalmente più verboso". È sistematicamente più verboso, con picchi drammatici su contenuti strutturati.
I Numeri Esatti
| Input | Opus 4.6 | Opus 4.7 | Delta |
|---|---|---|---|
| System prompt (realistico) | 5.039 token | 7.335 token | +46% |
| PDF 15MB, 30 pagine | 56.482 | 60.934 | +8% |
| Immagine standard (682x318) | 310 | 314 | +1% |
| Immagine alta risoluzione (3456x2234) | 1.578 | 4.744 | +201% |
Il dato sul system prompt è quello che fa più male a chi gestisce agenti in produzione. Un system prompt è per definizione qualcosa che viene rispedito ad ogni chiamata. Se un agente fa 10.000 chiamate al giorno con lo stesso system prompt da 5.000 token, con Opus 4.6 pagavi per 50 milioni di token di preamble giornaliero. Con Opus 4.7, ne paghi 73 milioni. Stesso prompt. Stessa logica. Stesso output atteso.
A $5 per milione, la differenza è circa $115 al giorno — più di $40.000 all'anno — per un workload non enorme. Moltiplicato per chi gira migliaia di agenti in parallelo, il numero scala rapidamente.
Il Caso Peggiore: +201% sulle Immagini High-Res
Ricordate il grande annuncio di Opus 4.7? Tre volte la risoluzione delle immagini supportate, da 1.25 a 3.75 megapixel. Il salto da 54.5% a 98.5% su XBOW visual-acuity. Il motivo per cui molti stavano pianificando di migrare.
Bene. Quella capacità di vedere più pixel ha un prezzo che Anthropic non ha sottolineato. Un'immagine a 3456x2234 pixel — esattamente il tipo di screenshot che ora puoi finalmente passare senza comprimere — costa 3.01 volte i token che costava prima.
In pratica: la feature principale del rilascio è anche la più cara da usare. Se il tuo workflow processa screenshot ad alta risoluzione per visual reasoning (automazione UI, analisi di mockup Figma, penetration testing visivo), il costo per richiesta triplica. Non del 35%. Del 201%.
Il paradosso è che su immagini piccole — 682x318, il formato che useresti per un'icona o una miniatura — la differenza è impercettibile. Il nuovo tokenizer non è uniformemente peggiore. È selettivamente più costoso proprio dove l'upgrade promette di brillare.
La Discrepanza con Quanto Dichiarato
Anthropic aveva scritto, nel post di lancio, che il nuovo tokenizer produce tra 1.0x e 1.35x token rispetto al precedente. Un range onesto, se fosse vero.
I numeri di Willison mostrano una realtà diversa:
- Testo strutturato (system prompt): fino a 1.46x — oltre il massimo dichiarato
- Immagini high-res: fino a 3.01x — più del doppio del massimo dichiarato
- PDF: 1.08x — dentro il range
- Immagini piccole: 1.01x — dentro il range
Il range 1.0-1.35x non è falso, è incompleto. Funziona per certi input, non per altri. E i "certi altri" sono proprio quelli che chi usa Opus in produzione processa di più: system prompt lunghi e immagini ad alta risoluzione.
È probabile che Anthropic abbia calcolato il range su una media pesata del proprio traffico interno. Il problema è che la distribuzione di input dei clienti non è quella di Anthropic. Chi costruisce agenti con system prompt dettagliati o chi fa visual reasoning su screenshot pieni paga un tributo sproporzionato.
La Reazione della Community
Il thread su Hacker News ha superato i 600 punti in meno di 24 ore. Il sentiment dominante non è rabbia — è disillusione con un pizzico di cinismo.
"Opus 4.7 feels like the pre-nerf version of 4.6 dressed up as a new model, with a tokenizer change functioning as a stealth price increase" — è il commento più votato, e cattura bene l'umore. L'ipotesi (non dimostrata, ma circolante) è che Anthropic abbia gradualmente ridotto le capacità di 4.6 nei mesi precedenti al lancio di 4.7 per rendere l'upgrade più appetibile, aggiungendo il cambio di tokenizer come aumento nascosto di prezzo.
Non ci sono prove dirette di una "nerf" deliberata su 4.6. Ma la percezione conta: diversi utenti in thread separati avevano segnalato un peggioramento di 4.6 nelle settimane di marzo. Correlazione non è causalità. Ma è abbastanza per alimentare il sospetto che il "pricing invariato" sia stato un messaggio di marketing, non un impegno reale.
Altri commentatori più pragmatici notano una verità scomoda: finché i competitor non offrono la stessa combinazione di capacità, la leva contrattuale è dalla parte di Anthropic. Puoi lamentarti del +46%, ma se Opus 4.7 ti risolve problemi che GPT-5 e Gemini non risolvono, paghi.
Dalla discussione e dalla migration guide ufficiale emergono tre consigli tecnici specifici per tenere sotto controllo il conto su 4.7.
Rimuovi lo scaffolding ridondante. Se i tuoi prompt contengono istruzioni tipo "controlla due volte il layout", "forniscimi un progress update", "chiedimi prima di procedere" — Anthropic raccomanda esplicitamente di rimuoverle. Opus 4.7 fa queste cose da solo, e quelle righe in più nel system prompt vengono tokenizzate al 46% in più di prima. Paghi un comportamento che adesso è gratis.
Parti da high, non da xhigh. Claude Code mette xhigh come default, ma è pensato per task agentici complessi dove il ragionamento profondo paga. Per prompt one-shot, query RAG, classificazioni o task brevi, xhigh brucia token senza migliorare il risultato in modo percettibile. La migration guide è esplicita: per workload non agentici, parti da high.
Disabilita il 1M context su Claude Code. Se usi Claude Code, il 1M di context è attivo di default e ti incoraggia a riempirlo senza pensare. Puoi disabilitarlo aggiungendo al tuo settings.json:
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}
In questo modo la sessione torna a 200K di context, che è più che sufficiente per la maggior parte dei task di coding. Meno context = meno tentazione di allegare l'intero repository, meno token fatturati, meno degradazione da context rot. Se per un task specifico ti serve il 1M, puoi sempre riabilitarlo temporaneamente. Ma tenerlo acceso sempre è uno dei modi più veloci per vedere la fattura lievitare senza che nulla nel tuo codice sia cambiato.
Cosa Fare se Usi Opus 4.7 in Produzione
Tre mosse concrete, in ordine di priorità.
1. Misura, non fidarti. Prendi i tuoi 5 prompt più frequenti e passali all'endpoint count_tokens prima con claude-opus-4-6 e poi con claude-opus-4-7. Se il delta medio sul tuo traffico reale è sotto il 15%, il costo extra è gestibile. Se è sopra il 30%, devi decidere consapevolmente se il salto di qualità vale il salto di costo. Non estrapolare dai numeri di Willison: il tuo mix potrebbe essere diverso.
2. Comprimi il contesto che si ripete. Il +46% colpisce soprattutto i preamble lunghi. Se chiami direttamente l'API, rivedi il system prompt. Se usi Claude Code, rivedi il CLAUDE.md — quel file finisce nel contesto ad ogni sessione e ogni token di troppo viene moltiplicato per il numero di chiamate. Quello che hai ereditato mesi fa da iterazioni passate probabilmente non serve più.
3. Ridimensiona le immagini consapevolmente. Se il tuo workflow accetta immagini dagli utenti, considera un preprocessing che normalizzi la risoluzione al minimo necessario per il task. La capacità di processare 3.75 megapixel non significa che devi usarla sempre. Per la maggior parte dei casi d'uso, 1.25 megapixel restano sufficienti — e costano 3 volte meno.
Il 1M di Contesto Ti Fa Tirare Dritto
C'è un effetto comportamentale che amplifica il problema. Con 1 milione di token di context window a disposizione, la tentazione naturale è smettere di pensare al contesto come risorsa scarsa. Carichi tutto il repository, alleghi tutta la documentazione, passi l'intera conversazione precedente. Tanto "c'è posto".
Solo che adesso "c'è posto" costa di più. Quel file da 50.000 token che prima pagavi una certa cifra, con Opus 4.7 ti costa il 46% in più se è testo strutturato. Moltiplicato per chiamate che si ripetono in una sessione agentica, il delta non è più un dettaglio contabile — è una voce di budget.
Il 1M di context è una feature potente. Ma trattarla come un buffet illimitato è esattamente il comportamento che il nuovo tokenizer penalizza di più. Chi era già disciplinato sul contesto (RAG selettivo, compression, retrieval mirato) paga meno. Chi "tira dritto" perché tanto c'è spazio scopre il costo alla fattura successiva.
Il punto non è demonizzare Anthropic. Opus 4.7 è genuinamente migliorato su benchmark, su vision, su tool use. È un upgrade reale. Ma "stesso prezzo" e "stesso costo" non sono la stessa cosa quando il tokenizer cambia sotto il cofano. Chi paga la fattura a fine mese sa la differenza. Chi pianifica budget annuali deve ricalibrare le proiezioni oggi, non a giugno quando il delta accumulato avrà già bruciato il margine di errore.
Se c'è una lezione, è che i cambi di tokenizer vanno trattati come cambi di pricing a tutti gli effetti. E che le scaling laws funzionano anche al contrario: un modello può migliorare in efficienza di compute e peggiorare in efficienza di fatturazione. Sono due assi indipendenti, e il vendor sceglie quale ottimizzare.
Fonti: