Passa al contenuto principale

Claude Sonnet 5: la guida sul campo

Intermedio

Il 30 giugno 2026 Anthropic ha rilasciato Claude Sonnet 5 (claude-sonnet-5) e, silenziosamente, lo ha reso il modello di default in Claude Code. Sulla carta è un drop-in per Sonnet 4.6 allo stesso prezzo di listino. In pratica, tre vincoli API faranno restituire 400 Bad Request alle migrazioni ingenue, un nuovo tokenizer produce circa il 30% di token in più per lo stesso testo (il che cambia sia il tuo budget di contesto sia il conto per richiesta), e la scala di effort è cambiata abbastanza da far sì che "tieni tutto uguale" non sia più la stessa cosa. Se stavi su Sonnet 4.6 a high, far girare Sonnet 5 a high è più vicino a Sonnet 4.6 a max.

Questa pagina è la guida pratica sul campo: cosa è cambiato, cosa si rompe, la checklist di migrazione esatta, la matematica del pricing sullo shift del tokenizer e i pattern di prompting che la maggior parte dei team ricalibra per primi.

What you'll learn
  • Capire cosa sia davvero Sonnet 5 — 1M di contesto di default, adaptive thinking attivo di default, primo Sonnet con safeguard di cybersecurity in tempo reale
  • Conoscere i tre vincoli API che faranno restituire 400 al tuo codice esistente e la fix in una riga per ciascuno
  • Modellare la matematica del pricing con il nuovo tokenizer: stesso $/token ma ~30% di token in più = conto per richiesta diverso
  • Ricalibrare i livelli di effort: Sonnet 5 medium ≈ Sonnet 4.6 high, e Sonnet 5 high ≈ Sonnet 4.6 max
  • Adeguare i pattern di prompting che cambiano di più: verbosity, triggering degli strumenti, recall nella code review e default di design

La versione in un paragrafo​

