Modelli Claude a confronto: quale scegliere e quando cambiare

I modelli Claude non si scelgono dal nome. Si scelgono da tre numeri — quanto costa il singolo compito, quanto tempo puoi aspettare, quanta qualità ti serve davvero — e da una verifica sui tuoi dati che vale più di qualunque classifica.

Questa guida mette in fila tutto: come sono divise le fasce, come si sceglie per caso d'uso, quanto si risparmia scendendo di livello, e come si cambia modello senza rompere quello che funziona. Dove cito versioni e listini, verifica sempre la pagina ufficiale: i cataloghi cambiano in fretta.

I quattro modelli in una tabella

Tutti i dati provengono dalla panoramica modelli della documentazione ufficiale Anthropic, letta il 19 agosto 2026. I prezzi sono in dollari per milione di token.

La prima cosa che salta all'occhio è la scala dei prezzi: dieci volte fra Haiku 4.5 e Fable 5.1 in input, dieci volte anche in output. È una differenza che su volumi seri decide se un progetto è sostenibile.

La seconda è che la finestra di contesto ha smesso di differenziare: tre modelli su quattro dichiarano un milione di token. Chi sceglieva in base a quel parametro oggi deve guardare altro, per le ragioni spiegate in finestra di contesto: quanto conta davvero.

Cosa dice la documentazione ufficiale

Al di là dei numeri, la documentazione fornisce due indicazioni operative che vale la pena riportare.

La prima è il consiglio di partire da Opus 5 come scelta predefinita. È il modello posizionato come equilibrio fra capacità e costo all'interno della famiglia.

La seconda riguarda Fable 5.1, indicato per il ragionamento complesso e per i flussi agentici di lunga durata, oppure per i casi in cui Opus 5 al massimo livello di ragionamento non è sufficiente. È una raccomandazione precisa: Fable 5.1 non è il modello da usare sempre, è quello da usare quando l'altro non basta.

Cosa cambia davvero fra una fascia e l'altra

I prezzi raccontano una gerarchia, ma non spiegano cosa si compra salendo. Vale la pena dirlo in modo concreto, perché è la parte che decide se la spesa in più ha senso.

Dal leggero all'intermedio. Il salto più evidente riguarda i compiti che richiedono di tenere insieme più informazioni. Un modello leggero classifica benissimo un messaggio o estrae un campo da un documento pulito; comincia a faticare quando deve incrociare tre fonti, gestire un'eccezione non prevista o capire che la domanda contiene un presupposto sbagliato.

Dall'intermedio all'alto. Qui il guadagno si concentra sui compiti a più passaggi, dove un errore al secondo passo si propaga fino alla fine. Analisi articolate, interventi su codice esistente, agenti che devono pianificare e correggersi: sono gli scenari in cui la differenza si vede.

Al vertice della famiglia. L'ultimo scalino è quello con il rapporto costo-beneficio più stretto e va giustificato caso per caso. La documentazione stessa lo posiziona come riserva per quando il livello sotto, spinto al massimo, non basta — il che implica che nella maggior parte delle situazioni non serve.

Il livello di ragionamento come terza variabile

C'è un parametro che agisce trasversalmente e che spesso rende inutile salire di modello: il livello di ragionamento. Alzarlo su un modello intermedio può colmare parte del divario con la fascia superiore, a un costo inferiore rispetto al cambio di modello.

La documentazione Anthropic indica un livello predefinito alto sui modelli di punta della famiglia. È un dettaglio che conta quando si confrontano i prezzi: un modello che ragiona di più produce più token di output, e l'output è la voce più cara del listino. Il meccanismo è spiegato in reasoning effort: cosa cambia nei confronti.

La velocità, che spesso conta più della qualità

La documentazione indica una scala di latenza relativa: Fable 5.1 è il più lento, Haiku 4.5 il più veloce, con Opus 5 e Sonnet 5 nel mezzo.

È un dato che in fase di valutazione viene quasi sempre trascurato e che in produzione diventa determinante. Se il modello risponde dentro un'interfaccia dove qualcuno aspetta, due secondi e otto secondi sono esperienze completamente diverse, indipendentemente da quanto sia buona la risposta.

