Claude Opus 5.5: il prezzo scende del 20%, e nell'aggiornamento c'è una trappola

Cosa è uscito il 22 settembre

Anthropic ha rilasciato Claude Opus 5.5, che prende il posto di Opus 5 come modello di punta della linea Opus. Opus 5 resta servito, ma è passato tra i modelli legacy.

Le caratteristiche di base non cambiano: un milione di token di contesto, 128.000 token di output massimo, conoscenza affidabile fino a giugno 2026, ragionamento adattivo sempre attivo. Sull'API il modello si chiama claude-opus-5-5, senza suffisso di data, ed è disponibile da subito su API Claude, Amazon Bedrock, Google Cloud e Microsoft Foundry. Anthropic si impegna a non ritirarlo prima del 22 settembre 2027.

Detto così sembra un aggiornamento di manutenzione. Sul prezzo non lo è, e su come vanno impostate le chiamate nemmeno.

La notizia è il listino

Input e output scendono da 5$ e 25$ per milione di token a 4$ e 20$. Meno 20% su entrambe le voci, con lo stesso contesto e un modello dichiarato più capace. È la prima volta che la linea Opus scende di prezzo generazione su generazione.

La lettura della cache passa da 0,50$ a 0,20$ per milione di token, cioè meno 60%. La scrittura in cache da 6,25$ a 5$.

Se non lavori con le API sembra contabilità. Non lo è quando fai girare agenti: un agente rilegge lo stesso contesto a ogni passo, quindi i token letti dalla cache diventano la voce dominante del conto, spesso più grande di quello che il modello scrive davvero. Lo stesso meccanismo aveva reso interessante Fable 5.1 un mese fa.

Anthropic dichiara output più veloci del 30% e circa il 40% di costo in meno per portare a termine lo stesso lavoro, una volta messi insieme prezzo e velocità. Sono stime del fornitore, ma appartengono alla categoria che si verifica sul proprio conto in due settimane.

Resta la modalità fast, solo su API Claude, a 8$ e 40$ per milione di token: il doppio del listino standard per un output più rapido. Su come si compone davvero la spesa, dal token alla formazione delle persone, ne ho scritto in quanto costa Claude in azienda.

I benchmark, e come leggerli

Su Terminal-Bench 4.0, che misura il coding agentico, Opus 5.5 arriva al 66,4% contro il 52,3% di Opus 5 e il 55,8% di Fable 5.1. È il risultato più citato del rilascio, e va letto con la nota che Anthropic stessa mette in fondo alla tabella: quel 66,4% è misurato a effort xhigh, il punteggio migliore del modello. Non è il comportamento predefinito.

Su CursorBench 4.0 si passa dal 46,6% di Opus 5 al 57,8%. Su OSWorld 2.1, che misura l'uso del computer, dal 74,0% all'81,8%. Su FrontierCode v1.1 il 54,4% supera il 50,3% di Fable 5.1, che costa due volte e mezzo tanto.

Sul lavoro d'ufficio il numero interessante è GDPval-AA v2.1, una valutazione su compiti di knowledge work: 1846 punti Elo contro i 1708 di Opus 5.

Due avvertenze valgono qui come sempre. I test li ha scelti e girati chi produce il modello. E un punteggio misurato al massimo dello sforzo dice quanto il modello può fare, non quanto farà nella configurazione in cui lo userai.

La trappola: l'effort predefinito è sceso

Questo è il punto che rischia di far sembrare peggiore un modello migliore.

Su Opus 5 l'effort predefinito, cioè quanta capacità di ragionamento il modello dedica a una richiesta quando non specifichi niente, era high. Su Opus 5.5 è medium.

Chi aggiorna il nome del modello nel codice e non tocca altro ottiene quindi un modello che, per impostazione predefinita, ragiona meno di quello che aveva prima. Su compiti brevi non si vede. Su analisi lunghe e lavoro agentico si vede eccome, e la conclusione naturale, sbagliata, è che il nuovo modello sia un passo indietro.

