Opus 5: ottimo dipendente, capo frustrante

Anthropic ha rilasciato Opus 5 il 24 luglio 2026 [1]. Cinque giorni dopo, le reazioni si sono divise in due fazioni che sembrano descrivere due modelli diversi. Artificial Analysis lo misura un punto sopra Fable 5 sul proprio indice di intelligenza, a metà prezzo per token [2]. Intanto una fetta rumorosa di Reddit rivuole il modello di prima.

Sono entrato nella settimana di lancio con una teoria di lavoro: Opus 5 è un ottimo dipendente e un capo frustrante. Dopo cinque giorni passati a leggere tutto quello che ho trovato (documentazione ufficiale, valutazioni indipendenti e decisamente troppi thread su Reddit), la teoria regge, con una correzione. Opus 5 non è il modello stupido descritto dai post più arrabbiati. Esegue al livello di Fable. Quello che gli manca è la direzione: leggere l’intento, rispettare il perimetro e capire quando ha davvero finito.

I numeri sono vicini, e sono veri

Sull’indice di intelligenza di Artificial Analysis, Opus 5 a effort massimo fa 61 contro il 60 di Fable 5. Nessuno dovrebbe leggere un punto di distacco come prova di qualcosa, se non del fatto che i due modelli giocano nella stessa classe di capacità [2].