Nella colonna di sinistra il modello leggero è spesso la scelta corretta anche a costo di qualche punto di qualità. Nella colonna di destra puoi permetterti il modello più capace senza che nessuno se ne accorga.

Le tre domande che determinano tutto

Quanto è complesso il compito? Non quanto è importante: quanto è complesso. Classificare un messaggio è semplice anche se il messaggio è di un cliente importante. Un compito è complesso quando richiede di concatenare più deduzioni, incrociare fonti diverse o gestire eccezioni non previste.

Quanti casi al mese? Sotto qualche migliaio, la differenza di prezzo fra le fasce è trascurabile e conviene privilegiare la qualità. Sopra le decine di migliaia, il costo diventa la variabile dominante e vale la pena ottimizzare seriamente.

Qualcuno sta aspettando? Se la risposta compare su uno schermo mentre una persona attende, la velocità entra nella decisione con lo stesso peso della qualità.

La mappa per caso d'uso

La colonna «fascia di partenza» va letta letteralmente: è il punto da cui iniziare la prova, non la conclusione. Se la fascia indicata non basta sui tuoi casi, si sale; se abbonda, si scende.

Le caratteristiche complete di ciascun modello sono in modelli Claude a confronto.

La procedura in cinque passi

Primo: scrivi il compito in una frase. Non «vogliamo usare l'AI», ma «classificare le email in arrivo in sei categorie» o «estrarre otto campi dalle fatture fornitori». Se non riesci a scriverlo in una frase, il progetto non è ancora definito.

Secondo: raccogli dieci casi reali. Presi dal lavoro vero, con l'esito corretto già noto. Almeno tre devono essere difficili: documento mal scritto, informazione mancante, formato anomalo. Sono quelli che distinguono le fasce.

Terzo: parti dalla fascia più bassa plausibile. Usa la mappa qui sopra. Esegui i dieci casi e annota per ciascuno esito, tempo e consumo.

Quarto: sali solo se fallisce. E prima di cambiare modello, prova ad alzare il livello di ragionamento sulla stessa fascia: costa meno di un salto di categoria e spesso basta.

Quinto: fai valutare a chi conosce il lavoro. Non a chi conosce l'AI. Chi fa quel mestiere riconosce in due secondi un errore che a un tecnico sembra una risposta ragionevole.

• Definisci il compito in una frase
• Raccogli dieci casi reali, tre difficili
• Parti dalla fascia più bassa plausibile
• Alza prima l'effort, poi la fascia
• Fai valutare a chi conosce il lavoro
• Misura anche costo e tempo, non solo qualità

Perché salire per prudenza è l'errore più caro

La tentazione, di fronte a un progetto importante, è scegliere il modello più capace «per stare tranquilli». È comprensibile ed è la decisione che costa di più, per tre ragioni contemporanee.

Costa di più in denaro, ovviamente: fino a dieci volte rispetto alla fascia leggera. Costa in velocità, perché i modelli più capaci sono i più lenti e in scenari interattivi l'utente lo percepisce. E costa in informazione, perché non saprai mai se la fascia inferiore sarebbe bastata — e senza quel dato non potrai mai ottimizzare.

La risposta è spesso "due"

Nella maggior parte dei processi aziendali la difficoltà dei casi non è distribuita in modo uniforme: la grande maggioranza è ordinaria, una minoranza è complessa. Pagare la stessa tariffa per entrambe le categorie è lo spreco più diffuso.

L'impostazione a due livelli risolve il problema. Il modello leggero riceve tutto il traffico e chiude i casi che gestisce con sicurezza; quelli che riconosce come dubbi salgono al modello capace.

Se i casi difficili sono il dieci per cento, paghi la fascia alta su un decimo del volume. La spesa resta vicina a quella del modello economico, la qualità a quella del modello potente. Il dettaglio dell'impostazione è in strategia a modello misto.

Le tre soglie da verificare per prime

La lunghezza dell'input. Duecentomila token sono molto: nell'ordine di alcune centinaia di pagine di testo. Per la stragrande maggioranza dei compiti aziendali è abbondante. Diventa stretto quando devi passare interi archivi, contratti molto voluminosi o conversazioni lunghissime con tutto lo storico.