La correzione è una riga: impostare output_config.effort in modo esplicito. Anthropic consiglia di ripetere la calibrazione, perché i livelli sono stati ritarati e medium su 5.5 non corrisponde a medium su 5. Per il lavoro agentico lungo la raccomandazione resta high o xhigh, con la specifica del compito data tutta all'inizio.

Vale anche il contrario, e in genere è la scoperta più utile: su molti compiti di routine il nuovo modello a effort basso fa quello che il precedente faceva a effort alto, spendendo meno.

Quattro cose che si rompono nel codice

Se hai un'integrazione in produzione su Opus 5, questi quattro punti vanno guardati prima di cambiare il nome del modello.

Il ragionamento non si può più spegnere. Su Opus 5 impostare thinking disabled era ammesso fino a effort high. Su Opus 5.5 restituisce errore 400 a qualsiasi livello. La leva per spendere meno non è spegnere il ragionamento, è abbassare l'effort.

L'uso forzato degli strumenti non è più supportato. Impostare tool_choice su any oppure su tool dà errore 400, anche sull'endpoint di conteggio token. Va usato auto, con gli strumenti dichiarati in modalità strict e un'istruzione esplicita nel prompt su quando chiamarli. È lo stesso cambio già visto su Fable 5.1.

I blocchi di ragionamento sono legati al modello e alla conversazione. Opus 5.5 non legge i blocchi prodotti da Opus 5, e viceversa: l'API li scarta senza errore e senza addebito, ma il modello perde quel pezzo di contesto. Per gli account creati dal 31 agosto 2026 in poi vale anche il controllo sulla modifica della storia: se riscrivi un turno precedente e poi rimandi indietro un blocco di ragionamento, ricevi un 400. Le conversazioni vanno tenute in sola aggiunta.

L'uso del computer passa dal nuovo toolset. Su API Claude e Google Cloud vale solo computer_toolset_20260801; la versione precedente restituisce 400.

Ultimo dettaglio che non rompe niente ma fa sparire testo dall'interfaccia: le note che il modello scrive tra una chiamata e l'altra tornano dentro blocchi di ragionamento, vuoti con l'impostazione predefinita. Chi le mostrava all'utente vede l'interfaccia ammutolirsi.

Safeguard più larghi, e cosa comporta

Opus 5.5 rifiuta in più categorie del predecessore. Ai rifiuti su materia cyber si aggiungono quelli su biologia e quelli sulla richiesta di riprodurre il ragionamento interno del modello.

Un rifiuto non è un errore HTTP: la risposta torna con stato 200 e stop_reason impostato su refusal, con una categoria. Il codice che legge direttamente il contenuto senza guardare quel campo si comporta come se il modello avesse risposto vuoto.

Anthropic dichiara anche un calo dell'85% dei tentativi del modello di aggirare i limiti che gli vengono posti, che è il tipo di miglioramento che conta quando un agente gira senza nessuno a guardarlo.

Per chi fa lavoro di sicurezza legittimo esistono i programmi di verifica, per ora limitati agli Stati Uniti. Per tutti gli altri il punto pratico è uno: prevedere il caso del rifiuto nel codice, ed eventualmente il ripiego automatico su un altro modello.

Cosa cambia per un'azienda italiana

Tre cose, in ordine di impatto.

La prima è il conto. Se usi Opus via API, il costo scende del 20% senza fare niente, e molto di più se il tuo carico rilegge spesso lo stesso contesto. Vale la pena rifare il calcolo prima di rinunciare a Opus per ragioni di budget.

La seconda è la calibrazione. Aggiornare il nome del modello senza fissare l'effort è il modo più rapido per ottenere un risultato peggiore e incolpare il modello. Mezz'ora di prove su un campione di richieste reali evita mesi di conclusioni sbagliate.

La terza è la scelta tra modelli, che sei giorni dopo si è complicata: il 28 settembre è arrivato Sonnet 5.5, che su alcuni test di coding agentico sta sopra a Opus 5.5 e costa un quinto. Su come si decide tra i due ho scritto un confronto dedicato.

Noi in Maverick lavoriamo su questo: architetture che mescolano i modelli invece di sceglierne uno per sempre, con il costo tenuto sotto controllo dal disegno e non dalla rinuncia.