Passa al contenuto principale

Claude Sonnet 5.5: la guida sul campo

Intermedio

Il 28 settembre 2026 Anthropic ha rilasciato Claude Sonnet 5.5 (claude-sonnet-5-5) — il secondo modello della famiglia 5.5, dopo Opus 5.5 di sei giorni prima. Il listino è la parte interessante proprio perché non si è mosso: 2 $ in / 10 $ out per MTok, identici byte per byte ai prezzi di Sonnet 5, stesso tokenizer, stesse tariffe di cache e batch. La dichiarazione di Anthropic è comunque: output oltre il 30% più veloce e fino al 30% in meno per task.

Entrambe le cose possono essere vere insieme, e capire perché è il senso di questa pagina: su Sonnet 5.5 il risparmio vive nel conteggio dei token e nel numero di turni, mai nel prezzo per token. Questo cambia cosa misuri, e cambia quale manopola tocchi per prima.

La seconda cosa da sapere fin dal primo giorno: il modello economico non è uniformemente indietro rispetto a quello costoso. Su Terminal-Bench 4.0 Sonnet 5.5 segna 70,6% contro il 66,4% di Opus 5.5 — l'unica riga pubblicata in cui il modello a metà prezzo è avanti. E sull'Elo del lavoro di conoscenza i due sono in parità statistica. Il divario che resta è concentrato in un punto preciso, e questa pagina dice dove.

What you'll learn
  • Conoscere i numeri reali: 2/10 $ per MTok invariati rispetto a Sonnet 5, contesto 1M, output massimo 128K (300K su Batches), cutoff giugno 2026, effort predefinito high
  • Correggere le cinque breaking change che restituiscono 400 su una codebase Sonnet 5, e la sesta che restituisce 200 e fa ammutolire la tua UI di avanzamento
  • Usare between_tools correttamente — il sostituto di thinking disabled, rifiutato a effort xhigh e max e incompatibile con ogni campo accessorio
  • Leggere onestamente la tabella di lancio: dove Sonnet 5.5 batte Opus 5.5, dove è 8 punti indietro, e perché una riga segna 10,3%
  • Ricalibrare l'effort da zero invece di riportare l'impostazione precedente, e recuperare circa 1/3 del costo di sessione che max effort spende in review auto-avviate
  • Gestire i fallimenti più silenziosi: richieste con structured output che pensano fino a max_tokens, nomi di tool sbagliati nel maiuscolo/minuscolo, e messaggi utente reali scambiati per prompt injection

Specifiche, e i quattro numeri cambiati​

Sonnet 5Sonnet 5.5Opus 5.5
ID Claude APIclaude-sonnet-5claude-sonnet-5-5claude-opus-5-5
Input / output per MTok2 $ / 10 $2 $ / 10 $4 $ / 20 $
Lettura cache / scrittura 5m0,20 $ / 2,50 $0,20 $ / 2,50 $0,20 $ / 5 $
Prompt minimo memorizzabile in cache1.024 token512 token—
Contesto1M1M1M
Output massimo (sync)128K128K128K
Impostazioni di thinking accettateadaptive, disabledadaptive, between_toolssolo adaptive
Effort predefinitohighhighmedium
Knowledge cutoff affidabile—giu 2026giu 2026
Ritiro non prima di—28 set 202722 set 2027

Quattro cose in quella tabella sono davvero nuove, e solo una di esse è un titolo da qualche parte:

  1. Il prompt minimo memorizzabile in cache si è dimezzato, 1.024 → 512 token. Se il tuo system prompt sta nella fascia 600–1.000 token, su Sonnet 5 era silenziosamente non memorizzabile e ora lo è, al 10% del prezzo di input in lettura. Nessuna modifica al codice, nessun header beta. È la vittoria più facile di tutta la pagina.
  2. thinking: {"type": "disabled"} non esiste più, sostituito da between_tools. Sonnet 5.5 sta fra Sonnet 5 (che accettava disabled) e Opus 5.5 (che non accetta nessuno dei due) — può ancora saltare il thinking iniziale, solo con un nuovo nome e nuovi limiti.
  3. L'effort predefinito è rimasto high — nota che è più alto del medium predefinito di Opus 5.5. Il modello più economico pensa più per turno, di default, di quello costoso.
  4. temperature, top_p e top_k restituiscono 400 a qualsiasi valore diverso dal predefinito, come nel resto della linea 5.x. Le sweep sui parametri di campionamento non sono una superficie di tuning qui; l'effort sì.