La lunghezza dell'output. Sessantaquattromila token restano tanti per una risposta, ma se il tuo caso prevede di generare documenti lunghi — report estesi, traduzioni integrali, riscritture complete — la soglia si può incontrare.

La data limite. Febbraio 2025 è oltre un anno più vecchia di quella di Sonnet 5. Su compiti in cui l'informazione arriva dai tuoi documenti non cambia nulla. Su compiti che dipendono dalla conoscenza interna del modello, la differenza è sostanziale e va considerata seriamente.

Cosa fa bene il modello leggero

La tentazione è di considerare il modello economico una versione depotenziata da usare solo per risparmiare. È una lettura sbagliata: su una classe precisa di compiti fa il lavoro esattamente come le fasce superiori, in meno tempo e a metà prezzo.

Quella classe è composta dai compiti di riconoscimento e trasformazione semplice: capire di cosa parla un messaggio, individuare un campo in un documento strutturato, decidere a chi instradare una richiesta, riformulare un testo breve, verificare la presenza di un'informazione.

Sono compiti che nella pratica costituiscono la maggioranza del traffico di un sistema aziendale. Pagarli come se fossero analisi complesse è lo spreco più diffuso nei progetti AI.

Quanto si risparmia

Su volumi alti la differenza si vede subito. Ipotizziamo 200.000 richieste al mese, con 1.500 token di input e 300 di output ciascuna.

Settemiladuecento dollari all'anno, a parità di risultato se il compito è di quelli che il modello leggero gestisce bene. Su volumi più alti la proporzione resta la stessa e la cifra assoluta cresce.

C'è poi un secondo risparmio, meno visibile ma reale: la velocità. Un modello più veloce riduce i tempi di attesa negli scenari interattivi e accorcia le elaborazioni in blocco. Nei flussi agentici, dove ogni passaggio paga la propria latenza, l'effetto si moltiplica per il numero di passaggi.

La strategia a due livelli

L'impostazione che dà i risultati migliori nella pratica non sceglie fra i due modelli: li usa entrambi.

Haiku 4.5 riceve tutto il traffico. Per ogni caso produce un esito e un'indicazione di quanto sia sicuro. I casi che superano la soglia di confidenza si chiudono lì; quelli sotto passano a Sonnet 5, che li tratta con più attenzione.

• Definisci una soglia esplicita per il passaggio di livello
• Misura la percentuale reale di casi che salgono
• Verifica che il modello leggero ammetta di non sapere
• Controlla a campione i casi chiusi al primo livello
• Rivedi la soglia dopo qualche settimana di dati
• Registra tutto per poter tarare nel tempo

Il terzo punto è la condizione che rende possibile l'intera impostazione. Un modello leggero che chiude con sicurezza casi che non ha capito rende inutile il secondo livello, perché quei casi non arrivano mai al modello capace. Va verificato esplicitamente sui casi difficili prima di mandare il sistema in produzione.

Perché il cutoff più vecchio non è un difetto

La data limite di Haiku 4.5 — febbraio 2025 secondo la documentazione — è la caratteristica che fa storcere il naso più spesso. Vale la pena spiegare perché in molti casi non significa nulla.

Ogni modello ha il proprio ciclo di addestramento. Un modello leggero che resta in catalogo perché continua a svolgere bene il suo compito conserva la data della propria epoca: non viene riaddestrato solo per aggiornare l'orologio. Che sia più vecchia non lo rende meno preciso nel classificare un messaggio o nell'estrarre una data da una fattura, perché quelle capacità non dipendono da quanto sa del mondo.

La domanda giusta è sempre la stessa: l'informazione della risposta viene dal documento o dal modello?

Le prime tre righe coprono la maggior parte del traffico aziendale, e in tutte e tre la data limite è irrilevante. Le ultime due descrivono compiti che comunque non andrebbero affidati alla conoscenza interna di nessun modello, per le ragioni spiegate in knowledge cutoff: cosa significa in pratica.

Quanto costa davvero, con un esempio

