Claude Sonnet 5.5 e Opus 5.5: costi, benchmark e differenze che contano nella API

Due modelli della stessa famiglia, due scelte operative

Anthropic ha presentato Claude Opus 5.5 il 22 settembre 2026 e Claude Sonnet 5.5 il 28 settembre. Il primo è proposto per attività complesse che richiedono giudizio e continuità; il secondo per iterazioni rapide e compiti delimitati. Questo confronto legge specifiche, prove pubblicate e documentazione delle integrazioni: non attribuisce alla redazione test che non ha eseguito. La domanda utile è quale configurazione usare nel proprio flusso, non quale nome occupi sempre il primo posto. [1][2]

Entrambi risultano disponibili tramite Claude API e attraverso le piattaforme cloud indicate da Anthropic, comprese AWS, Google Cloud e Microsoft Foundry. Gli identificatori diretti sono claude-sonnet-5-5 e claude-opus-5-5; su Amazon Bedrock il prefisso cambia in anthropic. Per le app Claude valgono anche piano e limiti del servizio: disponibilità del modello e disponibilità di ogni funzione API non sono sinonimi. Aggiornamento del 7 ottobre: anche Haiku 5.5 è stato annunciato; il precedente comunicato Sonnet che lo dava in arrivo non descrive più la situazione attuale. [3][1][13]

Per un gruppo di sviluppo, prova a separare tre decisioni: il modello che interpreta una richiesta, quello che modifica i file e il controllo che stabilisce se il risultato funziona. Una correzione circoscritta e una migrazione con dipendenze incerte meritano esperimenti diversi. Parti da requisiti verificabili, come test da superare, file autorizzati e comportamento da conservare. Evita di classificare un incarico come facile soltanto perché il testo della richiesta è breve: una singola riga può nascondere un cambiamento architetturale.

Prezzi, cache e contesto: il conto che serve davvero

Nel listino della Claude API, Sonnet 5.5 costa 2 dollari per milione di token in ingresso e 10 in uscita; Opus 5.5 costa rispettivamente 4 e 20 dollari. Dal 7 ottobre, la lettura della cache Sonnet scende da 0,20 a 0,10 dollari per milione, mentre Opus resta a 0,20: lo confermano l’annuncio Haiku e il paragrafo aggiornato del listino, la cui tabella conserva ancora il valore precedente. Scrivere una cache di cinque minuti costa 2,50 dollari con Sonnet e 5 con Opus; quella di un’ora costa 4 e 8. La composizione dei token conta quanto la tariffa base. [7][13]

La documentazione assegna a entrambi un contesto da un milione di token e un massimo di output di 128 mila token. Sono limiti diversi: il primo riguarda lo spazio della richiesta, il secondo quanto la risposta può produrre. Nel codice è disponibile anche la Models API, che espone i limiti e le capacità del modello. Consultarla è più robusto che dedurre il supporto a una funzione dalla sola stringa del nome o riutilizzare una costante fissata per una generazione precedente. [3]

Un conto illustrativo aiuta a leggere il listino: con 100 mila token nuovi in ingresso e 10 mila complessivi in uscita, senza cache o altri servizi, la tariffa base porta a 0,30 dollari con Sonnet e 0,60 con Opus. Non è il costo misurato di un incarico: le quantità sono ipotetiche. Per confrontare due agenti somma anche tentativi falliti e verifiche, quindi dividi per risultati accettati. Conserva separatamente input nuovo, input in cache e output totale: altrimenti una risposta breve può nascondere un’esecuzione costosa.

Effort: attenzione ai default e ai confronti apparentemente equi

Le impostazioni iniziali differiscono: Sonnet 5.5 usa Medium nelle app Claude e in Claude Code, mentre sulla Claude Platform il default è High. Opus 5.5 ha Medium come effort predefinito nella API. Il parametro si imposta attraverso output_config.effort e influenza tutti i token della risposta, comprese chiamate agli strumenti e ragionamento. Due richieste che omettono effort possono quindi confrontare configurazioni diverse senza che il programmatore se ne accorga. [1][6]

High è lo stesso livello nominale, non un budget identico di token tra modelli. Per Opus 5.5 Anthropic avverte che, a parità di effort, il ragionamento per turno può crescere rispetto a Opus 5 e consiglia di ripetere la calibrazione. La guida Sonnet chiarisce inoltre che non esiste una corrispondenza fissa fra il vecchio budget numerico e un livello effort. Portare il nome del modello alla versione nuova senza misurare nuovamente tempi e consumi è dunque una migrazione incompleta. [4][5]

