Prezzi dell'API di Claude Sonnet 5: rischi di migrazione, costi dei token e instradamento verso Opus

TLDR

Claude Sonnet 5 è live come claude-sonnet-5: contesto da 1M, output massimo 128k e prezzi introduttivi $2 / $10 per MTok input/output fino al 31 agosto 2026. Il prezzo standard è $3 / $15 per MTok dopo tale data.

Per i team su Sonnet 4.6, non è una semplice sostituzione dell’ID modello. Ridefinite la baseline di token di output, livello di effort, tasso di hit della cache del prompt, tasso di HTTP 400 e tasso di fallback su Opus 4.8 prima di instradare traffico di produzione.

API Migration Snapshot

Key Takeaways

• Sonnet 5 è una decisione di migrazione, non solo un ID modello più recente.
• Misurate il costo per task risolto, non solo il prezzo per token.
• Impostate effort in modo intenzionale; Sonnet 5 usa high per impostazione predefinita su Claude API e Claude Code.
• Ridefinite la baseline di caching del prompt, token di output e tasso di HTTP 400 prima del rollout in produzione.
• Mantenete Opus 4.8 nel set di valutazione per lavoro agentico ad alto effort.

What Actually Shipped

L’annuncio di Claude Sonnet 5 di Anthropic lo presenta come il prossimo modello di classe Sonnet per la produzione. La superficie pratica nella panoramica dei modelli Claude e nella pagina prezzi ufficiale porta alla stessa conclusione: Sonnet, non Opus, è dove molti team prendono decisioni quotidiane su instradamento, latenza e costi.

What Public Discussion Shows

I fatti concreti provengono dalla documentazione di Anthropic. Nel confronto pubblicato da Anthropic, Sonnet 5 ottiene 63,2% su SWE-bench Pro contro 58,1% per Sonnet 4.6, raggiunge 80,4% su Terminal-Bench 2.1 contro 67,0%, e migliora Humanity's Last Exam con strumenti da 46,8% a 57,4%.

La discussione pubblica è utile per uno scopo più ristretto: mostra cosa hanno notato per primi i builder e quali affermazioni meritano di essere ritestate. Il thread del grafico di lancio di TestingCatalog (launch-chart thread) ha portato alla conversazione sui benchmark, la lettura prezzo/prestazioni di Chubby (price/performance read) ha inquadrato la domanda di confronto, e la nota sulla disponibilità di strumenti per sviluppatori di Kilo Code (developer-tool availability note) ha mostrato i primi movimenti dell’ecosistema.–

Fonte: @claudeai

Le domande di follow-up sono più utili dell’hype di lancio. La discussione su Hacker News si è concentrata sull’uso dei token e sulle curve di costo, il thread di lancio su r/singularity ha dibattuto il confronto con Opus, e le prime impressioni su r/ClaudeAI hanno raccolto resoconti a livello utente. Trattate quei thread come segnali, non come specifiche.

Claude Sonnet 5 API Pricing

La tariffazione di Claude Sonnet 5 ha due fasi.

La tabella segue la pagina prezzi di Claude di Anthropic.

Il dettaglio importante è che il prezzo per token non è l’intera storia del costo. La documentazione di Claude Sonnet 5 di Anthropic nota che il nuovo tokenizzatore può produrre circa il 30% di token in più per lo stesso testo. Consideratelo un numero di pianificazione approssimativo, non un moltiplicatore fisso. L’aumento esatto dipende dal contenuto e dalla forma del carico di lavoro, quindi i team dovrebbero rieseguire il conteggio dei token sui propri prompt di produzione.

Per la migrazione, utilizzate questa metrica di instradamento:

Costo effettivo per task risolto = (costo del modello primario + costo dei retry + fallback + costo) / task riusciti

Se Sonnet 5 completa più task con meno retry o meno chiamate di fallback a Opus, può comunque risultare più economico nella pratica. Se l’uso dei token aumenta senza migliorare la qualità di completamento, il prezzo più basso in evidenza potrebbe non tradursi in un costo inferiore del carico di lavoro.

Three Engineering Dark Corners

