Guida all'API di Claude Opus 5.5: l'ID del modello, quattro modifiche incompatibili e la quinta silenziosa

Cambia la stringa del modello da claude-opus-5 a claude-opus-5-5 e il tuo codice continua a compilare, continua a superare il type-checking e continua a passare qualunque cosa passi per una suite di test. Poi in produzione restituisce un 400. Quattro forme di richiesta che Claude Opus 5 accettava vengono respinte di netto da Claude Opus 5.5, e una quinta modifica non rompe assolutamente nulla — ed è esattamente per questo che sarà quella che arriverà ai tuoi utenti. Questa è la guida di riferimento per l'integrazione del modello: l'identificatore, le superfici che lo servono, il contratto delle richieste, i quattro errori, il quinto silenzioso e come funziona ora il parametro effort. Dove il comportamento coincide con Claude Fable 5.1, un team che ha già effettuato la migrazione lì ha già fatto parte del lavoro, quindi ogni modifica di seguito indica se vale anche per quel modello.

Tutto ciò che segue è tratto dalla documentazione di Claude di Anthropic stessa, datata 2026-09-24, due giorni dopo il lancio del modello. Le dichiarazioni del fornitore sono etichettate come dichiarazioni del fornitore, i numeri indipendenti come indipendenti, e i due non vengono mai presentati alla stessa impostazione di effort come se fossero comparabili.

L'ID del modello e dove viene servito

L'identificatore è claude-opus-5-5 — un id di modello fisso senza suffisso di data, lo stesso schema di claude-opus-5. Non esiste una forma separata di snapshot bloccato da adottare né un alias che risolva a qualcos'altro.

La panoramica dei modelli di Anthropic elenca cinque superfici, con queste stringhe esatte:

• Claude API — claude-opus-5-5, disponibile per tutti i clienti.

