# Scegliere il modello Claude giusto

> 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

---

## Il concetto in una frase

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**.

## Le classi (tier) di modelli

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à |

## La regola-guida

**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.

---

## Il flusso di scelta

```mermaid
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| C
```

Il 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.

---

## Le quattro dimensioni di scelta (con le insidie)

1. **Complessità del compito** — Compiti multi-step (agenti, refactoring, catene di ragionamento) traggono beneficio dalle classi alte. *Insidia:* sovrastimare un compito banale (estrarre un campo da un JSON) e pagare Opus dove basterebbe Haiku.

2. **Latenza** — App conversazionali e real-time (chatbot, autocomplete) favoriscono Sonnet o Haiku. *Insidia:* la latenza dipende anche dai **token generati** e dal livello di *effort/reasoning*; un Opus con effort basso può battere un Sonnet mal configurato.

3. **Vincoli di accesso** — Mythos è ristretto; policy aziendali, regione di deployment o piattaforma (API diretta, AWS Bedrock, Google Vertex) possono limitare le classi usabili. Non progettare attorno a un modello che poi non puoi chiamare in produzione.

4. **Unit economics** — Il costo per token cresce salendo di classe (Haiku < Sonnet < Opus < frontiera). Ma il costo *rilevante* è quello **per compito riuscito**, non per token: un modello economico che fallisce e richiede retry o intervento umano può costare più di un Opus one-shot. *I prezzi esatti cambiano nel tempo: leggerli sulla pagina pricing ufficiale, non ricordarli a memoria.*

## Leve oltre alla classe

- **Effort / reasoning level** — regolare quanto il modello "pensa" riduce costo e latenza sullo stesso modello; spesso preferibile a cambiare classe.
- **Prompt caching** — mettere in cache un prompt lungo e riusato (es. un system prompt corposo) abbatte il costo dei token ripetuti.
- **Batch processing** — per lavori asincroni, riduce il costo e rende accettabile una classe alta su volumi grandi.

## Da non confondere

- **Classe vs generazione** — "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.
- **Latenza vs throughput** — Haiku ha bassa latenza per singola richiesta *e* alto throughput per volumi; proprietà distinte ma spesso insieme.

---

## Esempio pratico

**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.

1. **Spezza il carico in sotto-compiti** — hanno profili diversi:
   - *Classificazione*: semplice, altissimo volume, latenza critica → candidato **Haiku**.
   - *Risposta tecnica sui log*: multi-step, volume basso, latenza tollerante → candidato **Opus** o **Sonnet**.

2. **Parti dall'alto e misura** — set di prova di ~200 ticket etichettati a mano. Se Haiku raggiunge ~98% di accuratezza sulla classificazione, tienilo. Per la risposta tecnica, prova Opus con effort medio e misura quante risposte passano la review senza correzione.

3. **Confronta il costo per compito riuscito, non per token** — se Opus risolve l'85% dei bug senza intervento e Sonnet il 60%, con 5.000 bug/mese quel 25% di gap = 1.250 interventi umani extra. Se il delta di costo API tra Opus e Sonnet su quei ticket è inferiore al costo di quel lavoro umano, **Opus è più economico** nonostante il prezzo/token più alto.

4. **Applica le leve fini** — prompt caching sul system prompt lungo della classificazione; batch per i report tecnici notturni.

5. **Verifica accesso e deployment** — conferma che le classi scelte siano disponibili sulla piattaforma di produzione prima di scrivere il codice definitivo.

**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.

---

## Riferimenti

- **"Claude Models Explained: Choosing the Best Model for Your Use Case"** — https://claude.com/blog/claude-models-explained-choosing-the-best-model-for-your-use-case
- Per **ID modello e prezzi esatti** (variabili nel tempo): pagina pricing / docs ufficiali su claude.com/docs.