Un dettaglio della system card rende concreto il problema: su FrontierCode Main, Sonnet 5.5 ottiene 52,1% a Xhigh e 46,2% a Max. Il test penalizza cambiamenti fuori dal perimetro, anche quando sono utili o di buona qualità. Aumentare il ragionamento non equivale quindi a migliorare ogni risultato: serve verificare anche il rispetto dell’incarico, non soltanto quanta attività l’agente svolge. [9]

Nell’esperimento, fissa esplicitamente effort, tetto di output e strumenti disponibili. Esegui prima incarichi brevi, poi lavori che richiedono più passaggi, registrando il tempo fino al primo testo e quello fino a un risultato verificato. Un agente che scrive velocemente può perdere tempo nella ricerca o nella correzione di una soluzione sbagliata. Mantieni anche una configurazione economica di riferimento: aumentare effort deve superare una prova concreta di qualità, non soltanto produrre una spiegazione più lunga.

Terminal-Bench: leggere insieme successo e costo

Nel grafico ufficiale di Terminal-Bench 4.0 del 28 settembre, a High Sonnet 5.5 registra 43,0% e 1,94 dollari per incarico; Opus 5.5 registra 64,2% e 3,88 dollari. I due grafici riportano i valori letterali delle etichette accessibili SVG, senza dedurli dalla posizione dei punti. Confrontano la stessa valutazione pubblicata e lo stesso effort nominale, separando accuratezza e spesa. I costi precedono il taglio della cache Sonnet del 7 ottobre: non sono una stima delle tariffe attuali né una promessa per il tuo repository. [1][13]

Il numero più citato, 70,6% per Sonnet contro 66,4% per Opus, usa invece Max per il primo e Xhigh per il secondo. La system card descrive 66 incarichi in ambiente terminale, Claude Code in modalità --bare, risorse preparate e nessun accesso Internet in uscita. Le medie dei risultati migliori usano cinque prove per incarico e comprendono le politiche di salvaguardia con eventuale fallback. Questo contesto aiuta a leggere quei punteggi, ma non documenta automaticamente ogni condizione dei punti High del grafico. [9]

Un controllo indipendente arriva da Artificial Analysis: nelle schede consultate il 7 ottobre, configurate come Max con fallback predefinito, Sonnet 5.5 ha Intelligence Index 56 e Opus 5.5 ha 58. Non sono percentuali né risultati Terminal-Bench. La metodologia dell’indice combina più valutazioni. Sono un riscontro utile sulla configurazione specifica, ma il piccolo distacco non basta a predire una migrazione di codice o la qualità di un documento. Per questo non mescoliamo quei punti con le percentuali dei grafici Anthropic. [11][12]

La migrazione che rompe il codice prima ancora del modello

Con Sonnet 5.5, thinking disabled restituisce un errore 400: per eliminare il ragionamento iniziale si usa between_tools. Questo valore è accettato a Low, Medium e High, mentre Xhigh e Max richiedono adaptive. Opus 5.5 mantiene invece adaptive thinking sempre attivo: disabilitarlo o fornire un vecchio budget manuale è rifiutato. Sono differenze operative verificabili nei manuali; lo stesso wrapper non dovrebbe applicare indistintamente a entrambi una configurazione pensata per i modelli precedenti. [5][4]

Anche forzare la scelta di uno strumento con tool_choice any o tool può provocare un errore, come spiegano le guide di migrazione. Per Opus restano supportati auto e none; per ottenere dati con uno schema bisogna seguire le opzioni documentate per output strutturati o strumenti rigorosi. Un altro cambiamento meno visibile riguarda gli aggiornamenti fra chiamate: arrivano nei blocchi thinking e, con il display predefinito omitted, il loro testo può essere vuoto. Un’interfaccia può quindi sembrare silenziosa pur senza un errore della richiesta. [4][5]

Prima di sostituire il modello in produzione, prepara richieste di controllo per testo semplice, uso di un solo strumento, ciclo con più strumenti e risposta strutturata. Verifica codice di stato, tipo dei blocchi e motivo di arresto. Leggi i contenuti per type, senza assumere che il primo elemento sia testo da mostrare. Controlla inoltre che una UI segnali l’avanzamento quando il messaggio visibile è assente. Questa prova distingue un’integrazione rotta da un modello che sta ancora lavorando e rende più rapido il confronto successivo.

Routing Sonnet–Opus: il passaggio non è simmetrico