Il rischio di migrazione non riguarda solo la qualità del modello. Tre dettagli meno visibili possono cambiare costo o affidabilità in produzione.

Il ragionamento adattivo può trasformarsi in spesa di token di output

Claude Sonnet 5 utilizza il ragionamento adattivo per impostazione predefinita. La documentazione sul ragionamento esteso di Anthropic afferma che i token di ragionamento sono fatturati come token di output, quindi una risposta finale breve può comunque nascondere una grande quantità di lavoro di ragionamento fatturato.

Il controllo standard non è un budget fisso di ragionamento. Anthropic descrive effort come il controllo della profondità di ragionamento nella guida alla migrazione di Claude e nella documentazione di effort, mentre la panoramica del modello elenca high come predefinito di Sonnet 5 su Claude API e Claude Code. Per instradamento semplice o classificazioni deterministiche, testate livelli di effort più bassi come low o medium, oppure disattivate completamente il ragionamento; quindi verificate latenza, qualità e uso dei token di output.

Checklist di migrazione:

• Registrate l’impostazione effettiva di effort con ogni run di valutazione.
• Tracciate usage.output_tokens, non solo la lunghezza visibile della risposta.
• Confrontate latenza p50/p95 per Sonnet 4.6, Sonnet 5 e Opus 4.8.
• Per instradamento semplice o classificazioni deterministiche, testate livelli di effort più bassi o disattivate completamente il ragionamento, poi confrontate latenza, uso dei token di output e accuratezza del task.
• Osservate i task in cui Sonnet 5 risponde correttamente ma spende abbastanza token di ragionamento da rendere Opus 4.8 competitivo.

1. La cache del prompt deve essere ricalibrata

Per ricerca con contesto lungo, agenti di supporto e orchestrazione multi-step, la guida alla cache dei prompt di Anthropic è spesso la leva di costo più grande. Il nuovo tokenizzatore di Sonnet 5 può cambiare il conteggio dei token dello stesso prompt, quindi le assunzioni di costo sul caching dell’input dovrebbero essere ricalcolate dopo la migrazione. Il comportamento della cache dovrebbe anche essere riverificato indipendentemente monitorando i campi di creazione cache e utilizzo in lettura della cache.

Non presumete che una strategia di caching dei prompt ottimizzata per Sonnet 4.6 produca lo stesso profilo di costo a livello di carico di lavoro su Sonnet 5.

Checklist di migrazione:

• Rieseguite il conteggio dei token su tutti i prompt lunghi prima di spostare il traffico.
• Ricontrollate i breakpoints della cache e il posizionamento delle direttive di cache-control.
• Monitorate cache_creation_input_tokens e cache_read_input_tokens durante la finestra di migrazione.
• Attivate allerta su cali improvvisi di lettura cache o picchi di creazione cache dopo il cambio dell’ID modello.

I parametri di campionamento rifiutati generano 400 bloccanti in produzione

Sonnet 5 è più rigoroso su alcuni parametri di campionamento rispetto a molte integrazioni più vecchie. Le note di rilascio API di Anthropic indicano che valori non predefiniti di temperature, top_p e top_k restituiscono un errore HTTP 400. Se il vostro wrapper SDK imposta hardcoded i parametri di campionamento per ogni modello, un rollout può fallire al momento della richiesta.

Checklist di migrazione:

• Cercate nel codebase impostazioni hardcoded di temperature, top_p e top_k.
• Aggiungete validazione specifica per modello dei parametri prima dell’invio delle richieste.
• Effettuate un canary della migrazione con allerte sul tasso di errore prima del rollout completo.
• Mantenete una route di fallback a Sonnet 4.6 finché la validazione dei parametri non è pulita.

Claude Sonnet 5 vs Claude Sonnet 4.6

Claude Sonnet 5 è il candidato naturale di upgrade per i team che già usano Sonnet 4.6, ma non va trattato come una migrazione senza revisione.

Questo conta soprattutto per applicazioni con budget di token stretti, impostazioni di campionamento deterministiche o prompt lunghi. Prima di sostituire Sonnet 4.6 in produzione, rieseguite il conteggio dei token, rimuovete i parametri di campionamento non supportati e confrontate i tassi di successo dei task.

