Claude Opus 5 è uscito il 24 luglio 2026 e quasi tutto quello che trovi online è cronaca di quel giorno: benchmark, dichiarazioni, cinque punti chiave. Utile la prima settimana.
Se invece devi decidere se metterlo dentro un processo aziendale, le domande sono altre: quanto costa davvero, quale piano serve, chi controlla quello che produce e cosa si rompe quando lo colleghi ai tuoi sistemi. Questa pagina risponde a quelle.
La risposta breve
Opus 5 costa 5 dollari per milione di token in input e 25 in output, gli stessi di Opus 4.8, con prestazioni vicine a Fable 5 che costa il doppio. È questa la notizia, non la potenza: il rapporto qualità/prezzo è cambiato, il prezzo no.
Per un'azienda significa che l'aggiornamento dalla generazione precedente non aumenta la spesa. Quello che aumenta, se non stai attento, è il consumo — perché un modello più capace invoglia a dargli compiti più grandi.
Sonnet o Opus? La domanda che tutti fanno
È la ricerca correlata più frequente, e la risposta onesta è che non si decide leggendo i benchmark ma provando sul proprio compito.
- Sonnet 5 copre la maggior parte del lavoro ad alto volume: classificazione, estrazione, riformulazione, modifiche circoscritte. Costa meno e risponde più in fretta, e la latenza sull'esperienza utente pesa più di quanto si creda.
- Opus 5 serve quando il compito richiede di tenere insieme molti vincoli o molti file, o quando l'errore a metà percorso si propaga fino alla fine.
Il metodo pratico: parti da Sonnet, misura su dieci casi veri quante volte il risultato non è accettabile, e sali solo se quella percentuale ti costa più della differenza di prezzo. Su come sono fatti i conti di Sonnet 5 ho scritto una guida a parte, e il confronto con la fascia superiore sta nell'articolo su Fable 5 contro Opus 5.
Cosa serve per portarlo in azienda, oltre alle API
Qui sta la distanza tra "l'abbiamo provato" e "lo usiamo". Sono cinque cose, e nessuna riguarda il modello.
1. Decidere chi paga e come
Consumo API e abbonamento sono due economie diverse. L'API costa a token e scala con l'uso, senza tetti ma senza freni. L'abbonamento ha un costo fisso e un limite d'uso nella finestra oraria: prevedibile in bolletta, imprevedibile a metà pomeriggio quando qualcuno resta fermo.
Per un processo che deve girare tutti i giorni si va su API. Per il lavoro delle persone, abbonamento. Mescolarli senza deciderlo è il modo più comune di spendere male.
2. Sapere dove finiscono i dati
È la prima domanda che fa qualsiasi cliente con un contratto serio, e va risolta prima di scrivere codice, non dopo. Se ci sono dati che non possono uscire, il discorso cambia del tutto e si guarda ad altre architetture: ne ho scritto a proposito delle alternative in locale.
3. Stabilire chi verifica l'output
Un modello che si autocorregge riduce gli errori, non li elimina. Ogni processo automatizzato ha bisogno di un punto in cui una persona guarda il risultato, e di regole su cosa fare quando è sbagliato. Senza quel punto non hai automatizzato: hai delegato alla cieca.
4. Misurare il costo per compito, non per token
Il prezzo di listino non è la spesa. Quello che finisce in fattura dipende da quanto è lungo l'output e da quanti tentativi servono per un risultato accettabile. Un modello economico che ci prova tre volte costa più di uno caro che azzecca al primo colpo.
5. Collegarlo ai sistemi che avete già
Il salto di valore non arriva dal modello ma da cosa può leggere. Un assistente che non vede il gestionale risponde in astratto; uno collegato ai dati risponde sul vostro caso. Il modo standard per farlo è un server MCP, e su come si costruisce senza farsi male ho scritto questo articolo.
Gli errori che vedo fare più spesso
- Usare il modello più potente per tutto. Non ottieni risultati migliori, ottieni la stessa qualità con una fattura più alta.
- Partire dalla tecnologia invece che dal processo. "Vogliamo usare l'AI" non è un progetto. "Vogliamo ridurre il tempo di risposta ai preventivi" lo è.
- Aggiornare modello e prompt insieme. Se qualcosa peggiora non saprai cosa l'ha causato. Una variabile alla volta.
- Non tenere casi di prova. Senza una ventina di esempi reali con l'output atteso, ogni cambio di modello è un salto nel buio.
Se stai aggiornando da una versione precedente
Prima di toccare qualcosa, metti da parte quei casi di prova. Poi fai girare Opus 5 e cerca le regressioni, non i miglioramenti: quelli si notano da soli, i peggioramenti no.
Il punto dove si rompono più spesso le cose non è la qualità del ragionamento ma il formato dell'output: un JSON che cambia struttura manda in errore la pipeline anche quando la risposta è più intelligente di prima. Per chi viene da più indietro, il quadro completo sta nell'articolo su Opus 4.6.
Da dove partire
- Scegli un processo che oggi costa ore e ha un risultato verificabile.
- Raccogli venti casi reali con l'output che consideri corretto.
- Prova prima con Sonnet 5. Sali a Opus 5 solo sui casi che scarta.
- Misura il costo per compito completato e il tempo di verifica umana.
- Decidi solo allora se vale la pena metterlo in produzione.
Se questo percorso lo vuoi fare sui vostri processi invece che in astratto, è il lavoro che faccio per le aziende della zona: scrivimi e partiamo dal processo, non dal modello.