Il tokenizer è invariato rispetto a Sonnet 5, quindi lo stesso testo produce gli stessi conteggi di token. Qualsiasi cambiamento che misuri in fattura è un cambiamento in quanti token il modello ha scelto di emettere.

Perché la fattura cala anche se il prezzo no​

È la parte che gran parte della copertura del lancio comprime in "30% più economico", sbagliando in modo sottile. Il listino è identico. La dichiarazione di Anthropic si scompone in tre effetti separati, e non sono ugualmente facili da catturare:

Guided walkthrough1 of 3
  1. L'output è il lato costoso, a 10 $/MTok contro 2 $ di input. Sonnet 5.5 arriva allo stesso risultato con meno token di output di Sonnet 5, e questo include i token di thinking — il thinking è fatturato come output anche quando il suo testo non ti viene mai restituito. Questo effetto lo ottieni gratis, sullo stesso codice.

Gli effetti 1 e 2 sono esattamente quelli che un'impostazione effort riportata dal passato può annullare. Per questo la sezione successiva è quella da leggere prima di cambiare il tuo model ID.

Effort: ricalibra, non riportare​

Anthropic è esplicita sul fatto che i livelli di effort sono stati ricalibrati — un livello non compra la stessa quantità di thinking che comprava su Sonnet 5. Non esiste una tabella di conversione, per scelta. Rifai la tua sweep.

I punti di partenza pubblicati non coincidono con il default:

Carico di lavoroParti daPerché
Generale / nel dubbiohighÈ il default dell'API.
Coding agentico, uso di tool multistep, ben specificatomediumPoi passa a high per task più difficili o più lunghi.
Chat, sensibile alla latenzamedium o lowPiù effort significa attesa più lunga prima che la risposta inizi.
Qualsiasi cosaxhigh / maxSolo dove hai misurato un guadagno di qualità.

Tre conseguenze che mordono in produzione:

  • Cambiare l'effort di primo livello fra una richiesta e l'altra invalida la cache del prompt. Se vuoi una sessione interattiva economica che scala sui turni difficili, usa la beta effort per messaggio (output_config.effort su un singolo messaggio), che preserva la cache. Questa beta è nuova su 5.5 e non era disponibile su Sonnet 5.
  • max_tokens deve coprire il thinking più la risposta. Il thinking conta contro di esso anche quando il testo del thinking è omesso dalla risposta. Un limite dimensionato per una richiesta senza thinking tronca. Per il coding agentico la linea guida di Anthropic è netta: imposta max_tokens a 128.000 e usa lo streaming.
  • Chiedere al modello di pensare di meno non funziona in modo affidabile. Abbassare il livello di effort sì. Da medium in su pensa prima di quasi ogni risposta; a low salta il thinking sulla maggior parte delle richieste semplici.

La tassa di review al massimo effort​

A xhigh e max, Sonnet 5.5 non si ferma quando il task è finito. Avvia round di review e verifica per conto proprio, e se il tuo harness offre subagent lancerà subagent revisori — senza che nessuno glielo abbia chiesto. Anthropic ha pubblicato il rimedio e, cosa insolita, la sua entità: nei loro test su task di coding a effort max, il paragrafo qui sotto ha ridotto il costo di sessione di circa un terzo senza alcun cambiamento di qualità.

Fermare i round di review auto-avviati a effort xhigh e max

When the work the user asked for is done and its checks pass, stop and report. Don't start extra
rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user
asked for a review. If you think a deeper review is worth doing, say so at the end.

Rende le review auto-avviate più rare, non impossibili. Il problema speculare esiste in fondo alla scala: a low e medium su task agentici lunghi il modello è più propenso a fermarsi e chiedere conferma prima di finire, e a low a volte riporta una modifica al codice come fatta senza aver eseguito un controllo che la eserciti.

Le cinque breaking change​

Ognuna di queste restituisce HTTP 400 invalid_request_error su codice che funzionava su Sonnet 5.

1. disabled → between_tools​

