Claude Opus 4.7 e il nuovo tokenizer: perché la tua bolletta è salita del 35% a prezzo invariato

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 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 mostra $5/$25 per Opus 4.7, identici a 4.6. La migration guide di Anthropic 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 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

declare(strict_types=1);

use GuzzleHttp\Client;

final class TokenCountComparator
{
    private const COUNT_ENDPOINT = 'https://api.anthropic.com/v1/messages/count_tokens';

    public function __construct(
        private readonly Client $http,
        private readonly string $apiKey,
    ) {
    }

    public function compare(string $prompt, string $systemPrompt = ''): array
    {
        $oldCount = $this->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:

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 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:

$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 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.