Prendiamo un caso concreto: 20.000 documenti al mese, ciascuno con circa 2.000 token di input e 500 di output. Usando i prezzi ufficiali del 19 agosto 2026, il conto mensile grezzo è questo.

Dieci volte fra la prima e l'ultima riga, su un volume tutt'altro che estremo. Se il compito è estrarre otto campi da una fattura, la prima riga probabilmente basta e le altre tre sono soldi buttati.

Attenzione però: questi numeri sono il pavimento, non il conto reale. Non includono il prompt di sistema ripetuto a ogni chiamata, i token di ragionamento e i tentativi falliti — le tre voci che nella pratica gonfiano la stima iniziale, come descritto in costo per task o prezzo per token.

Il caso in cui la tabella si ribalta

C'è uno scenario in cui la fascia alta costa meno di quella bassa, e non è raro. Succede quando il modello economico non chiude il compito al primo passaggio.

Se un modello leggero richiede in media tre tentativi e poi il quindici per cento degli esiti va comunque corretto a mano, il costo vero comprende tre chiamate più il tempo di una persona. Un modello più caro che chiude al primo colpo e non richiede revisione può risultare complessivamente più economico, soprattutto quando il tempo delle persone coinvolte è costoso.

È il motivo per cui la stima va fatta sul costo per compito completato e non sul prezzo di listino: sono due numeri che possono ordinare i modelli in modo opposto.

La strategia mista

Nella maggior parte dei progetti reali la risposta migliore non è un modello, sono due.

Il modello leggero gestisce il grosso del traffico: classifica, estrae, risponde ai casi standard. Quando incontra qualcosa di ambiguo o fuori schema, non prova a indovinare: passa il caso al modello più capace, che lo tratta con più attenzione.

Il risultato è che paghi il modello caro solo sulla frazione di traffico che lo richiede davvero, che nella pratica è spesso fra il cinque e il quindici per cento. Il conto finale si avvicina a quello del modello economico, la qualità a quella del modello potente.

Il criterio economico che ribalta la scelta

C'è un calcolo che quasi nessuno fa e che spesso capovolge la decisione presa sul listino.

Il costo totale di un sistema AI non è la spesa di API: è la somma fra spesa di API, tempo di revisione umana e costo degli errori non intercettati. Le ultime due voci non compaiono in nessun preventivo e sono quasi sempre più grandi della prima.

Se un modello più caro riduce sensibilmente la seconda voce — perché sbaglia meno o perché segnala in modo affidabile i casi dubbi — può costare meno in totale pur costando di più a chiamata.

Cosa dichiara Anthropic sul confronto

L'annuncio ufficiale di Claude Opus 5, pubblicato il 24 luglio 2026, contiene diverse affermazioni sul confronto con la generazione precedente. Le riportiamo attribuendole, perché sono dati auto-riportati dal produttore.

• Su Frontier-Bench v0.1, Opus 5 supera tutti gli altri modelli e più che raddoppia il risultato di Opus 4.8, a un costo per task inferiore
• Su tutte le valutazioni di scienze della vita citate, Opus 5 risulta migliore di Opus 4.8
• Su un benchmark interno di chimica organica, un vantaggio di 10,2 punti
• Su compiti relativi alle proteine, un vantaggio di 7,7 punti
• Opus 5 è indicato vicino a Fable 5 come intelligenza di frontiera, a circa metà prezzo

Lo stesso annuncio dichiara anche un limite: su cybersecurity il modello resta dietro a un concorrente. È un dettaglio che vale la pena notare, perché un comunicato che ammette dove perde è mediamente più affidabile di uno che non ammette nulla.

Come leggere questi numeri

Sono confronti interni: nuovo modello contro modello precedente dello stesso produttore. È la categoria di confronto più solida fra quelle auto-riportate, perché elimina gran parte delle asimmetrie descritte in perché i benchmark dei vendor non sono comparabili: stessa impalcatura, stessa competenza nell'ottimizzazione, stesso interesse a mostrare un progresso reale.

Resta il limite dell'auto-riporto: nessuna parte terza ha verificato quei numeri, e la selezione dei test citati è del produttore. Il dato sul costo per task, però, è insolito e utile — pochi annunci lo espongono, e per un'azienda è più informativo del punteggio.

