Opus 5 è un ottimo dipendente, ma un capo frustrante

Anthropic ha rilasciato Opus 5 il 24 luglio 2026 e, dopo la prima settimana, il mio giudizio è semplice: è un ottimo dipendente, ma un capo frustrante [1]. Cinque giorni di ricerca mi hanno mostrato un modello che eguaglia Fable 5 nei principali benchmark e costa la metà per token, ma diventa meno affidabile quando deve stabilire la direzione [2].

Opus 5 è capace quanto Fable 5? Nei benchmark, quasi

Nei benchmark pubblicati, Opus 5 e Fable 5 rientrano nella stessa fascia di capacità. Con effort massimo, Artificial Analysis assegna 61 punti a Opus nel suo indice di intelligenza, appena sopra i 60 di Fable. Un punto di differenza è troppo poco per definire Opus il modello più intelligente [2].

Metrica	Opus 5	Fable 5
Indice di intelligenza AA	61	60
GDPval-AA v2, Elo	1861 (Valore migliore della riga)	1747
AA-Briefcase, Elo	1720 (Valore migliore della riga)	1574
Costo misurato per task di eval, $	2,03 (Valore migliore della riga)	2,75

Le valutazioni più specifiche di Artificial Analysis confermano questa conclusione. Opus ha raggiunto 1.861 Elo su GDPval-AA v2, che misura il lavoro professionale basato sulla conoscenza, e 1.720 su AA-Briefcase, dedicato al lavoro svolto dagli agenti. Supera così Fable rispettivamente di 114 e 146 Elo. Ha inoltre condiviso il primo posto nel Coding Agent Index con effort xhigh e raggiunto l’89% su Terminal-Bench 2.1 con effort massimo [2].

Questi risultati mostrano che il modello più economico può eguagliare Fable quando il task ha limiti chiari e un risultato specifico. Anthropic rileva lo stesso comportamento: con effort massimo, Opus è arrivato a meno di mezzo punto da Fable su CursorBench 3.2 e ha superato il miglior risultato di Fable su OSWorld spendendo circa un terzo. Queste ultime misurazioni provengono da Anthropic, quindi attribuisco più peso ai risultati indipendenti riportati sopra [1].

Perché Opus 5 riceve tante critiche? Per la supervisione

Le critiche riguardano soprattutto quanto sia faticoso supervisionare Opus, non la qualità del suo codice.

L’esempio più chiaro arriva da un utente che gli ha assegnato il 100% su una serie di task di programmazione reali. Secondo lui, Opus aveva prodotto l’implementazione migliore e mostrato la migliore disciplina nei test che avesse mai visto. Nonostante questo, lo ha definito “an incredible coder and really painful to work with” [4].

Nelle discussioni negative ricorrono cinque problemi.

Perde di vista l’intero sistema. Opus può scrivere buon codice per una parte del progetto e, nello stesso tempo, prendere decisioni deboli sull’architettura che la circonda. Uno sviluppatore racconta che inventava nuovi meccanismi, preferiva le proprie convenzioni a quelle del repository e modificava componenti che avrebbero dovuto restare invariati; per il lavoro quotidiano è quindi tornato a Fable 5 e a una versione precedente di Opus [5].

Fa ipotesi invece di chiedere. Quando mancano informazioni importanti, Opus può procedere sulla base di un’ipotesi plausibile ma errata. Il risultato sembra coerente, però risolve il problema sbagliato e lascia all’utente la sensazione di non essere stato ascoltato [5].

Dichiara il lavoro concluso troppo presto. Opus può annunciare una correzione mentre il problema iniziale è ancora presente, talvolta insieme a una nuova regressione. Durante un audit, il suo stesso script ha nascosto 46 errori che il modello non ha quindi rilevato; altri utenti lo hanno visto dichiarare di aver verificato il lavoro senza averlo fatto davvero [6]. Una falsa dichiarazione di completamento diventa particolarmente costosa durante una migrazione o una modifica al deploy.

Fornisce troppi aggiornamenti. Tra descrizioni di azioni di routine, lunghi rapporti sullo stato e piccoli dettagli trattati come decisioni importanti, la comunicazione finisce per ostacolare il lavoro. Il tester che gli ha assegnato il 100% l’ha infatti definita nervosa, pedante e stancante da supervisionare [4].

Le vecchie istruzioni possono peggiorarlo. Almeno un utente ha risolto questi problemi riscrivendo istruzioni e memorie di progetto create per Opus 4.x [7]. Questi file spesso chiedono di controllare tutto due volte, preparare piani dettagliati o creare subagenti. Poiché Opus 5 tende già a prendere l’iniziativa, le vecchie precauzioni possono spingerlo troppo oltre.