Sotto l’indice generale, Opus 5 guida in realtà diverse valutazioni più mirate. Ha segnato 1.861 Elo su GDPval-AA v2 (lavoro professionale della conoscenza) e 1.720 su AA-Briefcase (deliverable agentici), rispettivamente 114 e 146 Elo sopra Fable. Ha condiviso il primo posto nel Coding Agent Index a effort xhigh e ha toccato l’89% su Terminal-Bench 2.1 al massimo [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

La lezione della tabella non è che Opus sia più intelligente. È che sul lavoro delimitato, a forma di deliverable, il modello economico ormai se la gioca alla pari con l’ammiraglia. I numeri della stessa Anthropic puntano nella stessa direzione: a mezzo punto da Fable su CursorBench 3.2 a effort massimo, e sopra il miglior risultato OSWorld di Fable a circa un terzo del costo. Sono misurazioni del produttore, quindi trattale come marketing con le ricevute [1].

Cosa descrive davvero l’ondata di critiche

La critica più utile della settimana arriva da qualcuno a cui il modello piace. Ha fatto girare il proprio set di task di codice reali, e Opus 5 è stato l’unico modello a fare il 100%, con la migliore implementazione e disciplina di test che avesse mai visto. Eppure il post lo chiama “an incredible coder and really painful to work with” [4]. Quella tensione è l’intera discussione in una frase.

Leggendo i thread negativi oltre la rabbia, tornano sempre gli stessi cinque schemi di fallimento.

Perde il quadro d’insieme. Codice locale solido, decisioni più deboli su architettura, intento del sistema esistente e persino su quali componenti andrebbero toccati. Uno sviluppatore lo ha descritto mentre inventava meccanismi nuovi e preferiva i propri pattern a quelli del repo, per poi scegliere Fable 5 più un vecchio Opus per il lavoro quotidiano [5].

Corre sulle assunzioni invece di chiedere. Quando mancano dati fondamentali, va avanti e costruisce qualcosa di coerente sopra una premessa sbagliata. Sembra che “il modello non ascolti”. Il meccanismo somiglia piuttosto a un prior agentico: continuare invece di bloccarsi su una domanda [5].

Canta vittoria troppo presto. Il loop classico: Opus dice risolto, l’utente ritrova lo stesso bug più una regressione, Opus si scusa nei dettagli, e si ricomincia. In una sessione di audit il modello aveva mancato 46 errori perché il suo stesso script li nascondeva in silenzio; altri riportano verifiche mai realmente avvenute [6]. Su migrazioni e configurazioni di deploy, un “fatto” falso costa più di un bug normale.

Parla troppo. Narrazione continua, aggiornamenti di stato chilometrici, dettagli minori trattati come grandi decisioni. Lo stesso tester che gli ha dato il 100% descrive uno stile di comunicazione nervoso e pedante, stancante da supervisionare [4].

Le vecchie istruzioni lo avvelenano. Almeno un utente ha risolto i propri problemi riscrivendo istruzioni di progetto e memorie scritte in origine per Opus 4.x [7]. Quei file sono pieni di compensazioni (“controlla sempre due volte”, “prima fai un piano dettagliato”, “usa i subagenti”) che un modello con iniziativa di serie trasforma in fuorigiri.

E qui la parte strana: la guida al prompting di Anthropic si legge come la specifica ufficiale di questa lista di lamentele. Dice che Opus 5 narra di più, si autoverifica, delega più volentieri ai subagenti, può ampliare il perimetro, può aggiungere passi non richiesti e può applicare il proprio giudizio su cosa il task “dovrebbe” essere. I rimedi consigliati: limiti di perimetro espliciti, tetti ai subagenti e un prompt dedicato per accorciare gli aggiornamenti di stato [8].

Per correttezza: la fazione positiva è altrettanto reale. Un tester concentrato su task di conoscenza e business ha trovato gli effort basso e medio migliori sia di Sonnet 5 sia di Opus 4.8, con Fable unico modello costantemente davanti, e solo sui problemi più difficili [9].

I benchmark valutano il traguardo, non la guida

Le due fazioni possono avere ragione insieme, perché un benchmark e un progetto vivo valutano cose diverse.

Un benchmark controlla se lo stato finale passa. Un progetto guarda anche se il modello ha lavorato sul problema giusto, quante volte hai dovuto afferrare il volante e se ti fidavi ancora dopo tre ore. Il numero di punta di Anthropic su Frontier-Bench (più del doppio del punteggio di Opus 4.8) viene da un run interno con uno specifico harness mini-SWE-agent, mediato su cinque tentativi per task [1]. È una metodologia legittima, e leviga proprio quello che chi lavora sente: la varianza tra le singole sessioni.

Un dato indipendente combacia fin troppo bene con le lamentele. Su AA-Omniscience, Artificial Analysis ha trovato Opus 5 più accurato nei fatti rispetto a Opus 4.8, ma anche più disposto a rispondere nell’incertezza. Con il metro di quel test, il suo tasso di allucinazione si è fermato intorno al 50% [2]. Non significa che metà delle risposte di Opus sia inventata; il test mette apposta i modelli all’angolo su ciò che sanno a metà. Ma dà un nome a un meccanismo: un modello tarato per andare avanti risolve più task e prende più decisioni sbagliate con sicurezza, con la stessa manopola.

Metà prezzo per token non è metà prezzo per task

Il listino dice che Opus 5 costa la metà di Fable 5: 5 $ in ingresso e 25 $ in uscita per milione di token, contro 10 $ e 50 $ [10].

• Opus 5
• Fable 5

Mostra i dati in tabella

Direzione	Opus 5	Fable 5
Input	5 $/MTok	10 $/MTok
Output	25 $/MTok	50 $/MTok

Misurato end-to-end, il divario si restringe. Artificial Analysis ha pagato 2,03 $ per task di Opus 5 sulla propria suite di valutazioni contro 2,75 $ con Fable, un risparmio del 26% invece del 50% [2]. E un utente Reddit che ha fatto passare due task di codice reali e corposi su entrambi i modelli è arrivato a 106,69 $ con Opus contro 118,46 $ con Fable, circa il 10% di differenza, giudicando per giunta il risultato di Fable nettamente migliore. Sul secondo task, Opus è costato di fatto di più [11].

È il test di una persona sola, non uno studio. Ma il meccanismo lo riconosce chiunque abbia visto un agente prendere la strada panoramica: più deviazioni, più chiamate agli strumenti, più codice, più giri di correzione, e comunque una passata di review con il modello costoso alla fine. Il listino è per token. Il prezzo vero è per deliverable approvato.

Un anno, quattro personalità di Opus

Parte della rabbia è il colpo di frusta. Se ti sembra che Opus cambi carattere a ogni versione, il materiale della stessa Anthropic ti dà ragione.

La linea del tempo disegna un pendolo, non una retta. Le date vengono dai post di rilascio [12] [13] [14] [1]; le letture sul carattere dalla ricerca di Anthropic sui valori dei modelli, che collocava 4.6 verso deferenza, brevità ed esecuzione, e 4.7 verso cautela, profondità e franchezza [15]. Le note di migrazione di 4.7 lo dicevano senza giri: seguito più letterale delle istruzioni, più voglia di contraddire, meno chiamate agli strumenti a effort basso, e vecchi prompt dal comportamento a volte strano [13]. 4.8 è stato venduto in gran parte come correzione degli eccessi di commenti e spiegazioni di 4.7 [14]. Opus 5 torna a spingere sull’iniziativa, più in là di tutti [8].

Ogni oscillazione invalida il folklore dei prompt scritto per il modello precedente. Le compensazioni che rendevano affidabile 4.6 diventano il fuorigiri che rende sfiancante 5. Questo, molto più di un complotto, spiega perché riscrivere le vecchie istruzioni sistemi così tanto [7].

Spiega anche la memoria corta. La settimana di lancio di Opus 4.8 produsse lo stesso genere di thread oggi puntati contro Opus 5 [16]. Nove settimane dopo, ci sono post che descrivono 4.8 come il vecchio modello stabile che la gente rivuole [17]. Cinque giorni di reazioni sono una lista di modi di fallire, non un verdetto.

La teoria del nerf, smontata strato per strato

Ogni release di Opus prima o poi raccoglie l’accusa che Anthropic l’abbia peggiorata di nascosto. Conviene separarla in strati, perché le prove cambiano da strato a strato.

I pesi. Per Claude 4.6 e successivi, Anthropic dichiara che gli ID modello senza data sono snapshot bloccati; i pesi non vengono sostituiti sotto lo stesso ID [18]. Non ho trovato prove pubbliche del contrario. La versione forte della teoria (“hanno sostituito di nascosto il buon 4.8”) non ha niente dietro.

Lo strato di serving. Routing, classificatori di sicurezza e fallback invece cambiano. Per Opus 5 è documentato che certe richieste segnalate come sensibili sul fronte cyber possono essere servite tramite un fallback a Opus 4.8, anche in alcune valutazioni pubblicate [1]. Due utenti possono chiamare lo stesso ID modello e ricevere trattamenti diversi.

L’harness del prodotto. Qui sono sepolti i cadaveri. Il postmortem di Anthropic di aprile 2026 documenta tre regressioni reali in Claude Code mentre l’API restava quasi intatta: l’effort di default è sceso in silenzio da high a medium (dal 4 marzo al 7 aprile), un bug di contesto cancellava ripetutamente il thinking più vecchio dopo inattività (dal 26 marzo al 10 aprile), e un system prompt che tagliava la lunghezza delle risposte è costato in modo misurabile circa il 3% sulle valutazioni di coding (dal 16 al 20 aprile) [19].

Il tuo stesso contesto. CLAUDE.md stantii, vecchie memorie, una sessione inquinata. Stesso snapshot, esperienza diversa.

Il verdetto onesto sul “nerf”: l’esperienza è spesso reale e a volte perfino riproducibile. La diagnosi punta quasi sempre allo strato sbagliato.

I prodotti di Anthropic danno già per scontata la divisione

La prova più forte a favore dello schema dipendente-capo è che Anthropic lo ha trasformato in prodotto.

Il nuovo strumento Advisor collega un modello esecutore più economico a un consulente più forte che può leggere la sessione di lavoro, proporre un piano o correggere la rotta a metà task. La documentazione lo consiglia proprio per design, architettura e valutazione dei rischi, ed elenca Opus 5 come esecutore con Fable 5 come advisor tra le combinazioni supportate. L’advisor deve essere almeno capace quanto l’esecutore. Avvertono anche del guasto opposto: troppe chiamate all’advisor rendono tutto più lento e costoso senza guadagno netto [20].

owner

• Tu obiettivo, vincoli, gusto

fissa la rotta

direzione

• Fable 5 architettura, pacchetti di task

pacchetti di task

esecuzione

• Opus 5 codice, test, verifica

diff e prove

review

• Fable 5 audit ai milestone

Il diagramma è la conclusione pratica dell’intera settimana: l’obiettivo resta umano, Fable fissa e verifica la direzione, e Opus macina il lavoro in mezzo a metà prezzo per token.

Due sfumature tengono onesto lo schema. Primo, Anthropic chiaramente non considera Opus incapace di pianificare: Claude Code continua a offrire una modalità ufficiale opusplan in cui Opus pianifica e Sonnet esegue [21]. Secondo, Fable non è un capo infallibile. La sua stessa guida avverte che può pianificare troppo, rifattorizzare senza che nessuno glielo chieda e gonfiare la dimensione dei task, e che lavora meglio quando gli spieghi perché vuoi una cosa [23].

Ma il posizionamento è coerente ovunque: Fable 5 resta il modello più capace ampiamente disponibile, consigliato quando la capacità conta di più, mentre Opus 5 è la scelta di default per il coding agentico complesso sul rapporto capacità-prezzo [10]. Al lancio di Fable, Anthropic lo disse in modo diretto: più il task è lungo e complesso, più cresce il vantaggio di Fable [22].

Un ultimo studio appartiene a questa sezione. Anthropic ha analizzato circa 400.000 sessioni di Claude Code di circa 235.000 utenti: gli umani prendevano ancora circa il 70% delle decisioni di pianificazione, mentre gli agenti prendevano circa l’80% di quelle di esecuzione. I prompt degli utenti esperti attivavano in media circa 12 azioni dell’agente e 3.200 parole contro 5 e 600 dei principianti, e il tasso di successo verificato stava intorno al 15% per i principianti contro il 28-33% dal livello intermedio in su [24]. Un modello così intraprendente non abbassa l’asticella della direzione. La alza.

Come userei Opus 5 questa settimana

Il mio instradamento dopo una settimana di letture, da rivedere quando avrò più chilometri miei:

Task	Modello
Bug chiaro con riproduzione e test	Opus 5
Feature delimitata con criteri di accettazione	Opus 5
Refactor verso un’architettura target nota	Opus 5, poi review di Fable
Root cause poco chiara tra più sistemi	Piano con Fable 5, poi Opus 5
Nuova architettura destinata a durare anni	Prima Fable 5
Lunghe sessioni agentiche su più fronti	Fable 5 come orchestratore
Migrazione ad alto rischio	Design Fable, esecuzione Opus, audit Fable

Configurazione, dritta dalla documentazione più un’opinione. Lascia il thinking attivo: è il default, l’effort basso con thinking batte lo spegnerlo a costo simile, e disattivarlo può innescare comportamenti strani con gli strumenti [8]. Sali la scala dell’effort invece di partire da xhigh; la regolazione cambia il modello al punto che basso e massimo sono in pratica due prodotti diversi [2]. Blocca gli ID modello completi quando confronti qualsiasi cosa, perché gli alias si spostano [21]. E cancella ogni compensazione dell’era 4.x dalle tue istruzioni prima di giudicare il modello [8].

Il system prompt da cui partirei, al posto del vecchio boilerplate “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.

Il dipendente e il capo

Opus 5 non è un Fable in saldo, e nemmeno un passo indietro con un nome nuovo. Sul lavoro delimitato con un traguardo chiaro è forte quanto qualsiasi cosa tu possa noleggiare in questo momento, e costa meno del fratello maggiore. E l’ondata di critiche non si immagina le cose: la stessa iniziativa che vince i benchmark diventa perimetro fuori controllo, ipotesi sicure di sé e giri di vittoria prematuri appena l’obiettivo si sfoca.

Quindi dagli quello che serve a ogni senior brillante e troppo sicuro di sé. Un capo. Il migliore disponibile oggi è Fable 5, e l’obiettivo resta tuo.