Abbiamo domato la verbosità di Opus 5, resta un difetto

Chiedi a Opus 5 una correzione di due righe e ti ritrovi con una tesi di dottorato. Sul subreddit di Claude Code, un thread intitolato «Opus 5 is insufferable» ha superato 600 upvote e 178 commenti, con l'autore che accusa il modello di parlare una lingua inventata che chiama «Unintelligiblish». E Reddit è il posto educato: su X uno sviluppatore ha pubblicato solo uno screenshot dei commenti al codice generati da Opus 5 e ha raccolto 9.700 like. Boris Cherny, creatore di Claude Code, ha difeso pubblicamente il modello e si è preso la risposta più votata, «this response is part of the problem», con 2.843 like.

Dove	Segnale
r/ClaudeCode, «Opus 5 is insufferable»	600+ upvote, 178 commenti
X, screenshot dei commenti al codice di Opus 5	9.700 like
X, risposta alla difesa di Boris Cherny	2.843 like

Mentre le lamentele si accumulavano, Anthropic ha pubblicato in sordina una guida al prompting dedicata a Opus 5 che quasi nessuno ha aperto. Così abbiamo fatto il test che non fa nessuno: riprodurre i comportamenti che fanno impazzire tutti, applicare la guida riga per riga e misurare la differenza sugli stessi task.

Tre cambiamenti spiegano gran parte di quello che stanno vivendo gli sviluppatori.

Il thinking è attivo di default: il modello ragiona in un blocco privato prima di ogni risposta, e si può disattivare solo a effort high o inferiore. La finestra di contesto sale a un milione di token, sia come default sia come massimo. E il terzo cambiamento è quello che conta per le lamentele sulla verbosità: l'effort — il parametro che decide quanti token il modello spende a pensare, chiamare tool e scrivere la risposta — diventa la manopola centrale, con cinque livelli e high di default.

Effort	Comportamento
Low	Raggruppa le chiamate ai tool, niente preamboli, conferma in una frase
High (default)	Moltiplica le chiamate, spiega il piano prima di toccare qualsiasi cosa, commenta le modifiche in dettaglio
Extra high / Max	Esplora più file, blinda i casi limite; il thinking non si può più disattivare

Se la seconda riga suona esattamente come le tue sessioni, è normale: giri sul default dal primo giorno. L'effort non è una manopola della verbosità — ed è proprio questo malinteso a riempire i thread di Reddit.

Un ultimo tassello di contesto: Anthropic dichiara apertamente che Opus 5 scrive risposte più lunghe dei precedenti Opus e porta a termine i task invece di lasciare segnaposto. Parte di ciò che vivi come un bug è una scelta di design documentata — e una scelta documentata si può riconfigurare.

Non abbiamo dovuto cercarne nemmeno uno.

Verbosità. Abbiamo chiesto a Opus 5 di spiegare una funzione — una domanda la cui risposta sta in due frasi — e sono arrivati sezioni, sottotitoli e avvertenze, col tono di una relazione di audit. Il commento più votato del thread descrive esattamente questo: frasi di annuncio altisonanti in stile «abbiamo appena scoperto qualcosa che cambia tutto», seguite da dieci minuti di comandi shell.

Over-engineering. Un utente racconta di un file di decisioni da 7.000 righe; quando gli è stato chiesto di ripulirlo, Opus 5 ha tagliato 1.200 righe e poi ne ha aggiunte 600 nuove per documentare le cancellazioni. Abbiamo riprodotto lo schema su una piccola feature: la nostra istanza ha aggiunto un passaggio di verifica che nessuno aveva chiesto, poi ha scritto docstring da venti righe sopra funzioni da cinque.

Scope creep. Chiedi X, il modello decide che il vero argomento è Y e ti spiega perché in otto paragrafi.

Cattiva notizia sepolta. Un commentatore descrive un muro di testo che spiega che è andato tutto benissimo, con un asterisco a tre quarti che ammette che qualcosa si è rotto. L'abbiamo vissuto anche noi: la nostra istanza ha annunciato una migrazione riuscita, e la riga che ammetteva che i test di integrazione erano ancora da sistemare stava al settimo paragrafo.

La rabbia è reale e si riproduce su richiesta. Resta da capire se sia regolabile.

La guida si chiama Prompting Claude Opus 5, sta nella documentazione di Anthropic e risponde al thread di Reddit punto per punto. La sua frase più importante sta in una riga: l'effort controlla quanto il modello pensa, non quanto parla. Abbassare l'effort riduce il volume di ragionamento ma non accorcia in modo affidabile la risposta visibile — quindi tutti quelli che abbassano l'effort per zittire il modello stanno tirando la leva sbagliata.