La guida al prompting di Anthropic documenta lo stesso insieme di comportamenti: Opus 5 descrive più spesso il proprio lavoro, lo verifica da solo e crea subagenti con maggiore facilità, oltre a poter ampliare il perimetro o aggiungere passaggi non richiesti. Anthropic consiglia quindi di stabilire limiti espliciti per il task e per il numero di subagenti, chiedendo direttamente aggiornamenti di stato più brevi [8].

Le testimonianze positive sono altrettanto credibili. Un tester che usava il modello soprattutto per attività legate alla conoscenza e al lavoro aziendale ha trovato Opus migliore di Sonnet 5 e Opus 4.8 con effort basso o medio; soltanto Fable è rimasto costantemente superiore, e solo sui problemi più difficili [9].

Perché benchmark e utenti non concordano? Misurano lavori diversi

I benchmark e i progetti reali misurano lavori diversi, quindi entrambi i tipi di risultati possono essere corretti. Un benchmark controlla soprattutto se il risultato finale supera i test; un progetto mostra anche se il modello ha scelto il problema giusto, ha richiesto correzioni ripetute e ha descritto il lavoro in modo onesto.

Questa differenza conta quando si legge il risultato di Anthropic su Frontier-Bench, più che doppio rispetto a quello di Opus 4.8. Anthropic ha usato uno specifico harness mini-SWE-agent e calcolato la media di cinque tentativi per task [1]. Il metodo è ragionevole, ma la media riduce il peso delle singole sessioni insolitamente buone o cattive, proprio quelle che gli utenti tendono a notare di più.

Un risultato indipendente aiuta a capire la distanza tra le due esperienze. Su AA-Omniscience, Artificial Analysis ha trovato Opus 5 più accurato di Opus 4.8, ma anche più disposto a rispondere quando non era sicuro; secondo il sistema di valutazione del benchmark, il suo tasso di allucinazione è stato di circa il 50% [2]. Ciò non significa che metà di una normale risposta sia inventata, perché il test pone deliberatamente domande che i modelli possono conoscere solo in parte. Mostra invece un compromesso: continuare nonostante l’incertezza aiuta a risolvere più task, ma può produrre anche più errori espressi con sicurezza.

Opus 5 costa davvero la metà? Solo per token

Opus 5 costa la metà per token, ma completare un task costa di solito più della metà di quanto costerebbe con Fable. Claude Platform Docs indica per Opus un prezzo API di 5 $ per milione di token in input e 25 $ per milione in output, contro 10 e 50 $ per Fable [10].

• Opus 5
• Fable 5

Mostra i dati in tabella

Tipo di token	Opus 5	Fable 5
Input	5 $/MTok	10 $/MTok
Output	25 $/MTok	50 $/MTok

La differenza si riduce non appena si misura l’intero lavoro. Nella propria suite di valutazioni, Artificial Analysis ha speso 2,03 $ per ogni task di Opus 5 e 2,75 $ per Fable, ottenendo un risparmio del 26% anziché del 50% [2]. Un utente Reddit ha trovato un divario ancora più piccolo su due grandi task di programmazione: 106,69 $ per Opus e 118,46 $ per Fable, una differenza di circa il 10%. L’utente ha giudicato il risultato di Fable nettamente migliore, mentre sul secondo task Opus è costato di più [11].

Il confronto utile è il costo di un risultato accettato, non soltanto il prezzo di ciascun token. Il test di due task condotto da una sola persona non permette di stabilire un costo medio, ma mostra come passaggi inutili, chiamate aggiuntive agli strumenti, codice non richiesto e cicli di correzione possano assorbire lo sconto. Se Fable deve comunque verificare il risultato, si aggiunge un altro costo.

Perché ogni release di Opus sembra diversa? Cambia il comportamento

Ogni release di Opus può comportarsi in modo abbastanza diverso da frustrare chi aveva trovato prompt efficaci con quella precedente. I materiali pubblicati da Anthropic descrivono molti di questi cambiamenti.

Le release non seguono un percorso lineare verso una maggiore iniziativa. Le date provengono dai post di Anthropic sui rilasci [12] [13] [14] [1], mentre i riepiloghi dei comportamenti si basano anche sulla sua ricerca sui valori dei modelli. Lo studio associa Opus 4.6 alla tendenza ad assecondare l’utente, alla brevità e all’esecuzione, e 4.7 alla cautela, alla profondità e alla franchezza [15].