thinking: {"type": "disabled"} restituisce 400 con un messaggio che nomina il suo sostituto:

"thinking.type.disabled" is not supported for this model. Use "thinking.type.between_tools" for the
lowest thinking setting, or "thinking.type.adaptive" and "output_config.effort" to control thinking
behavior.

between_tools è l'impostazione di thinking più bassa su Sonnet 5.5. Non richiede header beta e funziona su ogni piattaforma che offre il modello. Ma è più schizzinoso di quanto disabled sia mai stato:

  • Accettato a low, medium, high. A xhigh o max restituisce 400 — quei livelli richiedono thinking adattivo (ometti thinking, oppure invia thinking: {"type": "adaptive"}; sono equivalenti).
  • L'effort non può cambiare a metà conversazione. Un output_config.effort per messaggio diverso dal livello in vigore restituisce 400. L'effort per turno richiede thinking adattivo.
  • Non accetta campi accessori. display, budget_tokens o block_binding inviati insieme a esso restituiscono 400. Anche i budget manuali (thinking: {"type": "enabled", "budget_tokens": N}) restituiscono 400.
  • Con il fallback lato server, una richiesta between_tools che ricade su Sonnet 5 lì gira con thinking: {"type": "disabled"} — le impostazioni vengono mappate attraverso il fallback per te.

Un'altra trappola: con between_tools, rimuovi ogni istruzione che dica al modello di non pensare. Quelle righe rendono più probabile che scriva tag XML interni nel suo output visibile.

Migrare un'integrazione con thinking disattivato — da Sonnet 5 a Sonnet 5.5

# Before — accepted on Sonnet 5
client.messages.create(
  model="claude-sonnet-5",
  max_tokens=16000,
  thinking={"type": "disabled"},
  output_config={"effort": "xhigh"},      # fine with disabled on Sonnet 5
  messages=[{"role": "user", "content": "..."}],
)

# After — on Sonnet 5.5: rename the type AND drop effort to high or below
client.messages.create(
  model="claude-sonnet-5-5",
  max_tokens=16000,
  thinking={"type": "between_tools"},     # xhigh/max with this -> 400
  output_config={"effort": "high"},
  messages=[{"role": "user", "content": "..."}],
)

# If you need xhigh or max, use adaptive thinking instead of between_tools:
#   thinking={"type": "adaptive"}   (or omit the field entirely)

# SDKs that predate between_tools fail type checking on the literal.
# Update the SDK, or pass the value as raw JSON.

2. L'uso forzato dei tool è rifiutato​

tool_choice impostato a {"type": "any"} o {"type": "tool", "name": "..."} restituisce 400:

tool_choice: type "tool" and "any" are not supported for this model.

auto (il default) e none funzionano ancora. Lo stesso controllo si applica all'endpoint di conteggio token, facile da mancare in una suite di test che esercita solo /v1/messages.

L'uso forzato dei tool faceva due lavori; separali:

  • La validità dello schema viene dallo strict tool use (strict: true sul tool) o dagli structured output.
  • Lo steering — far sì che il modello chiami davvero il tool — viene dal prompt che dice quando il tool si applica.

3. I blocchi di thinking sono legati al modello, alla conversazione e all'account​

Ogni blocco di thinking registra quale modello lo ha prodotto, e i modelli leggono solo i blocchi di alcuni altri modelli. Il grafo è asimmetrico e non intuitivo:

Blocchi prodotti daSonnet 5.5 può leggerli?
Sonnet 5.5 stessoSì
Sonnet 5, Opus 4.8, Haiku 4.5 e precedentiSì
Opus 5, Opus 5.5No
Qualsiasi modello Fable o MythosNo

E nella direzione opposta: nessun altro modello legge i blocchi di thinking di Sonnet 5.5. Quindi una conversazione che migra verso l'alto da Sonnet 5 a Sonnet 5.5 conserva il suo ragionamento; una conversazione che si sposta via da Sonnet 5.5 verso qualsiasi altra cosa — incluso Opus 5.5, un percorso di escalation allettante — esegue ogni turno successivo senza di esso. I blocchi illeggibili vengono scartati prima che il modello li veda, la richiesta va a buon fine, e i blocchi scartati non vengono fatturati. Con l'header beta thinking-binding-controls-2026-08-01 gli scarti sono dettagliati in un array di primo livello input_transformations.

