La Matematica dei Costi degli Agenti IA: Quando Haiku Batte Sonnet (e Quando No)

Indice dei contenuti

Aggiornato giugno 2026.

TL;DR: Scegliere Claude Haiku al posto di Sonnet può ridurre il costo per chiamata di un ordine di grandezza, ma solo quando il task tollera il tasso di successo inferiore di Haiku. La metrica che conta è il costo per risultato riuscito — costo della chiamata più ritentativi più pulizia umana — non il prezzo di listino per token. Faccio il routing per task, e una quota significativa dei miei step ad alto volume gira su Haiku mentre le decisioni di giudizio restano su Sonnet.

Lettura dell’operatore: Gestisco oltre 100 agenti, e l’inferenza è una voce di costo reale. Ma ho visto team “risparmiare” forzando tutto sul modello più economico per poi pagare il conto in ritentativi, escalation e clienti arrabbiati. La matematica dei costi funziona solo quando misuri l’intero funnel.

Il modello più economico non è quello con il prezzo per token più basso. È quello con il costo totale più basso per fare il lavoro nel modo giusto. Questi sono numeri diversi, e il divario tra loro è esattamente dove la maggior parte delle decisioni di costo sugli agenti va storta.

L’economia dei token, detta chiaramente

Anthropic tariffa Claude per milione di token, con input e output fatturati separatamente, e l’output che costa diverse volte di più dell’input. I numeri esatti cambiano nel tempo, quindi controlla i prezzi attuali di Anthropic — ma è la struttura a guidare la decisione:

• Haiku è il livello economico e veloce — di gran lunga il costo per token più basso della famiglia.
• Sonnet sta nel mezzo — nettamente più costoso di Haiku, nettamente più economico di Opus.
• Opus è il livello premium per il ragionamento più difficile.

Ne seguono due cose. Primo, i token di output dominano il costo nei task generativi, quindi un modello prolisso costa di più anche allo stesso prezzo per token. Secondo, il divario di prezzo per token tra Haiku e Sonnet è abbastanza grande da farsi notare assolutamente sul conto in uno step ad alto volume. Questo è l’argomento a favore di Haiku. Ora l’argomento contro.

La metrica che conta davvero: il costo per risultato riuscito

Il costo per chiamata è un numero di vanità. Ecco la formula che uso davvero:

costo_per_successo = (costo_chiamata × tentativi) + costo_pulizia
                      ÷ tasso_di_successo

Dove tentativi tiene conto dei ritentativi, e costo_pulizia è il costo atteso di un umano che corregge i fallimenti che sfuggono. Guarda cosa fa questo al confronto.

Supponi che Haiku costi circa un decimo di Sonnet per chiamata. Se Haiku riesce nell’80% dei casi su un task e Sonnet nel 98%, il risparmio per chiamata sembra enorme. Ma se ogni fallimento di Haiku innesca un ritentativo e 1 su 10 richiede comunque un umano che costa denaro reale, il termine di pulizia può inghiottire il risparmio sui token. Su un task a basso rischio e alto volume la matematica favorisce Haiku in modo schiacciante. Su un task dove un fallimento manda un’email al cliente sbagliato, può ribaltarsi completamente.

Non puoi prendere questa decisione senza misurare il tasso di successo per modello — che è esattamente ciò che ti dà un harness di valutazione. Esegui lo stesso set di valutazione contro entrambi i modelli e leggi i tassi di successo sulla stessa unità di misura.

Dove Haiku vince in modo deciso

Haiku è la scelta giusta quando il task è circoscritto, strutturato e verificabile:

• Classificazione e routing — “questo messaggio in arrivo è una prenotazione, un reclamo o spam?” Tre categorie, facile da verificare, gira di continuo. Haiku tutto il giorno.
• Estrazione con uno schema — tirare fuori una data, un nome, un importo da un testo, validato con Zod. Se l’output viene parsato, è quasi certamente corretto.
• Riscritture brevi e formattazione — aggiustamenti di tono, riassumere un input noto come buono, normalizzare dati.
• Filtraggio di prima passata — Haiku fa il triage, e solo i casi ambigui vengono escalati a Sonnet. Questo è il pattern a maggior leva.