Le note di migrazione rendono evidente questa evoluzione. Opus 4.7 seguiva le istruzioni più letteralmente, contraddiceva più volentieri l’utente ed effettuava meno chiamate agli strumenti con effort basso, tanto che Anthropic avvertiva che i vecchi prompt potevano funzionare male [13]. Opus 4.8 ha poi ridotto i commenti e le spiegazioni eccessivi di 4.7 [14], prima che Opus 5 tornasse con decisione verso una maggiore iniziativa [8].

Un’istruzione utile a un vecchio modello può quindi diventare controproducente. Più pianificazione e verifica possono aver aiutato Opus 4.6, ma con Opus 5 generano facilmente troppi piani, commenti e passaggi aggiuntivi. Ecco perché riscrivere le vecchie istruzioni di progetto può risolvere tanti problemi [7].

Con il passare del tempo, anche le testimonianze della prima settimana possono assumere un significato diverso. Opus 4.8 ha ricevuto lamentele simili al lancio [16], ma nove settimane dopo alcuni utenti lo descrivevano come il modello stabile che volevano riavere [17]. Cinque giorni di reazioni bastano a segnalare possibili problemi, non a formulare un giudizio definitivo.

Anthropic ha peggiorato Opus di nascosto? Non ho trovato prove

Non ho trovato prove che Anthropic abbia sostituito di nascosto i pesi di un modello Opus. L’esperienza può comunque peggiorare, perché la gestione delle richieste, l’harness del prodotto e il contesto dell’utente possono cambiare in modo indipendente.

I pesi del modello. Anthropic afferma che gli ID API senza data di Claude 4.6 e versioni successive rimandano a snapshot fissi, quindi i pesi non vengono sostituiti mantenendo lo stesso ID [18]. Questo sistema di versionamento documentato rende meno plausibile una sostituzione silenziosa dei pesi.

La gestione delle richieste. Routing, classificatori di sicurezza e modelli di riserva, invece, possono cambiare. Anthropic documenta che alcune richieste di cybersecurity segnalate e inviate a Opus 5 vengono gestite da Opus 4.8, anche in alcune valutazioni pubblicate [1]. Due richieste allo stesso ID modello possono quindi seguire percorsi diversi. OpenAI ha incontrato la sua versione del problema del rischio cyber, che affronto in che cosa OpenAI ha confermato su Astra e perché ha rallentato i lavori.

L’harness del prodotto. Il resoconto di Anthropic dell’aprile 2026 descrive tre regressioni di Claude Code che hanno colpito molto meno l’API. Senza avviso, l’effort predefinito è prima passato da high a medium tra il 4 marzo e il 7 aprile. Un bug di contesto ha poi rimosso più volte parti precedenti del ragionamento dopo periodi di inattività, tra il 26 marzo e il 10 aprile, e un system prompt ha infine limitato la lunghezza delle risposte dal 16 al 20 aprile. Anthropic attribuisce a quel prompt una riduzione di circa il 3% nelle valutazioni di coding [19]. I limiti di utilizzo rientrano nello stesso gruppo: la quota settimanale più bassa di Claude Code dopo la fine di una promozione è un cambio di piano, non di modello.

Il tuo contesto. Anche vecchie istruzioni di CLAUDE.md, memorie salvate o una sessione diventata molto lunga possono modificare il comportamento percepito, pur lasciando identico lo snapshot del modello.

Il peggioramento segnalato può quindi essere reale e talvolta riproducibile anche quando la diagnosi è sbagliata. In molti casi sono cambiati il prodotto, la configurazione o il contesto, non i pesi del modello.

Anthropic usa la stessa divisione: Opus esegue, Fable consiglia

Anthropic usa la stessa divisione di base del mio paragone tra dipendente e capo. Il suo strumento Advisor abbina un esecutore più economico a un modello più capace che può indicare la direzione, e la documentazione propone Opus 5 come esecutore e Fable 5 come advisor.

L’advisor può leggere la sessione corrente, proporre un piano e correggere il lavoro durante il task, quindi Anthropic lo consiglia per design, architettura e valutazione dei rischi. Deve essere capace almeno quanto l’esecutore, ma chiamarlo più spesso non garantisce un risultato migliore: la documentazione avverte che troppe chiamate rallentano il task e lo rendono più costoso senza migliorarlo [20].

responsabile

• Tu obiettivo, vincoli, criteri di accettazione

fissa la direzione

direzione

• Fable 5 architettura, task delimitati

task delimitati

esecuzione

• Opus 5 codice, test, verifica

implementazione e risultati dei test

verifica

• Fable 5 verifica ai passaggi chiave