Sopra a questo si aggiungono altri due vincoli:

  • Prefisso della conversazione. L'API controlla se il prompt system, la lista tools o un qualsiasi messaggio precedente sono cambiati da quando un blocco di thinking di Sonnet 5.5 è stato prodotto. Lo impone per impostazione predefinita per gli account creati dal 31 agosto 2026, 00:00 UTC in poi su Claude API, Bedrock e Google Cloud — riproporre un blocco dopo una modifica del genere restituisce 400. Per scartare i blocchi interessati invece di fallire, invia thinking-binding-controls-2026-08-01 e imposta thinking.block_binding.prefix_mismatch_behavior a "drop_block". Nota che block_binding funziona solo con il thinking adattivo; sotto between_tools le uniche opzioni sono una cronologia in sola aggiunta oppure rimuovere i blocchi di thinking dal turno modificato in avanti.
  • Account. I blocchi di thinking di Sonnet 5.5 funzionano solo nell'account che li ha prodotti, o in uno collegato. Un altro account che li invia se li vede scartare, con reason: "organization_binding_mismatch" sotto la beta binding-controls. I blocchi dei modelli precedenti non sono interessati.
Guided walkthrough1 of 5
  1. Claude Code, claude.ai, Claude Managed Agents e il Claude Agent SDK lo fanno già. Le integrazioni in sola aggiunta non richiedono modifiche.

4. computer_20251124 è rifiutato — su due piattaforme su tre​

Su Claude API e Google Cloud, Sonnet 5.5 supporta il computer use solo tramite il toolset computer_toolset_20260801. Dichiarare il vecchio tool computer_20251124 restituisce 400:

'claude-sonnet-5-5' does not support tool types: computer_20251124.

Su Amazon Bedrock, Sonnet 5.5 accetta ancora computer_20251124. Quell'asimmetria è il tipo di cosa che fa passare la CI di un deployment multi-piattaforma su un cloud e fallire su un altro. Migrare significa: togliere il vecchio header beta, sostituire la voce in tools con {"type": "computer_toolset_20260801"}, e aggiornare il loop dell'agente per i blocchi tool_use membro, le azioni batch e il toolset_name nei risultati. Le integrazioni già sul toolset, e qualsiasi cosa usi il browser use tool, non richiedono modifiche.

5. Gli abbinamenti advisor si sono ristretti​

Con il tool advisor (beta), un executor Sonnet 5.5 accetta come advisor Mythos 5.1, Fable 5.1, Mythos 5, Fable 5, Opus 5.5, Opus 5 o Sonnet 5.5 stesso. Opus 4.8, Opus 4.7 e Sonnet 5 vengono rifiutati con 400 — tutti e tre funzionavano come advisor per un executor Sonnet 5. Ogni advisor che Sonnet 5.5 accetta restituisce il proprio consiglio cifrato, come blocco advisor_redacted_result, quindi il tuo client non può leggere il testo del consiglio.

La sesta modifica: HTTP 200, e la tua UI ammutolisce​

Questa non fa fallire nulla ed è quella che più probabilmente arriva ai tuoi utenti prima che ai tuoi log.

Fra una chiamata a tool e l'altra, Sonnet 5.5 scrive note rivolte all'utente su cosa ha appena trovato e cosa sta per fare. Le note più lunghe di una frase o due ora tornano come blocchi thinking di progress update; le osservazioni più brevi restano text. Al valore predefinito display: "omitted" il campo di testo di un blocco progress update è vuoto. Un client che renderizza solo i blocchi text quindi non mostra nulla durante un lungo turno agentico — nessun errore, nessun avviso, solo silenzio dove prima c'era la narrazione.

Tre vie d'uscita, in ordine di quanto poco lavoro richiedono:

  1. Usa between_tools. Le note tornano con il loro testo di riepilogo, senza bisogno di alcun campo display (e nessuno viene accettato).
  2. Imposta display: "updates" con l'header beta thinking-display-updates-2026-08-18. Ottieni un breve riepilogo di ogni progress update mentre il ragionamento resta nascosto.
  3. Dai al modello un tool per inviare un messaggio all'utente, per i casi in cui deve mostrare testo esatto a metà turno — uno snippet di codice, una domanda a cui gli serve risposta. Digli di usare quel tool solo per contenuti del genere, e dichiara il tool nella prima richiesta così che tools non cambi più in seguito.