Sonnet 5 è il tier Sonnet bilanciato "parti da qui", posizionato sopra Sonnet 4.6 allo stesso prezzo di listino e ora il default di Claude Code. Supporta di default la finestra di contesto da 1M token (non c'è una variante con contesto più piccolo), 128k di output massimo e adaptive thinking attivo di default. Tre contratti API si rompono nella migrazione: l'extended thinking manuale (thinking: {type: "enabled", budget_tokens: N}) è rimosso e restituisce 400, i parametri di sampling non-default (temperature, top_p, top_k) restituiscono 400, e il tokenizer è cambiato — lo stesso testo di input produce circa il 30% di token in più rispetto a Sonnet 4.6. Il Priority Tier non è disponibile su Sonnet 5. Questa è tutta la forma del rilascio.

Perché "drop-in" ha bisogno di un asterisco​

I documenti ufficiali Anthropic descrivono Sonnet 5 come un "drop-in replacement per Claude Sonnet 4.6" — e per il contenuto dei prompt è vero. Ma la superficie API è cambiata abbastanza che "cambia la stringa del modello e spedisci" produrrà errori su richieste che ieri funzionavano bene. Ci sono quattro cose che ti morderanno, in ordine di quanto spesso vediamo rompersi le integrazioni:

  • temperature, top_p o top_k impostati su valori non-default ora restituiscono 400. Non ignorati silenziosamente. Non clippati. Un errore hard. Questo è nuovo per i modelli classe Sonnet; Opus 4.7 ha introdotto lo stesso vincolo. Se il tuo wrapper SDK invia sempre temperature: 0.7, ora fallirà sempre.
  • L'extended thinking manuale è rimosso. thinking: {type: "enabled", budget_tokens: N} era deprecato su 4.6 e restituisce 400 su Sonnet 5. Usa adaptive thinking con il parametro effort al suo posto.
  • L'adaptive thinking è attivo di default. Le richieste senza un campo thinking su Sonnet 4.6 giravano senza thinking; su Sonnet 5 girano con adaptive thinking. max_tokens è un cap hard sull'output totale — thinking più testo di risposta — quindi un limite dimensionato per "solo la risposta" su Sonnet 4.6 può troncare la risposta su Sonnet 5.
  • Il nuovo tokenizer produce circa il 30% di token in più per lo stesso testo. Non è un cambio API — le shape di richiesta e risposta sono identiche — ma tutto ciò che misuri o budgeti in token ora misura di più.

I vincoli API che ti restituiranno 400​

Guided walkthrough1 of 4
  1. Rimuovi qualsiasi temperature, top_p o top_k che non sia il default API. Se la tua app ha bisogno di varietà stilistica, usa istruzioni nel system prompt al posto di temperature (ora è l'unica leva). Se ti servono output di design diversi, chiedi al modello di proporre N direzioni distinte e sceglierne una — questo ti dà varietà tra run anche con sampling fisso.

Migrazione minima sicura — un diff

# Before (Sonnet 4.6) — worked
response = client.messages.create(
  model="claude-sonnet-4-6",
  max_tokens=4096,
  temperature=0.7,                          # 400 on Sonnet 5
  thinking={"type": "enabled",
            "budget_tokens": 8000},         # 400 on Sonnet 5
  messages=[...],
)

# After (Sonnet 5) — one-liner replacements
response = client.messages.create(
  model="claude-sonnet-5",
  max_tokens=8192,                          # raise: thinking now shares the budget
  # temperature removed — use system prompt instead
  # thinking removed — adaptive is on by default
  extra_body={"effort": "high"},            # was implicit in budget_tokens
  messages=[...],
)

Lo shift del tokenizer è una storia di pricing, non una storia di API​

Il nuovo tokenizer è il cambiamento che con più probabilità sorprenderà il tuo team finance. Le richieste e le risposte appaiono identiche sul filo, ma lo stesso testo di input produce circa il 30% di token in più rispetto a Sonnet 4.6. Il moltiplicatore esatto dipende dal contenuto — codice, prosa inglese, testo non-inglese e dati strutturati shiftano tutti diversamente — ma 30% è il numero che Anthropic cita.

Tre cose che questo cambia contemporaneamente:

  • Costo per richiesta. Il pricing per token è invariato rispetto a Sonnet 4.6 a $3 / $15 per MTok standard (e $2 / $10 fino al 31 agosto 2026). Ma se lo stesso testo produce il 30% di token in più, lo stesso testo costa circa il 30% in più una volta che scatta la tariffa standard.
  • Capacità di contesto in termini di testo. La finestra di contesto è ancora 1M di token, ma ogni token ora copre in media meno testo. Lo stesso documento occupa ~30% in più della tua finestra.
  • Rischio di troncamento su max_tokens. Un cap di output tarato per "circa questa quantità di testo" su Sonnet 4.6 può troncare silenziosamente l'output equivalente su Sonnet 5. Rivedi qualsiasi limite dimensionato vicino alla lunghezza di output attesa.

La matematica del pricing, esposta onestamente:

PeriodoPrezzo di listinoStesso testo → costo vs Sonnet 4.6
Ora → 31 ago 2026 (introduttivo)$2 in / $10 outCirca 13% più economico (30% di token in più × $2 vs. Sonnet 4.6 a $3)
Dal 1 set 2026 (standard)$3 in / $15 outCirca 30% più costoso per testo equivalente

Se stai prezzando un'app sui token introduttivi e non hai modellato il flip del 1 settembre, te ne accorgerai.

Riconta i tuoi prompt con il nuovo tokenizer

# Recount before you migrate — don't trust old numbers
count = client.messages.count_tokens(
  model="claude-sonnet-5",     # count under the NEW tokenizer
  messages=[{"role": "user", "content": your_prompt}],
  system=your_system,
)
print(count.input_tokens)        # roughly 30% higher than on claude-sonnet-4-6

La scala di effort è cambiata — ricalibra prima di confrontare​

Il parametro effort (low / medium / high / xhigh / max) ha ancora gli stessi cinque valori, ma Anthropic fornisce una mappatura esplicita cross-modello per la migrazione che la maggior parte dei team salta alla prima lettura:

  • Sonnet 5 a medium ≈ Sonnet 4.6 a high.
  • Sonnet 5 a high ≈ Sonnet 4.6 a max.
  • xhigh è raccomandato per i task di coding e agentici più difficili.
  • max rimuove del tutto i vincoli di spesa di token.

Due implicazioni:

  • Se stavi facendo girare Sonnet 4.6 a high e cambi il modello senza cambiare effort, ora stai girando con più thinking, più token e probabilmente output migliori — ma un conto più salato. Considera di scendere a medium.
  • Se stavi facendo girare Sonnet 4.6 a max e passi a Sonnet 5 a max, potresti pagare per un headroom che non ti serve. Prova prima xhigh.

Anthropic avverte anche che Sonnet 5 rispetta l'effort rigorosamente, specialmente nel range basso. low e medium limitano il lavoro a ciò che è stato chiesto; non "vanno oltre". Questo è positivo per latenza e costi, ma su task moderatamente complessi a low c'è un rischio reale di sotto-pensiero. La fix raccomandata è alzare l'effort piuttosto che aggirare con il prompt.

Sonnet 5 è ora il default di Claude Code — cosa cambia​

A partire da Claude Code v2.1.197 (30 giugno 2026), claude-sonnet-5 è il modello di default. Se non imposti nulla, le tue sessioni girano su Sonnet 5. Conseguenze pratiche:

  • Ottieni 1M di contesto, ma le tue impostazioni max_tokens ed effort sono ereditate. I default di Claude Code sono tarati per il nuovo modello; le configurazioni CLAUDE.md custom che pinnavano max_tokens o impostavano un override di effort dovrebbero essere riverificate.
  • Comportamento di default più veloce e più agentico. Sonnet 5 è più agentico di Sonnet 4.6 out of the box — allunga la mano verso i tool e fa loop di self-verification più prontamente. Se eri abituato a un Claude Code conservativo nell'eseguire comandi, aspettati più iniziativa.
  • Aggiornamenti di progresso user-facing regolari. Sonnet 5 fornisce già update intermedi di qualità più alta su tracce lunghe. Scaffolding di prompt come "dopo ogni 3 tool call, riassumi il progresso" di solito può essere rimosso.
  • Sonnet 4.6 è ora un modello legacy. Ancora disponibile (pin claude-sonnet-4-6 se hai una ragione), ma non è più l'on-ramp.

I quattro pattern di prompting che la maggior parte dei team ricalibra​

1. La verbosity si calibra sulla complessità del task​

Sonnet 5 sceglie la lunghezza della risposta in base alla complessità del task piuttosto che basarsi su una verbosity fissa di default. Le lookup semplici ottengono risposte più brevi; l'analisi aperta ne ottiene di più lunghe. Se il tuo prodotto vuole uno stile consistente, taratura del prompt — lo snippet ufficiale Anthropic funziona:

Doma la verbosity quando ti serve una voce fissa

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

Gli esempi positivi ("ecco come dirlo in modo conciso") funzionano meglio di quelli negativi ("non spiegare troppo").

2. Il triggering dei tool è più agentico — e può essere calibrato​

Sonnet 5 allunga la mano verso i tool più prontamente di 4.6. Due leve:

  • Effort. high o xhigh mostrano un uso dei tool sostanzialmente maggiore nei workload di ricerca agentica e coding. low e medium limitano il lavoro strettamente.
  • Thinking off. Con thinking: {type: "disabled"}, il modello è meno incline ad allungare la mano verso i tool. Se disabiliti il thinking ma dipendi ancora dalle tool call, aggiungi un nudge esplicito nel system prompt.

3. Gli harness di code review possono vedere calare la recall — è il modello che diventa più letterale​

Se il tuo prompt di review dice "riporta solo gli issue di alta gravità" o "non fare le pulci", Sonnet 5 può seguirlo fedelmente — investigando altrettanto a fondo, trovando gli stessi bug, e poi non riportando le finding che giudica sotto la soglia dichiarata. La precisione tipicamente sale, la recall può sembrare calare. La fix raccomandata da Anthropic separa la fase di finding dalla fase di ranking:

Prompt di code review orientato alla recall per Sonnet 5

Report every issue you find, including ones you are uncertain about or consider low-severity.
Do not filter for importance or confidence at this stage - a separate verification step will do that.
Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug.
For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

Non devi effettivamente costruire il secondo step perché il prompt aiuti — spostare il filtro di confidence fuori dallo step di finding è ciò che cambia il comportamento.

4. I default di design si assestano su una "house style" — sovrascrivila esplicitamente​

Su brief frontend e di design aperti, Sonnet 5 tende verso uno stile visivo di default consistente. Legge bene per alcuni prodotti, sbagliato per dashboard, dev tool, fintech, healthcare o app enterprise. Il pushback generico ("rendilo meno generico") tende a spostare il modello verso uno diverso stile fisso piuttosto che produrre varietà. Due pattern che funzionano:

  • Specifica un'alternativa concreta — codici hex, nomi di typeface, regole di layout. Sonnet 5 segue le spec esplicite con precisione.
  • Chiedi al modello di proporre N opzioni prima di costruire. Poiché temperature non-default restituisce 400, questo è ora il modo raccomandato per produrre direzioni di design significativamente diverse tra run.

Forza la varietà di design senza temperature

Before building, propose 4 distinct visual directions tailored to this brief
(each as: bg hex / accent hex / typeface, plus a one-line rationale).
Ask the user to pick one, then implement only that direction.

Safeguard di cybersecurity: rifiuti come HTTP 200​

Sonnet 5 è il primo modello tier Sonnet con safeguard di cybersecurity in tempo reale. Quando una richiesta viene declinata, ritorna come HTTP 200 di successo con stop_reason: "refusal" — non un errore. Se non hai costruito un branch di gestione dei rifiuti, la tua app tratterà la risposta vuota come una risposta vuota di successo e la spedirà silenziosamente all'utente.

La fix è un branch sulla risposta:

Gestisci i rifiuti in modo pulito

resp = client.messages.create(model="claude-sonnet-5", messages=[...])
if resp.stop_reason == "refusal":
  # Show a graceful message. Optionally retry on a fallback model
  # (Opus 4.8 is a common choice). You are NOT billed for a refusal
  # returned before any output was generated.
  return handle_refusal(resp)
# Otherwise process resp.content as normal

Questa è la stessa forma dei rifiuti in-band di Fable 5 — se già li gestisci, sei coperto. Se sei nuovo a questo, vedi la guida sul campo di Fable 5 per il pattern più completo che include il parametro fallbacks.

Il Priority Tier non è disponibile — pianifica di conseguenza​

Ogni altro modello Anthropic attuale supporta il Priority Tier per capacità riservata e latenza prevedibile. Sonnet 5 no. Se hai un workload enterprise che dipende oggi da un commitment di Priority Tier, le tue opzioni sono:

  • Tieni il workload su Sonnet 4.6 (ancora supportato, ancora su Priority Tier).
  • Migra il workload su Opus 4.8, che è su Priority Tier ed è il modello con cui Sonnet 5 viene confrontato per i task duri comunque.
  • Passa al tier standard su Sonnet 5 e accetta capacità non riservata.

Non c'è un workaround via beta header. Se il Priority Tier è load-bearing per te, questo è il primo bloccante di migrazione da pianificare.

Sonnet 5 vs Sonnet 4.6 vs Opus 4.8 — la scelta​

SceltaSceglilo quando
Sonnet 5Default per qualsiasi cosa nuova. Coding, task agentici, 1M di contesto e sensibilità al prezzo puntano tutti qui.
Sonnet 4.6Ti serve il Priority Tier, hai prompt che dipendono da parametri di sampling non-default che non puoi ancora riscrivere, o sei in mezzo a un eval e vuoi una baseline stabile.
Opus 4.8Profondità di reasoning o stabilità in run lunghi che Sonnet 5 non raggiunge, o ti serve il Priority Tier al top di gamma. Abbina con un override di effort — xhigh su Opus 4.8 è uno sweet spot comune.
Fable 5 / Mythos 5Hai validato che Opus 4.8 non basta e sei disposto a pagare 5× il pricing di output di Sonnet 5 per run autonomi multi-giorno. Vedi la guida sul campo di Fable 5.

Checklist di migrazione​

Guided walkthrough1 of 6
  1. Usa l'API di token counting con model="claude-sonnet-5" per ogni prompt in cui la lunghezza conta. Ovunque tu confronti contro un budget fisso di 1M token, assumi ~30% di uso in più. Ovunque max_tokens sia stretto, alzalo.

Verifica rapida​

Check yourself

0/5
  1. Il tuo codice Sonnet 4.6 esistente imposta temperature: 0.7 e thinking: {type: "enabled", budget_tokens: 8000}. Cambi il modello a claude-sonnet-5. Cosa succede?
  2. Hai misurato un system prompt a 40.000 token su Sonnet 4.6. Circa quanti token dovresti aspettarti che lo stesso testo conti su Sonnet 5?
  3. Hai un workload enterprise su Sonnet 4.6 con un commitment di Priority Tier. Vuoi migrare a Sonnet 5. Qual è il bloccante?
  4. Secondo la mappatura di effort cross-modello di Anthropic, far girare Sonnet 5 a effort=medium è circa comparabile in intelligenza a quale impostazione di Sonnet 4.6?
  5. La tua richiesta Sonnet 5 restituisce una risposta HTTP 200 con content: [] e stop_reason: "refusal". Cosa NON è successo?

Fonti e letture aggiuntive​