Il costo per task, il numero che conta davvero

Fra tutte le affermazioni dell'annuncio, quella potenzialmente più rilevante per un'azienda non è il raddoppio del punteggio: è il costo per task inferiore.

La differenza è sostanziale. Un punteggio più alto ottenuto spendendo di più è un progresso tecnico ma non necessariamente un affare. Un punteggio più alto ottenuto spendendo di meno cambia l'economia del progetto, perché sposta la soglia oltre la quale un'automazione diventa conveniente.

L'ultima riga è quella interessante. Ci sono processi che non vengono automatizzati non perché il modello non ce la faccia, ma perché il conto non torna: troppi tentativi, troppa revisione umana, margine troppo sottile. Quando entrambi i fattori migliorano contemporaneamente, alcuni di quei processi entrano nella fascia sostenibile.

Il modo per verificarlo sul proprio caso è misurare il costo per compito completato invece del prezzo di listino, tenendo dentro contesto ripetuto, token di ragionamento e tentativi falliti. Il metodo è in costo per task o prezzo per token.

Cosa cambia sulla carta

Opus 4.8 non compare nella panoramica modelli attuale, quindi non ne riportiamo prezzo e caratteristiche: non li abbiamo verificati su una fonte ufficiale aggiornata e preferiamo non stimarli. Chi ha un contratto attivo trova i propri parametri nella console del proprio account.

Anthropic dichiara, nell'annuncio ufficiale del 24 luglio 2026, che Opus 5 su Frontier-Bench v0.1 più che raddoppia il risultato di Opus 4.8 a un costo per task inferiore. È un dato auto-riportato, discusso in Opus 5 vs Opus 4.8.

Fase 1: capire se ti serve

Prima di pianificare qualunque cosa, vale la pena verificare che il cambio abbia senso per il tuo caso.

Il miglioramento dichiarato riguarda soprattutto i compiti agentici: sequenze multi-passo portate a termine. Se il tuo sistema classifica messaggi o estrae campi da documenti, quel raddoppio potrebbe non toccarti affatto.

La colonna di destra descrive una situazione più comune di quanto si creda. Molti sistemi usano la fascia che è stata scelta all'inizio del progetto, quando nessuno aveva riferimenti, e non è più stata rimessa in discussione. Se sei in quella condizione, la migrazione è l'occasione giusta per verificare se non convenga andare nell'altra direzione.

Fase 2: preparare la prova

Serve un banco di prova prima di toccare qualsiasi cosa in produzione.

• Raccogli dieci casi reali, di cui almeno tre difficili
• Registra gli esiti attuali del sistema in produzione
• Annota costo e tempo attuali per caso
• Prepara lo stesso prompt per entrambi i modelli
• Definisci in anticipo cosa considererai un miglioramento
• Coinvolgi chi conosce il lavoro per la valutazione

Il quinto punto è quello che evita le discussioni inutili a fine prova. Decidere prima cosa significa «meglio» — meno tentativi falliti, meno correzioni manuali, risposte più precise su una classe specifica di casi — rende il confronto oggettivo invece che impressionistico.

Fase 3: rileggere i prompt

È il passaggio che porta più valore e che quasi tutti saltano.

I prompt di sistema in produzione accumulano nel tempo istruzioni scritte per correggere comportamenti specifici del modello in uso: «non aggiungere premesse», «non ripetere la domanda», «rispondi sempre in questo formato». Quando il modello cambia, quelle istruzioni restano.

Le conseguenze sono tre e si sommano. Occupano contesto, che si paga a ogni singola chiamata per sempre. Possono essere inutili, se correggono un comportamento che il nuovo modello non ha. E in alcuni casi peggiorano attivamente le risposte, perché rimediano a un problema inesistente introducendo un vincolo che non serve.

La rilettura richiede un'ora e produce spesso un prompt più corto, più chiaro e più economico. È probabilmente l'ora meglio investita dell'intera migrazione.

Fase 4: girare in parallelo

Per un sistema critico, la fase più prudente e meno costosa è far lavorare i due modelli fianco a fianco.