Sonnet 5 or Opus 4.8: The Routing Decision Tree

La valutazione più robusta non è solo Sonnet 5 vs Sonnet 4.6. Per molti team, la vera domanda di instradamento è:

Questo workflow deve usare il più economico Sonnet 5 o il più forte Opus 4.8?

Usate questo semplice albero decisionale:

• Instradate su Sonnet 5 quando il workflow è di media complessità, sensibile alla latenza o ai costi.
• Instradate su Sonnet 5 quando il task è abbastanza ripetitivo da misurare in modo affidabile retry e tempo di revisione.
• Mantenete Opus 4.8 nella route quando il task richiede pianificazione ad alto effort, coding multi-file o decisioni enterprise costose.
• Mantenete Opus 4.8 nella route quando una risposta errata costa più della differenza di token.
• Mantenete temporaneamente Sonnet 4.6 quando i prompt di produzione dipendono da parametri di campionamento non supportati o da budget di ragionamento esteso manuali.

L’errore più comune è scegliere solo in base al prezzo. L’approccio migliore è confrontare:

• tasso di task risolti
• token medi in input
• token medi in output
• retry per task riuscito
• latenza per task riuscito
• tempo di revisione umana risparmiato
• tasso di fallback a Opus

Benchmarks: What To Trust And What To Retest

Anthropic posiziona Claude Sonnet 5 su coding, uso di strumenti e workflow professionali agentici. La conversazione di terze parti al lancio, in particolare il thread dei benchmark di TestingCatalog e il confronto prezzo/prestazioni di Chubby, ha trasformato la questione in una domanda pratica da benchmark: Sonnet 5 chiude abbastanza il gap con Opus da cambiare l’instradamento in produzione?

I numeri spiegano perché la domanda conta. Sonnet 5 è indietro rispetto a Opus 4.8 di 6,0 punti su SWE-bench Pro e 2,3 punti su Terminal-Bench 2.1, ma batte Sonnet 4.6 di 5,1 e 13,4 punti sugli stessi test. Il grafico di Chubby mostra anche Sonnet 5 che passa da circa $2+ per task a basso effort verso la fascia $5-$7 a effort più alto, quindi le impostazioni di effort dovrebbero far parte del benchmark.

Fonte: @kimmonismus

Trattate i benchmark di lancio come direzionali. Ritestate:

• se Sonnet 5 riduce i retry nel vostro codebase.
• se il ragionamento adattivo cambia latenza o lunghezza dell’output.
• se il nuovo tokenizzatore aumenta la vostra fattura effettiva.
• se il tasso di hit della cache del prompt resta stabile dopo i cambiamenti del tokenizzatore.
• se parametri rifiutati creano picchi di HTTP 400 nel traffico canary.
• se Opus 4.8 resta vincente sui task ad alto effort.

Qui la discussione sui costi su Hacker News e i primi resoconti utenti su r/ClaudeAI sono utili. Non sono la fonte di verità sulle specifiche del modello, ma rivelano le domande che gli sviluppatori reali pongono per prime: “Sarà davvero più economico?”, “Usa più token?”, “Quando dovrei ancora pagare per Opus?”

How To Evaluate Claude Sonnet 5 Yourself

Usate la finestra di prezzi introduttivi per eseguire un test piccolo ma realistico.

Costruisci un set di valutazione da 20 task

Includete task reali, non prompt giocattolo:

• bug fix nel vostro repo
• workflow di chiamata strumenti
• sintesi di documenti con contesto lungo
• triage ticket di supporto
• code review
• SQL o analisi dati
• task agentico multi-step

Esegui gli stessi task su Sonnet 4.6, Sonnet 5 e Opus 4.8

Non confrontate output singoli. Confrontate lo stesso set di task con lo stesso prompt e gli stessi criteri di revisione.

Se il vostro stack di valutazione usa agenti di coding, framework o strumenti di prompt-eval, il CometAPI Cookbook offre guide di integrazione native per GitHub per workflow sviluppatore comuni come Claude Code, Codex, LiteLLM, LangChain, Langfuse e Promptfoo.

Misura il costo per task risolto