Questa struttura assegna una responsabilità netta a ciascuno: tu definisci l’obiettivo e i vincoli, Fable crea il piano e verifica i passaggi importanti, mentre Opus lo implementa con un prezzo per token inferiore. Da allora ho usato questa divisione su grandi feature multi-agente e ho messo il risultato a confronto con Codex nel mio confronto tra Claude e Codex sulle feature grandi.

La distinzione ha comunque dei limiti. Anthropic non considera Opus incapace di pianificare: Claude Code include una modalità ufficiale opusplan nella quale Opus prepara il lavoro e Sonnet lo esegue [21]. Neppure Fable è un capo perfetto. La sua guida al prompting avverte che può pianificare troppo, fare refactoring senza autorizzazione e trasformare un piccolo task in un grande progetto; funziona meglio quando l’utente spiega perché serve una modifica [23].

Questa distinzione coincide con il posizionamento di Anthropic, che consiglia Fable 5 quando serve la massima capacità e presenta Opus 5 come il miglior rapporto tra prezzo e prestazioni per gli agenti di programmazione complessi [10]. Al lancio di Fable, l’azienda ha inoltre dichiarato che il suo vantaggio cresce con la lunghezza e la complessità dei task [22]. Quando Anthropic ha rilasciato il Fable successivo, ho confrontato Fable 5.1 e Opus 5 sui compiti lunghi degli agenti e sul prezzo.

Un’analisi di circa 400.000 sessioni di Claude Code condotte da circa 235.000 utenti rafforza questa idea. In quelle sessioni, gli utenti prendevano quasi il 70% delle decisioni di pianificazione, mentre gli agenti gestivano circa l’80% delle decisioni di esecuzione. I prompt degli utenti esperti portavano in media a 12 azioni dell’agente e 3.200 parole, contro 5 azioni e 600 parole per i principianti; anche il tasso di successo verificato saliva da circa il 15% al 28–33% per gli utenti intermedi o avanzati [24]. Per quanto proattivo, un modello ha quindi ancora bisogno di indicazioni umane chiare.

Come userei Opus 5: delimita il task e verifica il risultato

Affiderei a Opus lavori di implementazione ben delimitati e lascerei a Fable i task in cui la direzione non è chiara, l’architettura e le revisioni ad alto rischio.

In base ai risultati e alle testimonianze disponibili, oggi sceglierei tra i due modelli nel modo seguente. Potrei cambiare questa tabella dopo averli usati più a lungo in prima persona. Quell’uso diretto ora è raccontato in se Opus 5 sia davvero così male come dice internet.

Attività	Modello
Bug chiaro con riproduzione e test	Opus 5
Feature delimitata con criteri di accettazione	Opus 5
Refactoring verso un’architettura già definita	Opus 5, poi revisione di Fable
Causa iniziale poco chiara tra più sistemi	Piano con Fable 5, poi Opus 5
Nuova architettura destinata a durare anni	Prima Fable 5
Lunghe sessioni con più agenti in parallelo	Fable 5 come orchestratore
Migrazione ad alto rischio	Progettazione con Fable, esecuzione con Opus, verifica con Fable

Prima di cambiare modello, modificherei la configurazione. Lascerei attivo il thinking: è l’impostazione predefinita, un effort basso con thinking funziona meglio che disattivarlo a un costo simile, e la disattivazione può causare comportamenti insoliti nelle chiamate agli strumenti [8]. Partirei da un effort basso e lo aumenterei quando il task richiede più ragionamento, invece di usare sempre xhigh; Artificial Analysis ha misurato una grande differenza tra i livelli minimo e massimo [2].

Per un confronto corretto, userei gli ID completi dei modelli, perché gli alias possono cambiare [21]. Prima di valutare Opus 5, eliminerei anche tutte le istruzioni aggiunte per compensare i problemi di Opus 4.x [8].

Partirei da questo system prompt invece della vecchia istruzione “sii scrupoloso e proattivo”:

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

Questo prompt non trasformerà Opus in Fable, e non dovrebbe farlo. Opus 5 dà il meglio quando il task ha limiti e criteri di accettazione chiari, perché in quel contesto può produrre un lavoro eccellente a un prezzo per token inferiore. Quando l’obiettivo è poco chiaro, la stessa iniziativa può invece generare lavoro aggiuntivo, ipotesi errate presentate con sicurezza e false dichiarazioni di completamento.

Per questo userei Opus come dipendente, non come capo. Al momento Fable è più adatto a stabilire e verificare la direzione, ma l’obiettivo devi ancora definirlo tu.