Le stesse richieste vengono mandate a entrambi. La produzione continua a usare la configurazione attuale; le risposte del modello nuovo vengono solo registrate. Dopo qualche giorno hai un confronto su traffico vero, con i tuoi casi reali e la loro distribuzione naturale di difficoltà.

L'ultima riga è la più preziosa. I casi in cui i due modelli danno risposte diverse sono pochi e concentrano tutta l'informazione utile: guardarli uno per uno dice più di qualunque statistica aggregata.

Fase 5: passare, con una via d'uscita

Il cambio in produzione dovrebbe essere reversibile in pochi minuti. Questo significa una cosa sola dal punto di vista tecnico: l'identificativo del modello sta in un solo posto configurabile, non sparso in venti punti del codice.

Con quella premessa, il passaggio si può fare gradualmente — una quota di traffico alla volta — e annullare immediatamente se emerge un problema.

• Tieni l'identificativo del modello in un unico punto
• Passa una quota di traffico alla volta
• Tieni sotto controllo costo e latenza i primi giorni
• Controlla a campione gli esiti reali, non solo le metriche
• Mantieni la possibilità di tornare indietro per qualche settimana

Le sorprese più frequenti

Nelle migrazioni fra modelli ci sono alcuni inconvenienti che si ripresentano con regolarità. Conoscerli in anticipo fa risparmiare tempo.

La verbosità cambia, e con lei il costo. Un modello diverso può produrre risposte sistematicamente più lunghe a parità di istruzioni. Siccome l'output è la voce cara del listino, una differenza di verbosità del trenta per cento si traduce direttamente in fattura. Va misurata sui token consumati, non a occhio.

Il formato di risposta si sposta. Se il sistema a valle si aspetta una struttura precisa e la ricava dal testo, un cambio di modello può romperla in modi sottili: una virgola in più, un campo formattato diversamente, un preambolo che prima non c'era. Sono errori che non compaiono nei test su dieci casi e si manifestano in produzione.

I casi limite si comportano diversamente. È il motivo per cui i tre casi difficili nel banco di prova non sono un dettaglio ma il cuore della verifica. Sui casi facili tutti i modelli si assomigliano.

La latenza cambia in entrambe le direzioni. Non dare per scontato che un modello più recente sia più veloce. Va misurato, specialmente se qualcuno attende la risposta.

Cosa fare se il confronto non è netto

Capita spesso: il modello nuovo è leggermente meglio su alcuni casi, leggermente peggio su altri, e la media non dice nulla. In quella situazione la decisione non va presa sulla qualità, che è sostanzialmente equivalente, ma sulle altre tre variabili.

L'ultima riga è un argomento pratico che vale la pena considerare esplicitamente. I modelli escono dai listini con una certa regolarità, e restare su una versione che non compare più nella documentazione significa affrontare la migrazione più avanti, magari con meno tempo a disposizione. A parità di tutto il resto, allinearsi alla versione corrente riduce il debito futuro.

Il criterio generale su quando ha senso cambiare — e quando invece conviene fermarsi — è sviluppato in quando conviene cambiare modello AI.

Cosa cambia in un aggiornamento di versione minore

In generale, il passaggio da una versione a una versione minore successiva tende a mantenere l'impostazione del modello, con miglioramenti mirati e un aggiornamento della data limite. È diverso da un cambio di generazione, che può modificare in modo più visibile il modo in cui il modello reagisce alle stesse istruzioni.

Questo ha una conseguenza pratica per chi ha un sistema in produzione.

• I prompt esistenti di solito continuano a funzionare, ma vanno riletti
• Le correzioni scritte per aggirare comportamenti vecchi possono essere inutili
• Il costo reale va rimisurato: cambia se cambia la verbosità
• La latenza va rimisurata negli scenari interattivi
• I casi limite vanno riprovati: è lì che emergono le differenze
• Conviene far girare le due versioni in parallelo per qualche giorno

