«Most workloads start with Claude Opus 5»: la documentazione ti dà un default, non una scorciatoia. La scelta del modello ha il rapporto più alto fra impatto economico e sforzo implementativo, ed è anche quella che gli architetti motivano peggio: la difendono sul listino invece che sulle misure.

Quattro criteri e due punti di partenza

I criteri da fissare prima di guardare il prezzo sono capacità, velocità, costo ed effort. Il quarto è quello che si dimentica: diversi modelli espongono un parametro effort che scambia intelligenza con latenza e costo dentro lo stesso modello, e «Tuning effort is often a better lever than switching models».

Da lì partono due strategie opposte. La prima è efficiency-first: si implementa con Claude Haiku 4.5, si prova a fondo il caso d’uso e si sale solo se emerge uno scarto di capacità specifico. Serve per prototipi, requisiti di latenza stretti e volumi alti su compiti semplici. La seconda è capability-first: si parte da Claude Opus 5, si ottimizzano i prompt per quel modello e solo dopo si guadagna efficienza abbassando l’effort o scendendo di modello. È la strada per ragionamento complesso, lavoro agentico ad alta autonomia e casi in cui l’accuratezza pesa più del costo.

Fable 5.1   $10 / $50 per MTok   ctx 1M     output max 128K   latenza: la più alta
Opus 5      $5  / $25 per MTok   ctx 1M     output max 128K   latenza: moderata
Sonnet 5    $2  / $10 per MTok   ctx 1M     output max 128K   latenza: rapida
Haiku 4.5   $1  / $5  per MTok   ctx 200K   output max  64K   latenza: la più bassa

La finestra di contesto non è una riga di specifica: 1M token contro 200K decide se un corpus entra in una sessione o va partizionato.

Il listino non è il costo

Il confronto corretto è sul costo per attività completata, non per token. Su SWE-bench Pro, Claude Fable 5.1 a effort low chiude l’88,6% a 0,54 dollari per attività, contro il 77,4% di Claude Sonnet 5 a 0,84 dollari: undici punti in più spendendo il 35% in meno, nonostante un prezzo per token cinque volte superiore. Un modello «caro» che risolve al primo tentativo può costare meno di uno economico che itera.

Il secondo dato che cambia la conversazione è la distribuzione: su venti problemi WideSearch, i due più difficili assorbono il 43% della spesa e i dieci più facili appena il 10%. È la ragione per cui esistono le architetture multi-modello: spendere intelligenza di frontiera sulla coda dura senza pagare tariffe di frontiera sul lavoro di routine. Le due forme documentate sono l’advisor, un esecutore economico che scala le decisioni difficili a un modello superiore, e l’orchestrator, un modello di frontiera che delega il lavoro in blocco a worker meno costosi. Vanno adottate solo se battono l’intera curva del modello singolo.

Effort: la leva da esaurire prima di cambiare modello

L’effort ha cinque livelli — low, medium, high, xhigh, max — con default high sull’API; Claude Haiku 4.5 non lo supporta. Va ricordato che «Effort is a behavioral signal, not a strict token budget»: non è un tetto di spesa, è una calibrazione.

La forma della curva dipende dal tipo di lavoro. Sul lavoro di conoscenza l’effort alto spesso non compra nulla: medium eguaglia high risparmiando dal 13 al 31%. Sul coding di lungo respiro il compromesso è reale, con low che perde otto punti risparmiando il 75%. Quando l’esito è verificabile con test esiste una terza via: eseguire tutto a effort basso e rilanciare i soli fallimenti a effort alto, per accuratezza pari o superiore a metà costo, al prezzo di due giri di latenza.

Un effetto collaterale vanifica il risparmio: cambiare l’effort di primo livello fra una richiesta e l’altra invalida la cache del prompt.

Il rischio che non compare nel confronto

Un modello non è una scelta perpetua. Il ciclo di vita ha quattro stati — Active, Legacy, Deprecated, Retired — e Anthropic si impegna a dare «at least 60 days’ notice before model retirement for publicly released models». Due mesi sono un preavviso, non un piano di migrazione: chi non ha una suite di valutazione pronta li spende a scrivere test. L’audit dell’uso per chiave API e per modello si esporta dalla pagina Usage in Console: è il primo passo di ogni migrazione.

Vanno messe in conto anche le leve che non ci sono più: temperature, top_p e top_k restituiscono 400 su Claude 4.7 e successivi, e la guida rimanda al prompting; e gli impegni di capacità del Priority Tier non sono più acquistabili, oltre a non coprire i modelli di punta attuali. La garanzia di capacità, oggi, non è una leva contrattuale che puoi promettere.

Come si difende la scelta

Il confronto va fatto sui propri dati: benchmark specifici del caso d’uso, dove «having a good evaluation set is the most important step in the process», misura di accuratezza, qualità e casi limite, e solo alla fine il peso di prestazioni e costo. Ogni livello di effort va provato in una sessione separata, il vincitore va messo in shadow su una fetta di traffico, e la suite di esiti va lasciata accesa dopo il rilascio. Senza queste quattro righe, la scelta del modello resta un’opinione.