Poi fai pulizia attorno: elimina istruzioni come "tieni tutti i risultati per la risposta finale", e se vuoi aggiornamenti in punti prevedibili, chiedili esplicitamente — una riga prima della prima chiamata a tool, un riepilogo alla fine. Il modello lo segue.

Se i turni lunghi restano comunque silenziosi, il tuo harness può dare una spinta — con attenzione. Conta i passi consecutivi con chiamate a tool che non hanno inviato testo all'utente, e dopo parecchi (diciamo cinque) aggiungi un promemoria valido per un turno dopo gli ultimi risultati dei tool, come messaggio di sistema con ambito di turno:

Spinta dell'harness per un turno agentico silenzioso

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

Fermati dopo il secondo o il terzo se non attecchisce. Testo frequente dell'harness dopo i risultati dei tool porta il modello a sospettare una prompt injection — che è la sezione successiva. Poiché il promemoria è aggiunto in coda invece che inserito e poi rimosso, sia la cache del prompt sia il thinking preservato sopravvivono. La misurazione di Anthropic: a effort high con un tool per messaggiare l'utente disponibile, questo accorcia i tratti silenziosi più lunghi senza cambiamenti misurabili nella qualità del task.

Leggere onestamente la tabella di lancio​

BenchmarkSonnet 5Sonnet 5.5Opus 5.5Sonnet 5.5 come % di Opus 5.5
Terminal-Bench 4.010,3%70,6%66,4%106%
GDPval-AA v2.1 (Elo)14491844184699,9%
AA-Briefcase v1.1 (Elo)13591811182299,4%
OSWorld 2.1 (credito parziale)—80,1%81,8%98%
CursorBench 4.034,1%55,5%57,8%96%
Chartography (senza tool)—61,6%64,4%96%
Humanity's Last Exam (con tool)54,9%64,5%67,7%95%
FrontierCode 1.1 (max effort)42,4%46,2%54,4%85%

Quattro letture oneste di quella tabella:

  • Il divario non è uniforme, e mediarlo via nasconde il segnale utile. Sull'Elo del lavoro di conoscenza i due modelli sono dentro il rumore l'uno dell'altro. Sul benchmark di coding più difficile, FrontierCode 1.1, Sonnet 5.5 è 8,2 punti indietro — l'85% di Opus 5.5. Quella singola riga è la base onesta dell'inquadratura di Anthropic stessa, per cui Opus 5.5 resta nettamente più forte sul lavoro complesso e aperto che richiede giudizio prolungato.
  • Terminal-Bench 4.0 è l'unica riga in cui il modello a metà prezzo vince, 70,6% contro 66,4%. Quel benchmark è il proxy pubblicato più vicino a "fai girare un agente in una shell finché il lavoro non è finito", che è esattamente dove meno chiamate a tool e meno token si sommano.
  • Tratta il 10,3% di Sonnet 5 su Terminal-Bench 4.0 con sospetto, non con stupore. Un salto generazionale di 60 punti su una versione di un benchmark ti dice almeno tanto sull'harness e sulla versione di scoring quanto sul modello. Usalo per concludere "questa versione di questo benchmark penalizza il comportamento agentico di Sonnet 5", non "Sonnet 5.5 è sette volte migliore nel coding agentico".
  • Le fonti sono in disaccordo su FrontierCode in cima alla scala di effort. La tabella di Anthropic riporta 46,2% a effort max; almeno un aggregatore riporta un 52,1% più alto a xhigh. Non siamo riusciti a confermare la seconda cifra contro la tabella primaria, quindi leggila come non verificata — ma nota che "più effort ha ottenuto meno" è coerente con il consiglio della documentazione stessa di riservare xhigh e max ai casi in cui hai misurato un guadagno, invece di dare per scontato un miglioramento monotono.

La misurazione indipendente, come sempre, atterra più in basso di quella del vendor sui benchmark agentici. Fai le tue valutazioni prima di mettere un numero su una slide.

I fallimenti silenziosi​