Tracciate:

• token in input
• token in output
• richieste con molti token di ragionamento, usando i delta dei token di output e qualsiasi breakdown di utilizzo disponibile
• token di creazione cache
• token di lettura cache
• retry
• latenza
• errori HTTP 400
• modifiche manuali necessarie
• punteggio finale pass/fail

1. Osserva i vincoli di migrazione

Nel passaggio da Sonnet 4.6 a Sonnet 5:

• usa claude-sonnet-5
• rimuovi i parametri di campionamento non supportati
• evita budget manuali di ragionamento esteso
• ritesta max_tokens
• riconta i token con il tokenizzatore di Sonnet 5
• ricontrolla i breakpoints della cache del prompt
• attiva allerta su cali di lettura cache, picchi di creazione cache e picchi di HTTP 400

Decidi per classe di carico di lavoro

Usa Sonnet 5 di default per workflow di produzione di media complessità. Mantieni Opus 4.8 per workflow ad alto effort finché i tuoi dati sui task risolti non indicano il contrario.

What To Watch Next

Osservate cinque cose nelle prossime settimane:

1. Benchmark indipendenti su coding e agenti.
2. Resoconti reali degli sviluppatori sull’uso dei token con il nuovo tokenizzatore.
3. Resoconti sulla spesa di token di output dovuta al ragionamento adattivo.
4. Comportamento del tasso di hit della cache del prompt sui carichi con contesto lungo.
5. Cambiamenti di prezzo o disponibilità dopo la fine della finestra introduttiva il 31 agosto 2026.

Se il vostro team usa già Sonnet 4.6, non aspettate la fine della finestra di prezzo. Luglio e agosto sono il momento giusto per testare Sonnet 5 sui vostri carichi reali e decidere se migrare.

FAQ

Quanto costa Claude Sonnet 5?

Claude Sonnet 5 costa $2/$10 per MTok input/output fino al 31 agosto 2026. Il prezzo standard è $3/$15 per MTok dopo tale data.

Claude Sonnet 5 è un sostituto drop-in di Sonnet 4.6?

Per lo più sì, ma non senza test. Aggiornate l’ID modello, rimuovete i parametri di campionamento non supportati, impostate effort, ricontate i token e ridefinite la baseline della cache del prompt.

I token di ragionamento di Claude Sonnet 5 sono fatturati?

Sì. I token di ragionamento sono fatturati come token di output, quindi monitorate usage.output_tokens e la latenza.

Posso disattivare il ragionamento adattivo per task semplici?

Sì. Su Claude Sonnet 5, passate thinking: {"type": "disabled"} per disattivare il ragionamento. Se il carico beneficia comunque del ragionamento, mantenete il ragionamento adattivo abilitato e usate il parametro effort per controllare la profondità del ragionamento. Sonnet 5 usa high di default, quindi i carichi sensibili alla latenza dovrebbero testare impostazioni più basse come low o medium.

I costi della cache del prompt possono cambiare dopo la migrazione a Sonnet 5?

Sì. Ricontrollate i breakpoints della cache e monitorate cache_creation_input_tokens e cache_read_input_tokens.

Sonnet 5 ignorerà i parametri di campionamento non supportati?

No. Valori non predefiniti di temperature, top_p e top_k restituiscono errori HTTP 400. Rimuovete parametri hardcoded o aggiungete validazione specifica per modello prima del rollout in produzione.

Dovrei usare Claude Sonnet 5 o Claude Opus 4.8?

Usate Sonnet 5 per workflow sensibili ai costi. Mantenete Opus 4.8 per coding agentico ad alto effort e task enterprise complessi.

Testa la migrazione con CometAPI

Potete testare Claude Sonnet 5 tramite CometAPI e confrontarlo con Claude Sonnet 4.6, Claude Opus 4.8 e altri modelli di frontiera in un unico workflow API. Per pattern di setup tra agenti di coding, strumenti di automazione e framework di valutazione, usate il CometAPI Cookbook come compagno pratico ai vostri benchmark. Partite da un set di task piccolo, misurate il costo per task risolto e scegliete il modello che vince sul vostro carico di lavoro.