Sintesi della lezione basata sul blog Claude «Claude Models Explained: Choosing the Best Model for Your Use Case».
Fonte: https://claude.com/blog/claude-models-explained-choosing-the-best-model-for-your-use-case
Non esiste «il modello migliore» in assoluto: esiste il migliore per quel compito, a quel volume, con quei vincoli di latenza. Scegliere significa trovare il miglior rapporto tra qualità, velocità e costo.
I modelli di una stessa generazione sono organizzati in classi che scalano tre grandezze in tensione tra loro — capacità di ragionamento, latenza e costo (in dollari per milione di token, l'unità in cui il modello spezza il testo, ~3-4 caratteri).
Dalla più potente alla più economica:
| Classe | Profilo | Quando |
|---|---|---|
| Mythos / Fable | Modelli di frontiera, massima capacità. Mythos è ristretto a organizzazioni fidate su lavori dual-use (cybersecurity, biologia); Fable ha salvaguardie extra per uso pubblico più ampio | Compiti al limite dello stato dell'arte |
| Opus | Potente, per compiti aziendali a forte intensità di ragionamento | Ragionamento complesso, multi-step, codice |
| Sonnet | La classe «tuttofare»: bilancia qualità, velocità e costo | Compiti quotidiani |
| Haiku | Il più veloce ed economico | Alta frequenza, dove latenza e costo contano più della profondità |
Parti dal modello più capace tra quelli disponibili, poi scendi di classe o abbassa lo sforzo solo se i numeri lo giustificano. Un modello più capace spesso chiude il compito in meno tentativi: «meno tentativi» può risultare più economico di un modello a basso costo che sbaglia e va rilanciato.
flowchart TD
A[Nuovo compito] --> B{Complessita'?<br/>ragionamento multi-step,<br/>codice, decisioni}
B -->|Alta| C[Parti da Opus<br/>o modello di frontiera]
B -->|Media/Bassa| D[Parti da Sonnet]
C --> E{Latenza critica?<br/>utente in tempo reale}
D --> E
E -->|Si', serve risposta rapida| F[Scendi verso Sonnet/Haiku<br/>o riduci lo sforzo]
E -->|No, lavoro batch/async| G[Tieni la classe alta]
F --> H{Accesso consentito?<br/>Mythos ristretto,<br/>policy aziendali}
G --> H
H -->|No| I[Ripiega sulla classe<br/>disponibile piu' alta]
H -->|Si'| J{Unit economics reggono?<br/>costo x volume atteso}
J -->|Volume alto, margine stretto| K[Scendi di classe<br/>e misura la qualita']
J -->|Volume ok| L[Confermi la scelta]
K --> M[Valuta su un set di test:<br/>qualita' vs costo per compito riuscito]
L --> M
I --> M
M --> N{Qualita' accettabile?}
N -->|Si'| O[Deploy + monitora]
N -->|No| CIl punto chiave: le quattro dimensioni non si valutano una volta sola, ma in un ciclo che si chiude su una misura empirica («la qualità regge?»), non su un'intuizione.
regolare quanto il modello «pensa» riduce costo e latenza sullo stesso modello; spesso preferibile a cambiare classe.
mettere in cache un prompt lungo e riusato (es. un system prompt corposo) abbatte il costo dei token ripetuti.
per lavori asincroni, riduce il costo e rende accettabile una classe alta su volumi grandi.
«Opus» è una classe; «Opus 4.8» è una classe di una generazione. Salire di generazione (stessa classe, versione più recente) spesso dà più capacità a parità di costo: è la prima leva da considerare, prima di cambiare classe.
Haiku ha bassa latenza per singola richiesta e alto throughput per volumi; proprietà distinte ma spesso insieme.
Scenario. Team di supporto clienti, ~50.000 ticket/mese. Ogni ticket richiede (a) classificare l'intento (reso, fattura, bug tecnico) e (b) per i bug, generare una risposta ragionata leggendo i log. Vincolo: la classificazione risponde in <1 s (l'agente umano aspetta a schermo); la risposta tecnica può richiedere qualche secondo.
Risultato: architettura a due modelli — Haiku per la classificazione real-time ad alto volume, Opus per la minoranza di casi complessi dove il ragionamento ripaga il costo. Spesa totale più bassa di qualsiasi scelta a modello singolo, ogni decisione ancorata a una misura.