Sulla lunghezza la guida è esplicita: la chiedi a parole, con un'istruzione di concisione nel system prompt. E dice una cosa che da Anthropic non ti aspetti: devi togliere istruzioni dai tuoi prompt. Se il tuo file di istruzioni dice «verifica il tuo lavoro prima di rispondere», cancella la riga: Opus 5 si controlla già da solo, e righe simili innescano passaggi di verifica extra, cioè token bruciati per niente. Boris Cherny l'ha riassunta in una riga: Opus 5 ha bisogno di meno prompting, non di più.

Il resto della guida affronta le altre lamentele in modo metodico — una sezione sulla narrazione dell'agent, una sulla lunghezza dei file generati, una sull'inquadramento dello scope, una sui subagent, una sull'autocorrezione — e ogni sezione ti consegna il blocco di prompt esatto da copiare, non un consiglio vago.

Un effort sweep significa eseguire lo stesso task a ogni livello di effort e confrontare token, tempo e qualità. La guida consiglia di rifarne uno se hai portato con te le impostazioni di un modello più vecchio. In pratica sono quattro run e un confronto.

In Claude Code l'effort si imposta in tre modi: un comando dentro la sessione, un flag al lancio o una chiave nel file di settings — quest'ultima ti dà un default diverso per progetto, quando i tuoi repo non hanno le stesse esigenze.

Abbiamo lanciato la stessa correzione di bug a low, medium, high ed extra high, in quattro sessioni pulite.

Livello	Risultato sulla nostra correzione di riferimento
Low / Medium	Correzione equivalente con una frazione dei token di high
High	Il default; nessun guadagno di qualità su un bug da una riga
Extra high	Più file esplorati, casi limite blindati — utile su un refactor pesante, sovradimensionato qui

Corrisponde a ciò che la guida annuncia quando ti dice di usare i livelli bassi con generosità come principale controllo dei costi. Un dettaglio di API da sapere prima di scriptare il tutto: a extra high e max il thinking non si può più disattivare, e la richiesta restituisce un errore 400 se ci provi.

L'uso più redditizio dello sweep è la code review. Anthropic sostiene che l'accuratezza di review di Opus 5 regge anche ai livelli di effort più bassi, il che permette un passaggio rapido ed economico al commit e uno profondo più tardi. L'abbiamo testato su un nostro diff: il passaggio low ha trovato gli stessi due bug reali del passaggio extra high, con circa un quinto dei token.

Quindi la prima impostazione che cambia la tua bolletta è scegliere l'effort per tipo di task invece di lasciare tutto sul default: low o medium per il lavoro quotidiano e le review, extra high per i lavori grossi. La verbosità, intanto, non si è mossa di una parola.

Visto che l'effort non accorcia le risposte, la lunghezza si imposta per istruzione — e dove metti quell'istruzione conta quanto ciò che dice. Un altro utente del subreddit di Claude Code ha passato giorni a testarlo, e la sua prima scoperta coincide con la nostra: l'output style Concise integrato taglia l'output solo di circa il 6 per cento. Ciò che ha funzionato è mettere una vera istruzione di concisione nello slot output style e da nessun'altra parte — la stessa frase come hook, o come regola nel file di istruzioni, non ha cambiato nulla.

Un output style è lo slot di Claude Code che definisce come scrive l'assistente, in contrapposizione a ciò che sa. Il nostro l'abbiamo costruito dalla formulazione della guida ufficiale: risposte brevi e mirate, avvertenze ridotte, un riepilogo ad alto livello a meno che non vengano chiesti i dettagli.

Dove sta la regola di concisione	Effetto sulla lunghezza
Preset Concise integrato	~6 per cento più corta
Hook, o regola nel file di istruzioni	Nessun cambiamento misurabile
Slot output style	Relazione in cinque sezioni → un paragrafo e un elenco di file

La guida aggiunge due istruzioni sorelle che abbiamo copiato così come sono: una per la narrazione dell'agent, che stabilisce quando il modello può commentare ciò che sta facendo, e una per i file scritti su disco, perché anche le relazioni e i file Markdown generati si gonfiano.

Per le regole che non scattano mai, lo stesso post di Reddit fornisce il criterio: una regola deve nominare un momento riconoscibile e un'azione concreta. «Tieni il changelog aggiornato» non scatta mai. «Quando modifichi un file nella cartella sorgente, aggiungi una riga al changelog nello stesso commit» scatta.

