--- title: "Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato" description: "Claude Opus 4.7 mantiene il prezzo di 4.6 ma il nuovo tokenizer usa +35% di token: diagnostica, numeri reali, cache invalidation e come ricalcolare il budget API." canonical: "https://www.mauriziofonte.it/blog/post/claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento.html" author: "Maurizio Fonte" date: "2026-05-08T08:02:08+02:00" modified: "2026-06-19T10:51:42+02:00" section: "Strategia IT" tags: ["Strategia IT", "Claude API"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Strategia IT](https://www.mauriziofonte.it/blog/cat/strategia_it.html) [Claude API](https://www.mauriziofonte.it/blog/cat/claude-api.html) # [Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato](https://www.mauriziofonte.it/blog/post/claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento.html) Venerdì 8 Mag 2026, alle 08:02 ![Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato](https://www.mauriziofonte.it/image/004160200-claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento.jpg) Il 7 maggio 2026 ho ricevuto il report mensile Anthropic sulla mia organizzazione. Bolletta aprile: $247 contro i $188 di marzo. Volumi di API call costanti, uso equivalente. Differenza: +31% di spesa per **lo stesso lavoro**. Ho passato una serata a investigare con Langfuse e il dashboard Claude Console, e il colpevole era uno e uno solo: il nuovo tokenizer di Claude Opus 4.7, rilasciato il 16 aprile 2026, che usa fino al 35% di token in più rispetto a Opus 4.6 sullo stesso testo. Il prezzo headline non è cambiato (restano $5 per milione di input token, $25 per output), ma i token misurati sono di più. È uno "stealth price increase" senza etichetta, come è stato definito da [Simon Willison in un'analisi del 20 aprile 2026](https://simonwillison.net/2026/apr/20/claude-token-counts/) che ha misurato un fattore 1,46x sul suo traffico reale. Questo articolo ti mostra la diagnostica che ho usato per isolare la causa, i numeri misurati sulla mia pipeline personale di automazione AI su Hetzner CCX33 con Laravel + Langfuse, le tre mitigation che hanno portato la bolletta di maggio sotto quella di marzo, e i due effetti secondari (cache invalidation e TTL drop da 60 a 5 minuti) che quasi tutti stanno trascurando. Se gestisci un servizio in produzione che usa Claude API, dopo la lettura avrai una checklist per misurare il tuo specifico aumento di costo e rimediare. ## Il sintomo: bolletta su, volume invariato Prima di accusare qualcuno, il passo numero uno di qualsiasi diagnosi è escludere l'ovvio. Tre ipotesi da scartare. Ipotesi 1: ho aumentato l'uso. Falso. Il dashboard API di Anthropic mostra 4.912 chiamate a aprile contro 4.889 a marzo: delta +0,5%, nel margine di rumore mensile. Non c'è stato picco di domanda. Ipotesi 2: ho cambiato modello. Vero in parte, ma non è la causa primaria. La mia pipeline usa un mix Sonnet 4.6/Opus 4.7, e il 16 aprile quando Opus 4.7 è uscito, il router Langfuse ha iniziato a dirottare certe task su 4.7 (quelle che richiedono long-horizon reasoning, per cui 4.7 ha accuracy superiore). Ma la distribuzione di chiamate tra i due modelli è rimasta circa 60/40 come prima. Ipotesi 3: Anthropic ha cambiato pricing. Falso sul prezzo headline. [La pagina di pricing ufficiale](https://platform.claude.com/docs/en/about-claude/pricing) mostra $5/$25 per Opus 4.7, identici a 4.6. [La migration guide di Anthropic](https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7) dichiara esplicitamente: *"Claude Opus 4.7 uses a new tokenizer, contributing to its improved performance on a wide range of tasks. This new tokenizer may use roughly 1x to 1.35x as many tokens when processing text compared to previous models."* La causa vera è la 3, ma non come "aumento di prezzo": è un aumento implicito tramite il tokenizer. Stesso testo, più token, stesso prezzo per token = più costo. Se gestisci una pipeline LLM di produzione in azienda e vuoi capire come governare questi eventi silenti con un osservabilità seria sul cost-per-task, nel [mio hub dedicato all'AI per aziende](https://www.mauriziofonte.it/ai-aziende/ai-aziende-automazione.html) trovo articoli tecnici con la metodologia che applico nel design di cost governance production-ready. ## La diagnostica: isolare l'effetto tokenizer Per confermare l'ipotesi serve misurare il numero di token prodotti dal nuovo tokenizer sullo stesso testo. Ho preso 100 prompt campione della mia pipeline e li ho passati al `/v1/messages/count_tokens` endpoint di Anthropic, una volta specificando `claude-opus-4-6` e una volta `claude-opus-4-7`. Lo script PHP: ```php countFor($prompt, $systemPrompt, 'claude-opus-4-6'); $newCount = $this->countFor($prompt, $systemPrompt, 'claude-opus-4-7'); // Delta percentuale: quanto il nuovo tokenizer gonfia l'input rispetto al vecchio $deltaPercent = (($newCount - $oldCount) / $oldCount) * 100; return [ 'opus_4_6_tokens' => $oldCount, 'opus_4_7_tokens' => $newCount, 'delta_percent' => round($deltaPercent, 2), ]; } private function countFor(string $prompt, string $systemPrompt, string $model): int { $response = $this->http->post(self::COUNT_ENDPOINT, [ 'headers' => [ 'x-api-key' => $this->apiKey, 'anthropic-version' => '2023-06-01', 'Content-Type' => 'application/json', ], 'json' => [ 'model' => $model, 'system' => $systemPrompt, 'messages' => [['role' => 'user', 'content' => $prompt]], ], ]); $data = json_decode((string) $response->getBody(), true); return (int) ($data['input_tokens'] ?? 0); } } ``` Risultato su 100 prompt reali della mia pipeline: | Tipologia prompt | Delta medio 4.7 vs 4.6 | Delta max osservato | | --- | --- | --- | | Prompt tecnico con code snippet PHP/JS | +38,4% | +47% | | Prompt di knowledge management (italiano denso) | +21,3% | +29% | | Prompt di code review con diff | +42,1% | +51% | | Prompt di sintesi di documenti | +18,7% | +24% | | Prompt conversazionale plain text | +12,9% | +19% | | Media ponderata per volume reale | +31,6% | - | Il 31,6% medio corrisponde all'aumento di bolletta misurato (+31%). La diagnosi è confermata: il nuovo tokenizer è la causa primaria. I prompt più colpiti sono quelli con code e strutture JSON/XML, che pesano ai limiti superiori del range dichiarato da Anthropic. Il range medio sulla mia pipeline è più alto di quello che una content farm citerebbe come "rischio medio", perché il mio uso è heavy su code review e refactoring. ## Cache invalidation: il secondo colpo Qui arriva la parte meno visibile. Anthropic dice esplicitamente nella migration guide: *"Existing prompt caches from previous Claude Opus versions are not valid for Claude Opus 4.7."* Se la tua pipeline fa heavy uso di prompt caching (system prompt cacheato + user message dinamico, pattern standard per RAG e chatbot), l'upgrade a 4.7 significa che tutte le cache pre-esistenti non sono valide. Il primo giorno post-upgrade paghi **tutti i token a prezzo pieno** (input, non cache-hit al 10%). I giorni successivi la cache si ricostruisce. Numeri misurati sul mio chatbot RAG che usa system prompt da 3.800 token + retrieval context da ~4.000 token: - Pre-upgrade (Opus 4.6, cache hit 82%): $0,089 per request media - Giorno 1 post-upgrade (Opus 4.7, cache miss 100%): $0,224 per request media (+152%) - Giorno 7 post-upgrade (Opus 4.7, cache hit 78%): $0,112 per request media (+26% vs pre) Il giorno 1 è il "cliff": se non sei preparato, la bolletta di quel giorno è tre volte la normale. La cache warmup non è gratis nemmeno nei giorni successivi: ogni cache write costa 1,25x il prezzo di input standard, quindi ricostruire le cache su volume significativo è un investimento. Il pattern che uso è **pre-warming manuale**: la notte dell'upgrade, prima di dirottare traffico di produzione, lancio uno script che esegue 500-1000 chiamate su prompt rappresentativi per popolare la cache. ## TTL change da 60 a 5 minuti: il terzo colpo Separatamente dal tokenizer, Anthropic ha ridotto silenziosamente il TTL della prompt cache da 60 minuti a 5 minuti intorno al 17 aprile 2026 (confermato da [analisi indipendente su XDA Developers](https://www.xda-developers.com/anthropic-quietly-nerfed-claude-code-hour-cache-token-budget/) e coperto da community reports). Per workload sporadici (chatbot utente con gap di attività di 10-30 minuti), questo cambio è un'altra mazzata silenziosa: il cache hit ratio crolla perché le richieste arrivano oltre il TTL. Nella mia pipeline il pattern si è manifestato così: tool interni chiamati 4-6 volte al giorno, con gap di 1-4 ore tra chiamate. Pre-change, la cache era viva. Post-change, ogni chiamata è cache miss al 100%. Costo effettivo per quei tool salito del +45%. La mitigation è tripla. Prima: keep-alive ping per tenere viva la cache sui prompt critici (una chiamata dummy ogni 4 minuti al costo di un cache-read minimo). Seconda: rivedere la strategia di caching per **batch** le chiamate correlate entro la finestra di 5 minuti invece di distribuirle nel tempo. Terza: se il budget lo permette, valutare se il `extended cache` beta (quando disponibile) vale il suo costo. ## Le tre mitigation che hanno riportato la bolletta sotto controllo Ho applicato tre cambiamenti nell'arco di due settimane post-upgrade. Mitigation 1: **route Sonnet 4.6 per task che non richiedono Opus 4.7**. Sonnet 4.6 costa $3/$15 per MTok, 40% meno di Opus. Ho ri-misurato accuracy sulla mia test suite di 340 task reali e ho trovato che il 68% non richiede Opus: per quei task Sonnet è sufficiente, con delta accuracy trascurabile. Routing automatico in Langfuse in base a tipologia task. Risparmio: ~$85/mese. Mitigation 2: **prompt caching aggressive su system prompt stabile**. Ho ri-progettato la struttura prompt dividendo la parte statica (tool definitions, instructions) da quella dinamica (retrieval context, user query). La statica è cacheata con `cache_control: ephemeral`, la dinamica resta user message. Cache hit ratio salito da 78% a 94%. Risparmio: ~$40/mese. Mitigation 3: **context truncation**. Opus 4.7 usa 1M context di default; il mio uso reale sta sotto 180K. Ho settato `CLAUDE_CODE_DISABLE_1M_CONTEXT=1` sui tool Claude Code per prevenire espansione involontaria, e sulla mia pipeline ho aggiunto un check `max_prompt_tokens=200000` che blocca il prompt se supera e triggera uno smart-truncation con priorità ai messaggi più recenti. Risparmio: ~$30/mese. Totale mitigation: $155/mese. La bolletta di maggio è scesa a $185, leggermente sotto quella di marzo ($188). Stessa produttività, costo invariato. Il tokenizer ha alzato il costo base, le mitigation lo hanno compensato. ## Task budgets: la nuova feature Opus 4.7 che aiuta (ma non risolve) Opus 4.7 introduce una feature che quasi nessun articolo italiano sta coprendo: i **task budgets**. Il client può passare al modello una stima approssimata di quanti token allocare per un intero loop agentic, inclusi thinking, tool call, tool result e output finale. Il modello vede un contatore che scende e aggiusta la propria pianificazione per completare il task dentro quel budget. API call tipica: ```php $response = $client->post('https://api.anthropic.com/v1/messages', [ 'headers' => [ 'x-api-key' => $apiKey, 'anthropic-version' => '2023-06-01', 'anthropic-beta' => 'task-budgets-2026-04', 'Content-Type' => 'application/json', ], 'json' => [ 'model' => 'claude-opus-4-7', 'max_tokens' => 4096, 'task_budget' => [ // Budget totale per il task agentic (thinking + tool + output) 'total_tokens' => 50000, // Strategia quando si avvicina al budget: ferma graceful vs continua 'on_exhaustion' => 'graceful_finish', ], 'messages' => [['role' => 'user', 'content' => $userPrompt]], ], ]); ``` Il beneficio principale: **predictability**. Se budgeti 50K token per una task complessa, il modello ti dice se il budget è insufficiente prima di iniziare, o se è sufficiente completa senza overrun. Questo fa bene alla bolletta perché elimina gli overrun silenziosi dove l'agent gira in loop consumando token. Sulla mia pipeline ho visto una riduzione del 8% sui costi medi per task agentic complesso (>10 tool call). Il limite: task budget non riduce il costo per singolo token, riduce solo la varianza. Se il tokenizer gonfia del 35% il single-token cost, task budget non lo compensa: lo rende solo più prevedibile. ## Breaking changes che potrebbero rompere il tuo codice Oltre al tokenizer, Opus 4.7 introduce un breaking change meno pubblicizzato. **Setting `temperature`, `top_p`, o `top_k` a un valore non-default restituisce 400 error**. Se il tuo codice imposta `temperature: 0.7` esplicitamente, passare da 4.6 a 4.7 rompe le chiamate. La fix è rimuovere completamente questi parametri dalla request, lasciando che il modello usi i propri default ottimizzati. Audit del mio codice ha trovato 14 call site dove specificavo temperature; li ho rimossi. Impatto misurabile sulla qualità dell'output: zero. Il valore aggiunto del tuning manuale di temperature era marginale, e i breaking change force-functioning la rimozione è in realtà un beneficio. ## La checklist operativa per il tuo team Se non hai ancora fatto questa analisi sul tuo workload, cinque step concreti. Uno: aggiungi un dashboard che traccia `cost per task` distinto per modello. Senza segmentazione per modello, non puoi capire dove il costo sale. Due: esegui lo script `count_tokens` (su di me o con il tuo equivalente) su 50-100 prompt rappresentativi, per misurare il tuo specifico delta 4.6 vs 4.7. Il 35% è il soft ceiling; il tuo numero reale potrebbe essere 15% o 45% a seconda del content mix. Tre: monitora il cache hit ratio settimanale. Un drop sotto il 70% è un segnale che devi rivedere la struttura di caching o aggiungere keep-alive. Quattro: valuta se Sonnet 4.6 è sufficiente per una percentuale significativa dei task. Nella mia esperienza, il 60-70% dei task LLM in produzione non ha bisogno del modello top. Il routing intelligente è il lever più alto. Cinque: non sottovalutare il TTL da 5 minuti. Per chatbot con utenti umani che fanno domande sporadiche, questo è potenzialmente più costoso del tokenizer. Una riflessione strategica finale. Quello che è successo con Opus 4.7 non è un incidente: è un pattern. Ogni major model upgrade dei frontier lab porta con sé cambi invisibili nel tokenizer, nel TTL della cache, nel default del contesto, che shiftano il costo effettivo senza toccare il prezzo dichiarato. Il team che gestisce la cost governance di un'applicazione AI di produzione deve costruire un **release protocol** che per ogni nuovo modello esegua cinque passi in sequenza. Uno: count_tokens comparison su campione di prompt reali (quello che ho mostrato). Due: cost-per-task benchmark A/B tra vecchio e nuovo modello sulla test suite di regressione. Tre: pre-warming cache per evitare il cliff day. Quattro: audit breaking change API. Cinque: decision go/no-go basata sui dati, non sull'hype di release note. Senza questo protocollo, sei in balia degli upgrade. Con questo protocollo, ogni release diventa un'opportunità di re-negoziare il rapporto qualità/costo della tua pipeline. Opus 4.7 ha accuracy superiore; se il tuo use case la capitalizza, il +35% sul tokenizer si ripaga. Se no, Sonnet 4.6 resta la scelta economicamente superiore per ora, e il routing intelligente tra i due modelli è il dial più importante da costruire. Se stai gestendo un budget API Claude in azienda e vuoi un audit di tre giorni per identificare dove stai bruciando token non necessariamente, il [modulo di preventivo gratuito](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai) risponde in due minuti se il tuo caso rientra nel mio perimetro. Sette domande, niente impegno, e se il tuo scenario non rientra ti indirizzo a figure più adatte. Dall'articolo al lavoro vero Se vuoi portarlo dentro la tua azienda RAG sui documenti interni, automazioni con LLM, governance e costi prevedibili. [Vedi come lavoro sull AI](https://www.mauriziofonte.it/ai-aziende.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [« Articolo precedentePerché le allucinazioni LLM non si risolvono col prompting: rappresentazione distribuzionale e limiti architetturali7 Mag 2026](https://www.mauriziofonte.it/blog/post/allucinazioni-llm-rappresentazione-distribuzionale-perche-persistono.html)[Articolo successivo »Embeddings dominio-specifici per RAG italiano: costruire vettori su vocabolario aziendale con Word2Vec e fine-tuning11 Mag 2026](https://www.mauriziofonte.it/blog/post/embeddings-dominio-aziendale-word2vec-rag-italiano-tutorial-pratico.html) ### Articoli correlati a Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato - [Anthropic prompt caching workspace-level: ridurre il 95% dei costi API su un RAG aziendale](https://www.mauriziofonte.it/blog/post/anthropic-prompt-caching-workspace-ridurre-costi-api-rag-95-percento.html) Dal 5 febbraio 2026 Anthropic offre prompt caching a livello di workspace, con cache hit al 10 del prezzo input standard. Ho migrato il mio chatbot · 28 Mag 2026 ![Anthropic prompt caching workspace-level: ridurre il 95% dei costi API su un RAG aziendale](https://www.mauriziofonte.it/image/004230070-anthropic-prompt-caching-workspace-ridurre-costi-api-rag-95-percento.jpg) - [Anthropic Tool Search Tool e Programmatic Tool Calling: agenti con 50+ tool MCP senza saturare il context](https://www.mauriziofonte.it/blog/post/anthropic-tool-search-programmatic-tool-calling-mcp-ridurre-token.html) Quando un agent LLM ha 50 tool registrati via MCP, il token overhead del solo prompt di registrazione supera i 20k token e saturare il context · 4 Mag 2026 ![Anthropic Tool Search Tool e Programmatic Tool Calling: agenti con 50+ tool MCP senza saturare il context](https://www.mauriziofonte.it/image/004140070-anthropic-tool-search-programmatic-tool-calling-mcp-ridurre-token.jpg) - [Prompt caching workspace-level di Anthropic: perché i tuoi agenti costano troppo e come diagnosticare le cache mancate](https://www.mauriziofonte.it/blog/post/prompt-caching-workspace-level-anthropic-agenti-90-percento-risparmio.html) Dal febbraio 2026 Anthropic offre prompt caching workspace level con cache hit al 10 del prezzo input. Eppure nella maggioranza delle integrazioni · 18 Giugno 2026 ![Prompt caching workspace-level di Anthropic: perché i tuoi agenti costano troppo e come diagnosticare le cache mancate](https://www.mauriziofonte.it/image/004620070-prompt-caching-workspace-level-anthropic-agenti-90-percento-risparmio.jpg) - [Tokenizzazione degli LLM e italiano: la tassa nascosta del 64% sulla bolletta API e come ridurla](https://www.mauriziofonte.it/blog/post/tokenizzazione-llm-italiano-tassa-nascosta-costi-api-ottimizzare.html) Un prompt in italiano consuma mediamente 1,64 volte i token di un equivalente in inglese. Misura verificata su GPT 4 e Claude Opus 4.7 nel 2026, · 19 Mag 2026 ![Tokenizzazione degli LLM e italiano: la tassa nascosta del 64% sulla bolletta API e come ridurla](https://www.mauriziofonte.it/image/004460070-tokenizzazione-llm-italiano-tassa-nascosta-costi-api-ottimizzare.jpg) - [Claude Fable 5 per un backend engineer: API, costi e quando conviene (guida-decisione)](https://www.mauriziofonte.it/blog/post/fable-5-backend-engineer-api-costi-break-even-guida-decisione.html) Fable 5 è il tier sopra Opus, ma più capace non significa sempre conveniente. Cosa cambia per chi sviluppa: il request surface rispetto a Opus · 18 Agosto 2026 ![Claude Fable 5 per un backend engineer: API, costi e quando conviene (guida-decisione)](https://www.mauriziofonte.it/image/005100070-fable-5-backend-engineer-api-costi-break-even-guida-decisione.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/claude-opus-4-7-tokenizer-nuovo-costi-api-aumento-35-percento.html Pubblicato: 2026-05-08 · Aggiornato: 2026-06-19. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.