Il secondo punto è quello che porta più valore e che quasi nessuno fa. I prompt in produzione accumulano nel tempo istruzioni scritte per correggere comportamenti specifici di un modello. Quando il modello cambia, quelle istruzioni restano lì: occupano contesto, si pagano a ogni chiamata e a volte peggiorano attivamente le risposte perché correggono un problema che non esiste più.

Perché i cataloghi cambiano così in fretta

Chi segue questo settore da poco resta spiazzato dalla velocità con cui i modelli entrano ed escono dai listini. Vale la pena capirne il meccanismo, perché ha conseguenze pratiche su come si progetta un sistema.

I fornitori tendono a mantenere in catalogo un numero limitato di modelli per fascia. Quando esce una versione successiva, la precedente resta accessibile per un periodo di transizione — così i sistemi in produzione non si rompono — ma smette di comparire nella documentazione di riferimento, che descrive ciò che si consiglia di usare oggi.

Da qui la situazione che questo articolo descrive: un modello di cui si parla, che compare in annunci e in documentazione tecnica, ma che non ha più una scheda pubblica aggiornata.

Cosa mettere in conto ogni sei mesi

Un sistema AI in produzione non è un progetto che si chiude: è una configurazione che va rivista periodicamente. Sei mesi è un intervallo ragionevole, e la revisione richiede poche ore.

La seconda riga è quella che porta più valore in assoluto. Nel giro di pochi mesi capita regolarmente che una fascia inferiore raggiunga il livello di qualità che prima richiedeva la fascia superiore. Chi non rifà la verifica continua a pagare il doppio per una qualità che ormai ottiene a metà prezzo.

La terza riga è la più trascurata e ha un effetto doppio: le istruzioni obsolete si pagano a ogni singola chiamata e possono peggiorare le risposte. Rileggere il prompt di sistema una volta ogni sei mesi è probabilmente l'ora meglio investita di tutto il progetto.

Come fare la verifica

Il metodo è quello descritto in come si leggono i benchmark AI, applicato al confronto fra versioni e fasce.

Prendi dieci casi reali del tuo processo, includendo almeno tre difficili. Eseguili su tre configurazioni: la tua attuale, Opus 5 al livello predefinito e Opus 5 al massimo. Annota qualità, costo e tempo per ciascuno.

Se le tre colonne si assomigliano, hai la risposta e stai per risparmiare parecchio. Se sui casi difficili la tua configurazione attuale resta nettamente avanti, hai la giustificazione per mantenerla — e ora è una scelta motivata invece che un'eredità.

Le domande da fare prima di scegliere

Tre verifiche precedono la scelta del modello e cambiano il risultato più di qualunque confronto.

Quali parti del carico hanno davvero qualcuno che aspetta? È un esercizio da mezz'ora che quasi sempre rivela una quota di lavoro senza urgenza — arricchimento di archivi, report periodici, classificazione retroattiva. Su quella quota la latenza esce dalla decisione e si sceglie guardando solo qualità e costo.

Quanto è lungo il prompt di sistema? Si paga a ogni singola chiamata. Su cinquantamila richieste mensili, ogni migliaio di token di istruzioni ripetute sono cinquanta milioni di token di input al mese. È la voce che nessuno mette in preventivo e che spesso si può dimezzare con un'ora di rilettura.

Il compito dipende dalla conoscenza interna del modello? Se l'informazione viene dai documenti che fornisci tu, la data limite è irrilevante e una fascia più economica resta in gioco. Se viene dalla memoria del modello, il problema non è la fascia ma l'impostazione.

Un errore ricorrente sui prompt in produzione

C'è una dinamica che si ripete in quasi tutti i sistemi rimasti in funzione per più di un anno, e che vale la pena riconoscere.

Ogni volta che il modello sbaglia qualcosa, qualcuno aggiunge un'istruzione correttiva al prompt di sistema. «Non aggiungere premesse.» «Non ripetere la domanda.» «Rispondi sempre in questo formato.» Nessuno le toglie mai.

Dopo un anno il prompt contiene correzioni per comportamenti di modelli non più in uso, esempi ridondanti e ripetizioni difensive. Le conseguenze sono tre e si sommano: occupano contesto che si paga a ogni chiamata, non servono più, e in alcuni casi peggiorano attivamente le risposte perché vincolano il modello a rimediare a un problema inesistente.