Il filo conduttore: il costo di un errore di Haiku è basso e l’errore è economico da individuare. Quando la verifica è economica e il rischio è basso, vince il modello economico.

Dove Sonnet si guadagna il suo prezzo

Sonnet (e a volte Opus) vale la pena quando il task è aperto, multi-step o costoso da sbagliare:

• Loop di agente multi-strumento dove una chiamata sbagliata a uno strumento si propaga a cascata. Una maggiore affidabilità di ragionamento si compone attraverso gli step — i pattern di orchestrazione che tratto in orchestrazione multi-agente si basano sul fatto che il modello non perda il filo.
• Generazione rivolta al cliente dove un output scadente costa fiducia, non solo un ritentativo.
• Qualsiasi cosa dove la verifica sia di per sé difficile. Se non puoi dire a basso costo se l’output è corretto, non puoi permetterti un modello che sbaglia di frequente.

Un fallimento qui non costa un ritentativo — costa un rimborso, un cliente perso, o il mio tempo. A fronte di questo, il sovrapprezzo per token è un errore di arrotondamento.

La regola di routing che metto davvero in produzione

Non scelgo un modello per agente. Faccio il routing per task all’interno dell’agente, di solito con un classificatore economico che decide quale modello a valle gestisce il lavoro:

function pickModel(task: Task): string {
  // Economico, verificabile, alto volume → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // Aperto o rivolto al cliente → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // di default, la scelta sicura
}

Qui sono codificati due principi. Di default il modello sicuro, non quello economico — ottimizzi il costo verso il basso da una base che funziona, mai l’affidabilità verso l’alto da una rotta. E escala, non scommettere: lascia che Haiku gestisca l’80% facile e affida il 20% difficile a Sonnet. Quell’ibrido batte quasi sempre l’esecuzione di tutto su uno solo dei due modelli.

C’è anche il prompt caching da aggiungere sopra: se il tuo prompt di sistema è grande e riutilizzato, il caching riduce sostanzialmente il costo di input indipendentemente dal livello, il che a volte rende Sonnet abbastanza economico da rendere irrilevante la questione di Haiku.

Un esempio concreto dal mio stack

Prendi uno step di triage di messaggi in arrivo ad alto volume. Gira migliaia di volte, il task è una classificazione a tre vie, e un errore significa solo che l’elemento finisce in una coda di revisione — economico da individuare, basso rischio. È un task da manuale per Haiku, e spostarlo da Sonnet ha ridotto significativamente il costo di quello step senza impatto misurabile sul risultato che contava.

Ora prendi lo step che redige la risposta vera al cliente. Volume più basso, aperto, e una bozza scadente che esce costa fiducia. Quello resta su Sonnet. Stesso agente, due modelli, indirizzati per rischio. Tengo d’occhio il costo per esecuzione e le metriche di successo di entrambi, nel modo in cui descrivo in come misuro se un agente IA sta davvero funzionando — e abbasso uno step di un livello solo dopo che la valutazione dice che il modello più economico mantiene il tasso di successo.

FAQ

Claude Haiku è sempre più economico di Sonnet nella pratica?

Per token, sì — con ampio margine. Per risultato riuscito, non sempre. Se il tasso di successo inferiore di Haiku innesca ritentativi e pulizia umana, il costo totale può superare quello di Sonnet sui task dove gli errori sono costosi da individuare o correggere.

Come decido tra Haiku e Sonnet per un dato task?

Valuta il task su due assi: quanto è verificabile l’output e quanto è costoso un errore. Il lavoro economico da verificare, a basso rischio e alto volume va a Haiku; il lavoro aperto, rivolto al cliente o difficile da verificare va a Sonnet. Fai il routing per task, non per agente.

Qual è l’unica metrica di costo che dovrei monitorare?

Il costo per risultato riuscito — costo della chiamata per tentativi più costo di pulizia atteso, diviso il tasso di successo. Il prezzo per chiamata da solo nasconde ritentativi e tempo umano, ed è lì che i modelli economici diventano costosi senza che te ne accorga.

Posso usare entrambi i modelli in un solo agente?

Sì, e di solito dovresti. Il pattern più forte è una prima passata economica (Haiku classifica o filtra) che escala a Sonnet solo i casi ambigui. Quell’ibrido in genere batte l’esecuzione di tutto su un singolo livello.