Nessuno di questi solleva un errore. Tutti ti costano accuratezza o fiducia.

Structured output che pensano fino a esaurirsi​

Chiedi una risposta in JSON a un task che richiede qualche passaggio di ragionamento — sommare cifre da un documento, applicare una regola, ordinare elementi — e Sonnet 5.5 spesso risponde senza pensare prima, specialmente a effort low e medium. Con gli structured output il testo della risposta contiene solo il JSON, quindi il ragionamento non ha dove andare se non nel thinking; salta il thinking e l'accuratezza cala.

  • Con il thinking adattivo, aggiungere Think the problem through before you answer. al system prompt porta l'accuratezza a effort high vicino a quella di xhigh, con un aumento modesto dei token di output.
  • between_tools è l'impostazione sbagliata per queste richieste: senza tool in gioco significa nessun thinking, e quella riga non ha effetto.
  • A low e medium con gli structured output, il modello a volte continua a pensare finché non raggiunge max_tokens. Tratta qualsiasi risposta con stop_reason: "max_tokens" come fallita e riprova, anche quando il suo testo contiene per caso JSON valido. Questo è il modo più probabile in assoluto di spedire un numero sbagliato con sicurezza.

Se non puoi usare gli structured output e chiedi JSON nel prompt, il modello tende a svolgere il problema nel testo della risposta e a mettere il JSON alla fine. Non tagliare dalla prima { all'ultima } — a volte scrive una bozza prima della risposta finale e catturesti entrambe.

Estrarre il valore JSON finale da una risposta mista

# Read only text blocks. Treat stop_reason == "max_tokens" as a failure and retry.
# Starting at each { or [, try to parse a JSON value; continue from the END of a value
# that parses, so values nested inside it are not counted on their own. Keep the LAST one.

import json

def last_json_value(text):
  dec, best, i = json.JSONDecoder(), None, 0
  while i < len(text):
      if text[i] in "{[":
          try:
              value, end = dec.raw_decode(text, i)
          except ValueError:
              i += 1
              continue
          best, i = value, end          # jump past it: skip nested values
      else:
          i += 1
  return best

# Then check the fields you expect are present, and retry once if they are not.

Messaggi utente reali letti come prompt injection​

Sonnet 5.5 è addestrato a resistere alla prompt injection indiretta — istruzioni che arrivano attraverso i risultati dei tool e altri contenuti che legge durante il task. A volte classifica male un messaggio utente genuino in quel modo, dice all'utente che il risultato del tool conteneva testo che si spacciava per un messaggio da parte sua, e o lo ignora o chiede conferma. Il fattore scatenante è la posizione: testo che arriva subito dopo i risultati dei tool, specialmente a ogni passo.

  • Non mettere mai testo dell'utente dentro un blocco tool_result. È la posizione che legge male più spesso.
  • Consegna l'input utente di metà turno come turno utente: aggiungi le sue parole come blocco di testo nel messaggio utente che porta i blocchi tool_result, dopo l'ultimo tool_result.
  • Tieni gli avvisi dell'harness in un messaggio di sistema di metà conversazione separato, dopo le parole dell'utente. Non mettere mai un avviso e le parole dell'utente nello stesso blocco.
  • Elimina il tuo conto alla rovescia di token/budget dopo i risultati dei tool nelle sessioni interattive in cui gli utenti possono scrivere a metà turno. Un conto alla rovescia a ogni passo è la causa classica. La beta Task budgets aggiunge un conto alla rovescia simile ma non è mai stata osservata causare questa lettura errata.

Nomi di tool sbagliati nel maiuscolo/minuscolo​

Sonnet 5.5 ogni tanto chiama un tool dichiarato con un nome che differisce solo per maiuscole e minuscole — bash invece di Bash — o passa un parametro noto sotto un nome leggermente diverso. Non trattarlo come fatale. O accetti la chiamata quando la corrispondenza è inequivocabile, o restituisci un tool_result con is_error: true che indica il nome esatto atteso; di solito il modello si corregge al turno successivo.

Grafici: dagli i tool prima di dargli effort​

Per grafici densi e disegni tecnici, dai al modello un modo di ritagliare, zoomare o eseguire codice sull'immagine. Il risultato misurato vale la pena interiorizzarlo: con i tool a effort high ha letto i grafici più accuratamente che senza tool a effort max, a una frazione del costo. Sui disegni tecnici i tool aiutano solo da high in su, e soprattutto a xhigh e max. Punta al tool, non alla manopola.

Rifiuti: cinque categorie, e solo due vengono ritentate​

Una richiesta declinata è HTTP 200 con stop_reason: "refusal" e un oggetto stop_details che nomina la categoria. Sonnet 5.5 è il primo Sonnet a uscire con salvaguardie cyber paragonabili a quelle dei modelli più capaci di Anthropic, e il primo con classificatori che bloccano l'estrazione del ragionamento.

Categoria stop_detailsCosa copreIl fallback lato server la ritenta su Sonnet 5?
cyberPotrebbe abilitare danni cyber — malware, sviluppo di exploit. Trovare vulnerabilità nel codice sorgente è consentito; il lavoro dual-use ad alto rischio no.Sì
frontier_llmPotrebbe aiutare lo sviluppo di modelli di IA concorrenti.Sì
bioPotrebbe abilitare danni biologici. Domande quotidiane di salute ed educative non sono toccate.No
reasoning_extractionChiede al modello di riprodurre il suo ragionamento interno nel testo della risposta.No
general_harmsUn'altra area della policy d'uso. Anche lavoro benigno può farla scattare.No

Due note pratiche. Primo, se i tuoi prompt chiedono al modello di includere il suo ragionamento nella risposta, rimuovi quelle righe — invitano i rifiuti reasoning_extraction. Leggi il ragionamento dai blocchi di thinking riassunti (display: "summarized") invece. Secondo, se un rifiuto che arriva prima di qualsiasi output venga fatturato dipende dalla sua categoria, e conta comunque contro i tuoi rate limit.

Il lavoro legittimo nelle scienze della vita bloccato dal classificatore bio può candidarsi al Life Sciences Verification Program di Anthropic.

Quindi quale modello fai girare davvero?​

Guided walkthrough1 of 5
  1. Task quotidiani, bug fix, uso di tool multistep, documenti e fogli di calcolo rifiniti. Parti da effort medium per il coding agentico, high per il lavoro generale, e misura. A 2/10 $ con contesto 1M è il modello più economico della lineup ancora vicino alla frontiera sul lavoro di conoscenza.

La migrazione in sé è uno scambio di model ID più sei controlli, e Anthropic spedisce un'automazione per farlo: in Claude Code, /claude-api migrate this project to claude-sonnet-5-5 applica lo scambio di ID e le modifiche ai parametri che rompono, su tutta una codebase, e ti consegna una checklist di cosa verificare a mano. Ti chiede di confermare l'ambito prima di modificare qualsiasi cosa. Se usi Claude Managed Agents invece della Messages API diretta, il nome del modello è l'unica modifica richiesta.

Premi Invio o Spazio per girare la carta. Usa le frecce sinistra e destra per spostarti tra le carte.Termine mostrato.
1 / 10

Check yourself

0/6
  1. Sonnet 5.5 costa esattamente quanto Sonnet 5 — 2/10 $ per MTok, stesse tariffe di cache, stesso tokenizer. Anthropic sostiene comunque fino al 30% in meno per task. Da dove arriva il risparmio?
  2. La tua integrazione gira su Sonnet 5 con thinking: {"type": "disabled"} e output_config effort "xhigh". Qual è la modifica minima corretta per Sonnet 5.5?
  3. Dopo aver migrato un prodotto di chat a Sonnet 5.5, gli utenti segnalano che l'assistente sembra bloccato durante i turni lunghi con uso di tool, anche se la risposta finale arriva regolarmente e nei log non compaiono errori. Cos'è successo?
  4. Arriva un turno difficile in una conversazione con Sonnet 5.5 e vuoi più profondità. Quale opzione preserva il ragionamento accumulato fin qui?
  5. Usi gli structured output a effort medium per estrarre totali dalle fatture. Una risposta torna con stop_reason "max_tokens" ma il suo testo si interpreta come JSON valido con cifre plausibili. Cosa dovrebbe fare il tuo codice?
  6. Quale affermazione sulla tabella dei benchmark di lancio è accurata?

Prossimi passi​

Fonti e approfondimenti​