La documentazione di preserved thinking distingue la cronologia della conversazione dai blocchi di ragionamento che un altro modello sa leggere. Su Claude API e Google Cloud, Opus 5.5 legge i blocchi prodotti da Sonnet 5.5; il passaggio inverso non conserva il ragionamento precedente di Opus. I blocchi non leggibili vengono rimossi prima che il modello li riceva. I blocchi Sonnet sono inoltre legati all’account che li ha prodotti: spostare una conversazione fra account richiede attenzione alle regole specifiche della piattaforma. [8]

Esiste anche un vincolo sul prefisso: modificare istruzioni, strumenti o messaggi anteriori a un blocco può invalidarlo. Per gli account creati dal 31 agosto 2026 il controllo del prefisso è attivo per default; sui precedenti dipende dalle impostazioni indicate nelle docs. Le API possono rifiutare la richiesta o eliminare i blocchi interessati secondo la configurazione. Non bisogna quindi trattare la sostituzione di un prompt durante una sessione come un semplice aggiornamento innocuo della stringa. [8]

Per un routing illustrativo, assegna a Sonnet una modifica circoscritta con test e diff atteso. Passa a Opus se emergono requisiti contraddittori o una scelta architetturale da discutere. Se torni a Sonnet, includi una consegna esplicita: decisioni approvate, vincoli e file modificati. Conserva la cronologia secondo le istruzioni API invece di manipolare a mano i blocchi firmati. Valuta questo passaggio con lo stesso insieme di incarichi: la strategia ha senso soltanto se migliora risultati accettati, costo e tempo complessivo rispetto a un modello unico.

Prompt injection: più ragionamento non sostituisce le difese

La system card Opus riporta un caso istruttivo: un precedente snapshot interpretava un’istruzione nascosta in testo incollato dall’utente come autorizzazione, mentre il problema non compariva nelle stesse condizioni dentro risultati degli strumenti. Dopo l’aggiornamento del training, nella valutazione descritta la versione finale seguiva ancora l’istruzione nel 2% circa dei tentativi all’effort predefinito e nel 7,4% circa a Max. Con le mitigazioni del prodotto non seguiva le istruzioni piantate osservate in quel test. I risultati riguardano quegli scenari, non ogni attacco possibile. [10]

La conseguenza pratica è separare il contenuto da analizzare dall’autorità di decidere. In una prova del tuo agente, usa un documento di esempio con un’istruzione estranea al compito e verifica che non diventi un comando operativo. Registra l’azione proposta, gli strumenti disponibili e quali controlli la fermano. Tratta l’aumento di effort come una variabile della prova: non presumere che una maggiore riflessione risolva da sola la distinzione fra un log, una pagina recuperata e una richiesta autorizzata.

Mantieni l’esperimento iniziale in un ambiente con dati di esempio e risultati controllabili. Assegna soltanto strumenti necessari al lavoro, confronta i cambiamenti con i vincoli dichiarati e conserva una via di recupero. Il punteggio di una system card non descrive automaticamente la tua combinazione di modello, prompt, connettori e permessi. Il criterio di successo deve includere anche cosa l’agente evita di cambiare, non soltanto se consegna una risposta che sembra convincente.

Come scegliere senza trasformare ogni richiesta in un benchmark

Costruisci un piccolo insieme stabile di lavori realmente rappresentativi: una correzione con regressione da evitare, un aggiornamento di dipendenze, un confronto fra due proposte e un documento da completare con fonti. Fissa prima dell’esecuzione i criteri di accettazione. Una soluzione è completa quando supera quei criteri; dichiarare che il compito è finito non basta. Ripeti i casi con identiche risorse disponibili e riporta risultati e fallimenti, senza scegliere a posteriori soltanto l’output più gradevole.

Per ogni configurazione confronta costo per esito accettato, tempo totale, numero di correzioni e rispetto del perimetro. Conserva anche gli incarichi nei quali il modello più economico fallisce e quello più costoso non migliora il risultato: sono utili per definire le soglie di escalation. Il candidato operativo migliore è quello che raggiunge la qualità richiesta con un consumo sostenibile nel tuo carico. Il routing dovrebbe nascere da queste misure, non dall’idea che ogni richiesta debba attraversare entrambi i modelli.

Rivedi infine il confronto quando cambiano prompt, strumenti, fallback o versione del servizio. Le tariffe per token aiutano a impostare un budget; le curve del produttore spiegano i compromessi; le prove indipendenti offrono un altro punto di osservazione. La decisione sul tuo flusso resta una verifica distinta. Parti da una configurazione esplicita, conserva i dati dell’esperimento e rendi ripetibile il passaggio: così il confronto fra Sonnet e Opus diventa un criterio operativo invece di una classifica astratta.