La prima riga è quella con il miglior rapporto fra sforzo e risultato, e va rifatta a ogni revisione semestrale insieme al confronto fra le fasce.

Esempi pratici

Studio commercialista, assistente sulle procedure interne. Il sistema risponde alle domande ricorrenti dei collaboratori attingendo alle circolari e alle procedure dello studio. Compito di recupero e riformulazione, volumi nell'ordine delle centinaia al mese. La fascia intermedia basta ampiamente, e vale la pena provare anche quella leggera: se i documenti sono ben organizzati, spesso è sufficiente. La variabile che conta non è il modello ma che dichiari quando la risposta non è nei documenti.

E-commerce, prima risposta ai clienti. Migliaia di messaggi al mese su spedizioni, resi e disponibilità. Qui pesa la velocità: il cliente ha la finestra aperta e aspetta. Il modello più leggero della famiglia è la scelta corretta su due fronti, perché costa un quinto e risponde prima. I casi fuori schema salgono al livello successivo, secondo l'impostazione descritta in strategia a modello misto.

Azienda di servizi, agente sul ciclo passivo. L'agente legge la fattura, verifica l'ordine, controlla le condizioni e propone la registrazione. Cinque passaggi concatenati in cui un errore intermedio si propaga: è lo scenario in cui la fascia alta si giustifica. Il numero da misurare non è la qualità della singola risposta, ma quanti casi arrivano a conclusione senza intervento umano.

Errori da evitare

• Scegliere il più costoso per sicurezza. Moltiplica la spesa senza guadagno sui compiti semplici.
• Scegliere il più economico per risparmiare anche dove serve ragionamento.
• Ignorare la latenza in scenari dove qualcuno attende.
• Confondere finestra e memoria. Il contesto si paga a ogni chiamata.
• Decidere senza provare sui propri documenti reali.
• Fissare un modello per sempre. Il catalogo cambia in fretta.

Come applicarlo in azienda

Il percorso pratico per una PMI si riduce a quattro passaggi, e richiede mezza giornata.

Primo: scrivi il compito in una frase e classificalo. Riconoscimento e trasformazione semplice da una parte, ragionamento a più passaggi dall'altra. È questa distinzione a stabilire la fascia minima, non l'importanza del progetto.

Secondo: parti dalla fascia più bassa plausibile e provala su dieci casi reali, di cui tre difficili e uno a cui manca l'informazione richiesta. Quest'ultimo è la prova che separa un modello utilizzabile da uno pericoloso.

Terzo: prima di salire di fascia, prova ad alzare il livello di ragionamento sulla stessa. Costa meno di un salto di categoria e in molti casi basta, come spiegato in reasoning effort: cosa cambia nei confronti.

Quarto: misura il costo per compito completato invece del prezzo di listino, con il metodo di costo per task o prezzo per token.

Se vuoi capire quale configurazione ha senso per i tuoi processi e portarla in produzione, Giallo Studio può aiutarti a trasformare il problema in un workflow reale.

Da qui, tre approfondimenti utili. Per orientarti fra le fasce di prezzo, il quadro completo è in quando basta un modello economico. Il modo corretto di leggere i numeri dichiarati dai produttori è in quando conviene cambiare modello AI. E per capire se il tuo compito richiede davvero la fascia che stai pagando, la verifica è in perché i benchmark dei vendor non sono comparabili.

Conclusione

La domanda "qual è il modello Claude migliore" non ha risposta utile. Quella che conta è: qual è il modello più economico che supera la tua soglia di qualità, sul tuo compito, misurato sui tuoi dati? Si risponde con una prova su una cinquantina di casi reali, non con una tabella.

E quando esce una versione nuova non serve correre: si verifica se il tuo caso peggiora, si gira in parallelo e si passa solo con una via d'uscita pronta. Per il quadro sui costi vedi prezzo per milione di token e i modelli economici a confronto; per la scelta fra fornitori diversi, Claude, GPT e Gemini.

L'AI diventa utile quando entra nei processi. Giallo Studio aiuta PMI e team a costruire automazioni concrete, misurabili e sostenibili.