I tre nomi, e che cosa li separa davvero

Opus, Sonnet e Haiku non sono tre taglie dello stesso modello: cambiano capacità, latenza, prezzo, finestra di contesto e — dettaglio che si dimentica — il tipo di ragionamento supportato.

                     ID modello                  prezzo in/out   contesto  output max  thinking
Claude Opus 5        claude-opus-5               $5 / $25 MTok   1M        128K        adattivo
Claude Sonnet 5      claude-sonnet-5             $2 / $10 MTok   1M        128K        adattivo
Claude Haiku 4.5     claude-haiku-4-5-20251001   $1 / $5 MTok    200K       64K        extended

La latenza comparata va da «fastest» per Haiku 4.5 a «fast» per Sonnet 5 a «moderate» per Opus 5. Il parametro effort ha default high su Opus 5 e Sonnet 5 e non è supportato su Haiku 4.5. Come destinazioni d’uso la documentazione assegna a Opus 5 il coding agentico complesso e il lavoro enterprise, a Sonnet 5 velocità e capacità per i carichi quotidiani, a Haiku 4.5 la latenza e il prezzo più bassi: tempo reale, alti volumi, sotto-agenti. Esiste una fascia ancora più capace sopra Opus 5, ma per la maggior parte dei carichi si parte da lì.

Due modi di partire, e quale conviene

La documentazione descrive due approcci simmetrici. Efficiency-first: implementi con Haiku 4.5, testi, e sali solo se manca una capacità specifica. Capability-first: implementi con Opus 5, ottimizzi i prompt per quel modello, poi guadagni efficienza abbassando l’effort o scendendo di modello.

Se il compito è nuovo e non sai ancora se è fattibile, parti capability-first: separi il problema «il modello non ce la fa» da «il mio prompt non è buono», e solo dopo scendi. Se il compito è chiaro, semplice e ad alto volume, o il vincolo è la latenza, parti efficiency-first.

In entrambi i casi il passaggio decisivo è lo stesso e non è la scelta iniziale: costruire un set di test sul tuo caso reale, con i tuoi prompt e i tuoi dati, e confrontare i modelli su accuratezza, qualità e casi limite. Con un criterio che conviene adottare esplicitamente: misura il costo per compito completato, non il costo per token. Un modello più economico che ha bisogno di tre tentativi non è più economico.

Quando la curva qualità/spesa di un singolo modello non basta, restano le strategie multi-modello: un executor a basso costo che tiene il loop e consulta un advisor più capace sulle decisioni difficili, oppure un orchestratore che delega il lavoro di massa a worker più economici. Nei benchmark della documentazione un coordinatore di fascia alta con un worker Sonnet 5 è costato circa la metà del solo modello di fascia alta. La trappola, misurata: un executor a effort basso può smettere di accorgersi di essere bloccato, e consultare l’advisor quasi mai.

Adaptive thinking ed effort: la leva dentro il modello

Con l’adaptive thinking è il modello a decidere se e quanto ragionare; tu lo indirizzi con effort, che ha cinque livelli: low, medium, high (il default), xhigh e max. Non tutti i modelli che supportano max supportano xhigh. L’effort agisce su tutti i token di output, non solo sul thinking: a effort basso le chiamate ai tool sono meno numerose e più asciutte, a effort alto il modello spiega il piano prima di agire. E vale la pena ricordarlo come sta scritto: «Effort is a behavioral signal, not a strict token budget.»

La conseguenza pratica è che spesso non serve cambiare modello: «Tuning effort is often a better lever than switching models.» Prima di degradare da Opus 5 a Sonnet 5, prova Opus 5 a medium.

Due vincoli di cui tenere conto sul costo. I token di thinking sono fatturati come token di output anche quando il testo non ti viene restituito, e concorrono al limite max_tokens insieme alla risposta: se lavori a xhigh o max, alza max_tokens (64k è un punto di partenza ragionevole). E su Haiku 4.5, che non supporta l’effort, la leva è il budget di token dell’extended thinking.

Cambiare modello è cambiare contratto

L’ultima parte della skill è quella che si sottovaluta: fra una release e l’altra ci sono cambiamenti che rompono. I principali, oggi:

  • temperature, top_p e top_k sono deprecati e restituiscono 400 se impostati a un valore non predefinito sui modelli 4.7 e successivi.
  • Il prefill della risposta assistant non è supportato dai modelli 4.6 in poi: 400.
  • L’extended thinking manuale non è accettato dai 4.7 in poi, che vogliono thinking adattivo più effort; specularmente, i modelli 4.5 e precedenti rifiutano la modalità adattiva.
  • Su Opus 5 il thinking è attivo anche senza parametro: la risposta può iniziare con blocchi thinking, quindi il parsing per posizione si rompe, e in un loop di tool i blocchi vanno rimandati indietro identici o ricevi 400. Disabilitare il thinking è inoltre possibile solo fino a effort high.
  • Dal 4.7 il tokenizer è nuovo: lo stesso testo produce circa il 30 per cento di token in più. Non riusare conteggi misurati su modelli precedenti per stimare costi o capienza del contesto.

Sul versionamento degli identificativi, un equivoco frequente: dalla generazione 4.6 in poi gli ID senza data — claude-sonnet-5, claude-opus-5 — non sono puntatori sempreverdi, sono snapshot fissi. Solo i modelli precedenti hanno alias che risolvono all’ultimo snapshot datato. Il ciclo di vita ha quattro stati (Active, Legacy, Deprecated, Retired), il preavviso di ritiro per i modelli pubblici è di almeno 60 giorni, e le richieste a un modello ritirato falliscono. Prima di migrare, rifai lo sweep dell’effort sulle tue eval invece di trasportare l’impostazione tarata sul modello vecchio.