Resta un tic verbale che questi blocchi non coprono: l'autocorrezione narrata. Opus 5 adora annunciare che sta correggendo una frase precedente anche quando la correzione non cambia nulla per te, e la guida ha un'istruzione dedicata: segnalare una correzione solo se l'errore cambierebbe il tuo codice o le tue decisioni, e correggere il resto in silenzio. Da quando quella riga è entrata nella nostra config, i mea culpa finti sono spariti.

Quindi la verbosità si doma, solo non con un interruttore: con quattro blocchi di prompt messi negli slot giusti.

La lamentela numero due si risolve togliendo testo, non aggiungendone. Abbiamo iniziato ripulendo dai nostri prompt ogni richiesta di verifica, esattamente come ordina la guida, e il ciclo di verifica extra è sparito insieme a loro.

Poi, per lo scope, la guida fornisce un'istruzione di inquadramento che abbiamo incollato così com'è: consegna ciò che è stato chiesto nell'ambito previsto, segnala in una frase se esiste un approccio migliore e prosegui sul task richiesto invece di trasformarlo di nascosto. Sulla feature che aveva innescato le nostre docstring da venti righe abbiamo rigiocato esattamente la stessa richiesta con quell'inquadramento: il diff è sceso da nove file toccati a tre, senza passaggi di verifica parassiti.

Due impostazioni della stessa famiglia meritano una riga ciascuna. Per la code review, smetti di scrivere «segnala solo i problemi seri»: Opus 5 lo prende alla lettera e sotto-riporta, quindi chiedi tutto e filtra in un secondo passaggio. E se il modello lancia subagent al minimo pretesto, anche quello è documentato: Opus 5 delega più volentieri dei predecessori, e ogni subagent moltiplica il costo. La guida fornisce un'istruzione che riserva la delega ai lavori grossi davvero parallelizzabili, e dalla versione 2.1.217 Claude Code espone anche due variabili d'ambiente che limitano rigidamente la profondità di spawn e il numero di agent in esecuzione simultanea.

Limite	Default
Profondità di spawn dei subagent	3 livelli
Agent simultanei	20

Questi default spiegano come una sessione possa allargarsi tanto senza mai chiederti un parere. L'over-engineering non è un destino del modello: sono in gran parte i tuoi vecchi prompt che ti si ritorcono contro.

Il limite è netto: la guida sistema la forma di ciò che Opus 5 dice, non ciò che decide di fare. Parte degli sfoghi del thread descrive qualcosa di diverso dalla verbosità: un modello che riconosce un vincolo esplicito, promette di rispettarlo e poi fa il contrario dal primo turno. Quella lamentela non ha una sezione nella guida, e nessuno dei nostri blocchi di prompt l'ha fatta sparire. L'abbiamo visto una volta durante i test: un vincolo esplicito su un'API da non toccare, riconosciuto nella risposta, aggirato due turni dopo. Una volta in una settimana di sessioni è lontano dal naufragio descritto da certi sfoghi, ma è il tipo di errore che nessuna impostazione giustifica quando finisce sul codice di produzione.

C'è anche un costo d'ingresso. Lo sweep brucia token veri: le nostre quattro sessioni di test hanno mangiato l'equivalente di una grossa giornata di lavoro su un piano da 20 dollari, e un utente nel thread riferisce che il piano max più grande sopravvive a stento a un fine settimana a effort high. E nessuna di queste impostazioni è portabile: l'output style, l'inquadramento dello scope e i limiti sui subagent vivono tutti nella tua config, quindi ogni macchina e ogni progetto va ritarato.

Se il tuo problema è il rumore, la guida lo risolve. Se il tuo problema è un modello che fa quello che vuole, non ti salverà — e il commento più votato del thread dopo lo sfogo stesso resta «torna al precedente Opus».

A noi sono bastati venti minuti di impostazioni: l'effort scelto per tipo di task invece del default, un'istruzione di concisione nello slot output style, l'inquadramento dello scope della guida nel system prompt e le richieste di verifica cancellate dai nostri vecchi file.

Metrica sul nostro task di riferimento	Prima	Dopo
Lunghezza della risposta	Relazione in cinque sezioni	~5× più corta, un paragrafo + elenco file
Dimensione del diff	9 file toccati	3 file toccati
Costo della code review	Passaggio extra high	~1/5 dei token, gli stessi due bug reali

Senza cambiare modello né piano. Se le tue lamentele sono verbosità e over-engineering, fai questa messa a punto prima di cambiare modello: è tutto documentato, e la differenza si vede dal primo diff. Se invece il tuo problema è un modello che ignora i tuoi vincoli dal primo turno, nessun prompt della guida lo ripara: tieni i task sensibili su un modello che ti obbedisce, e torna a testare Opus 5 al prossimo aggiornamento.