• Amazon Bedrock — anthropic.claude-opus-5-5 (l'unica interfaccia che antepone il fornitore).

• Claude Platform su AWS — claude-opus-5-5, che utilizza gli id dell'API Claude anziché gli id in stile Bedrock.

• Google Cloud — claude-opus-5-5.

• Microsoft Foundry — claude-opus-5-5; il nome della distribuzione è quello che si invia, e Foundry segue il calendario del ciclo di vita dell'API Claude.

Due di questi cinque contano più del resto di questa sezione. Amazon Bedrock e Google Cloud fissano le proprie date di ciclo di vita e di dismissione e — come mostrano le modifiche dirompenti di seguito — Bedrock è anche l'unica piattaforma in cui il vecchio strumento di uso del computer funziona ancora. Se utilizzi Bedrock, non stai seguendo la stessa migrazione di tutti gli altri.

Ciò che ogni richiesta deve soddisfare ora

La guida alla migrazione di Anthropic enuncia il contratto sotto forma di elenco, e l'elenco è abbastanza breve da poterci verificare il proprio client. Indipendentemente dal modello da cui provieni, una richiesta a claude-opus-5-5 deve:

• Invia o nessun campo thinking oppure thinking: {"type": "adaptive"} — i due sono equivalenti, perché il pensiero adattivo è sempre attivo.

• Controlla la profondità del pensiero con effort, l'unico parametro della richiesta che lo consente; tutti e cinque i livelli sono supportati e il valore predefinito è medio.

• Usa tool_choice con {"type": "auto"} (impostazione predefinita) o {"type": "none"}. Forzare uno strumento viene rifiutato.

• Ometti temperature, top_p e top_k, oppure lasciali ai loro valori predefiniti. Qualsiasi altro valore viene rifiutato, su questo modello come su tutto da Claude Opus 4.7 in poi.

• Non terminare i messaggi con un turno dell'assistente precompilato; ciò era già stato rifiutato su Opus 4.6 e versioni successive.

• Dichiara l'uso del computer come il computer_toolset_20260801 toolset sull'API Claude e Google Cloud.

• Non inviare alcun header beta per la finestra di contesto. La finestra di contesto da 1M è quella predefinita, e un header scritto per un modello precedente non ha alcun effetto.

Dove la guida dice che un'impostazione viene rifiutata, l'API restituisce HTTP 400. Questa è l'intera modalità di errore del passaggio a questo modello: non un output degradato, non un avviso in un log — una richiesta che non viene mai eseguita.

Le quattro modifiche incompatibili

1. Impossibile disabilitare il pensiero

Il pensiero adattivo è sempre attivo. thinking: {"type": "disabled"} restituisce un 400, e lo stesso vale per un budget manuale — thinking: {"type": "enabled", "budget_tokens": N}. Il testo dell'errore indica il tipo inviato e poi indica la sostituzione:

• "thinking.type.disabled" non è supportato per questo modello. Usa "thinking.type.adaptive" e "output_config.effort" per controllare il comportamento di thinking.

• "thinking.type.enabled" non è supportato per questo modello. Usa "thinking.type.adaptive" e "output_config.effort" per controllare il comportamento del thinking.

La conseguenza pratica non è l'errore, ma ciò che accade dopo averlo risolto. Su Claude Opus 4.8 e versioni precedenti, una richiesta priva del campo thinking veniva eseguita senza thinking. Su Claude Opus 5.5 ogni richiesta esegue il thinking, e max_tokensresta un limite rigido che copre il thinking più il testo della risposta. I token di thinking vengono fatturati come token di output anche quando il testo del thinking non ti viene mai restituito. Un endpoint che in precedenza funzionava senza thinking può quindi produrre, dopo la «correzione», più token di output per richiesta di quanti ne producesse prima. La guida di Anthropic è di ridurre l'effort dove prima disattivavi il thinking e — con effort xhigh o max — di partire con max_tokens a 64k e regolare da lì.

Anche la forma della risposta cambia. Una risposta può iniziare con uno o più blocchi di thinking prima del primo blocco di testo, quindi il codice che legge la risposta in base alla posizione — content[0].text, oppure un gestore di stream che tratta il primo content_block_start come testo — si rompe con queste risposte anche quando la richiesta è andata a buon fine. Seleziona invece i blocchi in base al loro campo type.

2. L'uso forzato dello strumento restituisce un errore

tool_choice tipi any e tool restituiscono un 400, e la stessa validazione si applica all'endpoint di conteggio dei token, quindi un conteggio pre-flight fallisce allo stesso modo della chiamata reale:

• tool_choice: i tipi "tool" e "any" non sono supportati per questo modello.

I valori auto e none non sono interessati. La sostituzione documentata consiste nel mantenere tool_choice: {"type": "auto"}, nel contrassegnare gli strumenti con strict: true per argomenti validi rispetto allo schema, oppure nello spostare lo schema negli output strutturati — e nell'indicare nel prompt quando lo strumento si applica, poiché auto non garantisce una chiamata. L'uso rigoroso degli strumenti accetta un sottoinsieme di JSON Schema: ogni oggetto nell'input_schema di uno strumento deve impostare additionalProperties: false, quindi controlla ogni schema prima di attivare il flag. E nota la lacuna che questo lascia: se il tuo codice dipendeva dal forzare una chiamata anziché dal semplice consentirla, auto ripristina il permesso e non la garanzia. Verifica che sia effettivamente tornato un blocco tool_use.

3. I blocchi di pensiero sono vincolati al modello e alla conversazione

Ogni blocco di pensiero registra quale modello l'ha prodotto, e ciascun modello legge i propri blocchi più un insieme definito di quelli altrui. Le regole valgono in entrambe le direzioni:

• Claude Opus 5.5 legge i blocchi di pensiero provenienti da Claude Opus 5 e dai precedenti modelli Opus, Sonnet e Haiku — ma non da Claude Fable o dai modelli Claude Mythos.

• Sull'API di Claude, Claude Fable 5.1 e Claude Mythos 5.1 leggono i blocchi di Claude Opus 5.5. Nessun altro modello lo fa.

• Una conversazione che passa da Claude Opus 5.5 a qualunque cosa diversa da quei due esegue i suoi turni successivi senza il ragionamento precedente.

Un router o un fallback che sposta una conversazione è il modo più ovvio per incappare in questo. La metà più sottile è che il blocco è vincolato anche al prefisso della conversazione — il prompt di sistema, gli strumenti e ogni messaggio che lo precede. Anthropic applica il controllo del prefisso per impostazione predefinita per gli account creati a partire dal 2026-08-31 00:00 UTC, sull'API di Claude e sulle piattaforme cloud: riprodurre un blocco dopo aver modificato il prompt di sistema, l'elenco degli strumenti o un messaggio precedente fa sì che la richiesta restituisca 400. Esistono due vie di fuga. Invia l'header beta thinking-binding-controls-2026-08-01 e imposta thinking.block_binding.prefix_mismatch_behavior su "drop_block" per eliminare i blocchi interessati invece di far fallire la richiesta. Oppure mantieni la conversazione in sola aggiunta e modifica le istruzioni con un messaggio di sistema a metà conversazione anziché con una modifica — che è ciò che fanno già Claude Code, claude.ai, Claude Managed Agents e l'SDK di Claude Agent.

C'è una buona notizia facile da lasciarsi sfuggire: quando una richiesta contiene un blocco che il modello di destinazione non è in grado di leggere, l'API lo elimina prima che il modello lo veda. La richiesta va a buon fine e i blocchi eliminati non vengono fatturati.

4. Il precedente strumento di utilizzo del computer viene rifiutato sull'API Claude e su Google Cloud

Una voce di strumenti di tipo computer_20251124 restituisce un errore 400 sull'API Claude e su Google Cloud. Il messaggio indica il tipo rifiutato e poi elenca i tipi che il modello accetta:

• 'claude-opus-5-5' non supporta i tipi di strumento: computer_20251124.

Il sostituto è il computer_toolset_20260801 toolset: elimina l'header beta computer-use-2025-11-24, e invia la voce tools senza nome e senza dimensioni di visualizzazione. Non è solo una modifica alla richiesta — anche il ciclo dell'agente cambia di conseguenza. Le azioni arrivano come blocchi tool_use membri anziché come un singolo strumento computer; possono essercene diversi in un turno, e l'azione è il nameanzichéinput.action, e ogni risultato deve rimandare toolset_name indietro. Su Amazon Bedrock, computer_20251124 continua a funzionare esattamente come su Claude Opus 5 e non è necessaria alcuna modifica.

Quali dei quattro si applicano anche a Claude Fable 5.1?

Anthropic afferma che le prime tre valgono anche per Claude Fable 5.1 — thinking sempre attivo, nessuna scelta forzata dello strumento e blocchi di thinking vincolati al modello e alla conversazione. La modifica relativa all'uso del computer no: quella è specifica di questo modello sull'API di Claude e su Google Cloud. Quindi un team che è già passato a Claude Fable 5.1 ha dismesso i propri percorsi di codice con thinking disabilitato e le proprie scelte forzate dello strumento, e adotta un pattern di conversazione in sola aggiunta; ciò che resta è l'id del modello e il set di strumenti per l'uso del computer. Un team che arriva da Claude Opus 5 si trova ad affrontare tutte e quattro contemporaneamente. Questa è la migrazione che vale la pena pianificare, e comporta una mole di lavoro diversa a seconda del punto di partenza.

Il quinto cambiamento: nulla va in errore e il tuo feed dei progressi tace

Su Claude Opus 5, le brevi note che il modello scrive tra una chiamata di strumento e l'altra tornano come normali blocchi di testo. Su Claude Opus 5.5 — come su Claude Fable 5.1 — quella narrazione ritorna come blocchi di pensiero di aggiornamento sullo stato di avanzamento, al massimo uno prima di ogni chiamata di strumento. E thinking.display ha come valore predefinito "omitted", quindi quei blocchi arrivano con un campo thinking vuoto insieme alla loro firma.

Nessuna richiesta fallisce. Nessun errore viene registrato. Un'applicazione che trasmette agli utenti il testo tra uno strumento e l'altro come indicatore di avanzamento semplicemente smette di mostrare l'avanzamento tra una chiamata a uno strumento e l'altra e inizia a non mostrare nulla. Il sintomo visibile è un'interfaccia utente che sembra bloccata proprio durante la fase di lavoro in cui l'utente desidera maggiormente essere rassicurato, e verrà segnalato come un problema di prestazioni, un problema di rete o un blocco — non come un bug di migrazione. Questa è la modifica che arriva in produzione.

La correzione è un'impostazione di visualizzazione, più una lettura che le corrisponde:

• Imposta thinking.display su "updates" — beta, dietro l'header thinking-display-updates-2026-08-18 — per riavere gli aggiornamenti di avanzamento mentre il ragionamento stesso resta nascosto. Questa è l'impostazione che cerca un feed di avanzamento.

• Oppure impostalo su "summarized" per ricevere aggiornamenti sui progressi e riepiloghi del ragionamento mescolati insieme negli stessi blocchi.

• Poi leggi il testo dai blocchi di pensiero anziché dai blocchi di testo, visualizza ogni blocco di pensiero non vuoto prima del blocco tool_use che esso precede e restituisci i blocchi invariati insieme al resto del turno dell'assistente.

La nota di Anthropic stessa al riguardo merita di essere citata nello spirito: ci si aspetta che un'interfaccia che visualizza testo tra le chiamate agli strumenti imposti un valore di visualizzazione anziché affidarsi al valore predefinito. Se oggi la tua integrazione ignora completamente i blocchi di pensiero, quello è l'unico punto in cui il valore predefinito è sicuro.

Lo sforzo è la superficie dell'API

Con il thinking non disattivabile, output_config.effort diventa l'unica manopola su quanto il modello ragiona, e quindi l'unica manopola su costi e latenza per una data attività. Ci sono quattro cose che vale la pena sapere prima di copiare un'impostazione dal vecchio modello.

Il valore predefinito è cambiato. Claude Opus 5.5 usa come impostazione predefinita l'effort medio, mentre Claude Opus 5 e i modelli Opus precedenti usavano come impostazione predefinita quello alto. Una richiesta che omette l'effort ora viene eseguita un livello più in basso rispetto a prima del cambio. Anthropic documenta inoltre che il modello tende a pensare di più per turno a una data impostazione di effort rispetto a quanto facesse Claude Opus 5, soprattutto con xhigh e max. Questi due effetti spingono in direzioni opposte, ed è proprio per questo che l'istruzione del fornitore è di eseguire una nuova sweep dell'effort sulle proprie valutazioni invece di trasferire un'impostazione da un modello all'altro.

La scala è basso / medio / alto / xhigh / max, tutti e cinque supportati qui. Il livello denominato non è, in primo luogo, un budget di token fisso — Anthropic descrive l'impegno come un segnale comportamentale, non un budget rigido — e l'allocazione di token dietro ogni livello è cambiata tra i modelli, quindi "alto" su Claude Opus 5.5 non è "alto" su Claude Opus 5. Impostare l'impegno sul valore predefinito del modello è identico a ometterlo.

Due dettagli operativi, perché entrambi costano denaro quando vengono trascurati. Primo, modificare il valore di effort di livello superiore tra una richiesta e l'altra invalida la cache dei prompt: scegli un livello e mantienilo costante all'interno di una conversazione che si affida ai cache hit, e fallo invece variare tra carichi di lavoro diversi. Secondo, questo modello supporta effort per messaggio (header beta mid-conversation-output-config-2026-07-01), che cambia il livello a partire da un turno successivo senza riavviare la cache. Il minimo della cache dei prompt qui è di 512 token, in calo rispetto ai 1.024 della generazione precedente, quindi i prompt che prima erano troppo brevi per essere messi in cache ora possono creare voci senza alcuna modifica al codice.

Limiti di output: 128K in modalità sincrona, 300K in modalità Batch

L'API Messages sincrona limita l'output a 128K token. L'API Message Batches arriva a 300K token di output dietro l'output-300k-2026-03-24 header beta — esattamente quella stringa. L'input è l'intera finestra di contesto da 1M token per impostazione predefinita, senza che sia richiesto alcun header.

L'interpretazione pratica: il limite di 128K è invariato rispetto a Claude Opus 5, quindi nessun aspetto di un'integrazione sincrona deve essere ridimensionato su questo asse da solo. Ciò che deve essere ridimensionato è il thinking al suo interno. Poiché max_tokens ora copre thinking più testo a ogni richiesta, un valore che era appena sufficiente per il testo di risposta su Claude Opus 5 qui è più stretto — e con effort xhigh o max il fornitore suggerisce di partire da 64k e ottimizzare. Se un job di lunga durata era stato dimensionato in base al limite sincrono di 128K e ora viene troncato, non è il limite che è cambiato.

Il routing di salvaguardia fa parte della specifica.

Questo è un fatto di integrazione, non una nota a piè di pagina di policy: su alcuni prompt, la stringa del modello che invii non descrive ciò che ha risposto.

Claude Opus 5.5 viene fornito con classificatori di sicurezza, e una richiesta rifiutata viene restituita come HTTP 200 con stop_reason: "refusal" e un oggetto stop_details che indica l'area della policy. Questo modello copre più categorie di Claude Opus 5 — aspettati bio, frontier_llm e reasoning_extraction insieme ai familiari cyber. Il rifiuto reasoning_extraction viene bloccato del tutto anziché ritentato: il fallback lato server di Anthropic non lo ritenta, e il rifiuto ti viene restituito.

Per le categorie che effettuano il nuovo tentativo, il meccanismo è un parametro. Imposta fallbacks su "default" con l'header beta server-side-fallback-2026-07-01 e l'API riesegue una richiesta rifiutata sul modello che Anthropic consiglia per quella categoria, all'interno di un'unica chiamata, restituendo un'unica risposta. Il centro assistenza di Anthropic indica direttamente il routing per questo modello: le richieste di cybersecurity segnalate passano a Claude Opus 4.8, e i suoi classificatori di biologia — il set in stile Fable-5 — causano un fallback verso Claude Opus 5 per il lavoro di scienze della vita a duplice uso. Anche un insieme ristretto di capacità di sviluppo di LLM di frontiera viene indirizzato a Claude Opus 5. Anthropic osserva inoltre che i controlli esaminano tutto ciò che il modello legge, non solo il tuo ultimo messaggio, quindi memoria, contenuti dei connettori, risultati di ricerca e file possono attivare un passaggio.

Tre cose conseguono per la tua integrazione. Leggi il campomodel di primo livello su ogni risposta, perché riporta il modello che ha effettivamente prodotto il messaggio, e un blocco di contenuto fallback contrassegna ogni punto di passaggio. Verifica i limiti di frequenza del fallback stesso, perché un fallback soggetto a limiti di frequenza non viene tentato e al suo posto viene restituito il rifiuto — i fallback degenerano in rifiuti sotto carico. E considera qualsiasi esecuzione di benchmark pubblicata con le salvaguardie abilitate come una misurazione del sistema instradato anziché del solo Claude Opus 5.5, che è esattamente ciò che Anthropic afferma riguardo ai propri numeri qui sotto.

Il fallback lato server è in beta e solo per l'API Claude: non è supportato sull'API Message Batches e non è disponibile su Amazon Bedrock, Google Cloud o Microsoft Foundry, dove invece il middleware dell'SDK è il percorso documentato. Sul fronte della verifica, esistono percorsi di accesso per entrambe le categorie — il Cyber Verification Program e il Life Sciences Verification Program — ma si noti l'asimmetria documentata dal centro assistenza di Anthropic al momento in cui scriviamo: Claude Opus 5.5 non è attualmente elencato nel Cyber Verification Program, mentre il programma per le scienze della vita è descritto come in grado di dare alle organizzazioni verificate accesso ai modelli più capaci.

Contesto, cutoff, dismissione e modalità Fast

Il resto dell'envelope, dalla pagina del modello e dalla tabella delle deprecazioni:

• Finestra di contesto — 1M token, predefinita, nessun header beta.

• Data limite delle conoscenze — giugno 2026, che è anche il termine dei dati di addestramento.

• Ritiro — non prima del 2027-09-22 sulle piattaforme gestite da Anthropic, con almeno 60 giorni di preavviso. Amazon Bedrock e Google Cloud stabiliscono le proprie date. Claude Opus 5 è Attivo fino ad almeno il 2027-07-24, quindi non c'è alcun passaggio forzato.

• Listino prezzi — $4,00 per milione di input, $20,00 per milione di output, $5,00 per milione di scritture in cache da 5 minuti, $8,00 per milione di scritture in cache da 1 ora, $0,20 per milione di letture dalla cache. Batch costa la metà in entrambe le direzioni, a $2,00 / $10,00.

• Le letture dalla cache sono l'eccezione che vale la pena notare: $0,20 è il 5% dell'input di base, mentre la maggior parte dei modelli Claude si attesta al 10% e Claude Fable 5.1 al 2,5%. I carichi di lavoro misti con un forte riutilizzo della cache percepiscono tutto ciò come uno sconto reale.

• Modalità veloce — ancora documentata come anteprima di ricerca, solo API Claude, con prezzo separato di 8,00 $ per input / 40,00 $ per output per milione. Attivala con speed: "fast" e l'fast-mode-2026-02-01 header beta. Non è disponibile su Bedrock, Claude Platform su AWS, Google Cloud o Microsoft Foundry, né con la Batch API, né con un impegno Priority Tier. Tieni presente che Claude Opus 5.5 non supporta affatto Priority Tier.

Cosa dicono i benchmark e con quale impostazione

Le impostazioni di effort sono il motivo per cui una tabella del fornitore e una tabella indipendente non possono essere confrontate riga per riga, e per cui ogni numero di seguito riporta la propria impostazione.

Riportato dal fornitore, harness proprietario di Anthropic. La nota di lancio di Anthropic afferma che, salvo diversa indicazione, tutti i risultati di Claude Opus 5.5 utilizzano il pensiero adattivo con massimo impegno; l'eccezione è Terminal-Bench 4.0, riportato a xhigh per Claude Opus 5.5 e a high per GPT-6 Astra, perché quelli sono i punteggi più alti di ciascun modello. Su questa base il fornitore riporta Terminal-Bench 4.0 al 66,4%, FrontierCode v1.1 Main al 54,4%, CursorBench 4.0 al 57,8%, GDPval-AA v2.1 a 1.846 Elo, AutomationBench al 40,0%, Humanity's Last Exam con strumenti al 67,7%, Terminal-Bench-Science 0.1 al 58,7%, OSWorld 2.0 all'81,8% parziale e Chartography con strumenti all'89,0%. Con il livello di impegno medio predefinito del modello, il fornitore riporta FrontierCode al 54,6% e CursorBench al 52,5%. Si noti ciò che la stessa nota rende noto: le valutazioni sono state eseguite con le salvaguardie di produzione abilitate e, quando queste si sono attivate, i compiti di cybersicurezza sono stati completati da Claude Opus 4.8, mentre quelli di biologia e di sviluppo di LLM di frontiera da Claude Opus 5 — Anthropic afferma che ciò probabilmente riduce le prestazioni di Claude Opus 5.5 su quei benchmark. I punteggi pubblicati sulle valutazioni interessate non sono quindi misurazioni pulite di questo modello.

Indipendente, Artificial Analysis. Sull'Intelligence Index v4.3.2, Claude Opus 5.5 ottiene 58 nella configurazione che Artificial Analysis etichetta "Adaptive Reasoning, Max Effort, Default Fallback" — il suo punteggio misurato più alto, superiore di diversi punti, e guida sei delle dieci valutazioni che lo compongono. Sullo stesso indice e con lo stesso harness, Claude Fable 5.1 ottiene 53 e Claude Opus 5 ottiene 51. Artificial Analysis pubblica l'intera scala degli effort, che è l'artefatto indipendente più utile in questo caso: max 58, xhigh 56, high 54, medium 51, low 42. Le sue stesse misurazioni collocano Claude Opus 5.5 a circa 119.000 token di output per task dell'indice con effort massimo, contro circa 73.000 per Claude Opus 5, 78.000 per Claude Fable 5.1 e 27.000 per GPT-6 Astra — token fatturati come token di output — e la sua pagina riporta un costo di 5,98 $ per task dell'indice. Misura inoltre Terminal-Bench 4.0 al 59,6% e Humanity's Last Exam al 61,4%, contro il 66,4% e il 67,7% dichiarati dal fornitore con effort massimo su un harness diverso.

Confronta quei due paragrafi mettendoli l'uno contro l'altro e la conclusione onesta è limitata. Il 66,4% di Terminal-Bench del fornitore e il 59,6% indipendente sono lo stesso benchmark eseguito da persone diverse con impostazioni di cui non è garantita la corrispondenza, e nessuno dei due costituisce una prova relativa al tuo carico di lavoro. La scala dell'effort è il risultato trasferibile: su un indice indipendente, le impostazioni di questo modello stesso coprono sedici punti, una dispersione più ampia del divario tra esso e il suo predecessore. Scegliere un livello di effort conta più che scegliere tra questi modelli, e la clausola "Default Fallback" in quell'etichetta è il routing di salvaguardia descritto sopra, non un artefatto del benchmark.

Efficienza dichiarata dal fornitore, con attribuzione. Anthropic afferma che Claude Opus 5.5 offre prestazioni al livello di Claude Fable 5.1 sulla maggior parte dei lavori, con un costo di esecuzione inferiore di circa il 40%, e che i carichi di lavoro tipici costano all'incirca il 40% in meno rispetto a Claude Opus 5, a fronte di un taglio del prezzo di listino del 20%. L'output è oltre il 30% più veloce. Si tratta di caratterizzazioni del fornitore relative a medie calcolate su carichi di lavoro selezionati dal fornitore stesso. Le dichiarazioni dei clienti al momento del lancio sono lo stesso tipo di prova: Box riporta un terzo dei token e risposte circa il 40% meno prolisse, Kiro all'incirca la metà dei token e circa il 40% in meno di chiamate, Factory il 20–25% in meno di token di output, GitHub tra il minor numero di token e di passaggi che abbia misurato. Anthropic riporta inoltre un test interno di verifica dei fatti in cui 16 dei suoi 18 report hanno superato una soglia di qualità che né Claude Fable 5.1 né Claude Opus 5 hanno raggiunto in alcun tentativo. Tutto quanto è dichiarato dal fornitore e nulla è verificato da terzi. La limitazione dichiarata è insolitamente schietta e vale la pena riportarla: Anthropic afferma che Claude Opus 5.5 «sospetta spesso di essere sottoposto a valutazione».

Infine, i modelli fratelli: Anthropic afferma che Claude Sonnet 5.5 e Claude Haiku 5.5 arriveranno "nelle prossime settimane". Nessuno dei due è stato rilasciato, nessuno dei due ha un prezzo e nessuno dei due è disponibile su alcuna piattaforma oggi.

Testare le quattro modifiche senza un cutover completo

Il rischio di migrazione qui non è la qualità — è che un percorso di codice che non hai mai esercitato in staging è quello che restituisce 400 in produzione. Le quattro modifiche di rottura sono tutte modifiche alla forma della richiesta, il che significa che falliscono in modo deterministico e immediato, e l'unico modo per trovare i percorsi che hai mancato è far passare traffico reale attraverso di essi.

Claude Opus 5.5 è su OrcaRouter come anthropic/claude-opus-5.5 al prezzo di listino di Anthropic con 0% di ricarico — il prezzo di listino del provider viene trasferito tal quale, quindi una variazione di prezzo del fornitore è attiva qui lo stesso giorno.

Questo ti consente di indirizzare una percentuale del traffico di produzione verso il modello mentre il resto continua a girare su Claude Opus 5, osservare quali richieste falliscono e perché, e correggerle una alla volta. I quattro errori si descrivono da soli: ciascuno indica il parametro che ha rifiutato e, in tre casi su quattro, la sua sostituzione. Il failover automatico copre la lacuna finché un percorso è ancora rotto — una richiesta che fallisce su un modello che non hai caratterizzato appieno ripiega su uno che conosci, invece di mostrare il 400 a un utente.

Un ordine di lavoro pratico: per prima cosa cambia l'id del modello e imposta effort in modo esplicito, dato che il valore predefinito è passato a medium; poi rimuovi i percorsi thinking-disabled e forced-tool-choice; quindi correggi il lettore in streaming — la selezione dei blocchi per tipo e l'impostazione thinking.display — perché è quello che fallisce in silenzio anziché in modo evidente; e lascia per ultima la migrazione del toolset computer-use se sei su Bedrock, dato che è quella che non si applica lì. Tutto il resto — prezzo, finestra di contesto, tariffe di cache e il valore predefinito di 1M token — è già dove l'hai lasciato.

Instrada una quota di traffico live verso il nuovo modello senza un passaggio completo: Claude Opus 5.5 su OrcaRouter viene eseguito al prezzo di listino di Anthropic con failover automatico verso un modello che hai già caratterizzato.