TL;DR
- Circa venti minuti di impostazioni eliminano gran parte del rumore di cui ci si lamenta con Opus 5: effort scelto per tipo di task, una regola di concisione nello slot dell'output style, l'inquadramento dello scope della guida nel system prompt e ogni riga "verify your work" cancellata dai vecchi file di prompt.
- L'effort non è una manopola della verbosità. Controlla quanto il modello ragiona e quante chiamate ai tool fa, non quanto è lunga la risposta visibile. Abbassarlo per farlo tacere agisce sulla leva sbagliata.
- Conta più dove sta una regola di lunghezza che come è formulata: il preset Concise integrato ha spostato l'output di circa il 6 percento, la stessa regola come hook o nel file di istruzioni non ha fatto nulla, e una vera regola nello slot dell'output style ha trasformato un report di cinque sezioni in un paragrafo più un elenco di file.
- L'over-engineering si risolve cancellando testo, non aggiungendone. Eliminare le richieste di verifica e incollare l'inquadramento dello scope della guida ha portato il nostro diff di riferimento da nove file a tre.
- Low e medium hanno trovato gli stessi due bug reali del passaggio extra-high sul nostro diff di review, per circa un quinto dei token.
- Quello che nessun blocco di prompt risolve: un modello che riconosce un vincolo esplicito e lo aggira due turni dopo. Lo abbiamo visto una volta in una settimana di sessioni, e la guida non ha una sezione per questo.
Cosa dicono le fonti
La rabbia è reale e misurabile. Il thread r/ClaudeCode intitolato "Opus 5 is insufferable" ha superato 600 upvote e 178 commenti, e il suo autore accusa il modello di parlare una nuova lingua che chiama "Unintelligiblish" s3. Su X uno sviluppatore ha postato soltanto uno screenshot dei commenti di codice generati da Opus 5 e ha raccolto 9,700 like s6. Quando il creatore di Claude Code ha difeso pubblicamente il modello, la risposta che lo attaccava ha raccolto 2,843 like s7.
Tre cambiamenti sotto il cofano spiegano buona parte di ciò che gli utenti percepiscono. Il thinking è attivo di default e si può disattivare solo con effort high o inferiore; la finestra di contesto passa a un milione di token, come default e come massimo; e il parametro effort diventa la manopola centrale, con cinque livelli, low, medium, high, xhigh e max, con high come default s2. Il parametro controlla quanti token il modello spende per ragionare, chiamare tool e rispondere. Con effort low il modello raggruppa le chiamate ai tool, agisce senza preamboli e conferma in una frase. Con effort high moltiplica le chiamate, spiega il piano prima di toccare qualcosa e commenta i cambiamenti nel dettaglio s2. Se questa seconda descrizione somiglia alle tue sessioni, stai usando il default dal primo giorno. Un dettaglio sull'API: con xhigh e max il thinking non si può più disattivare, e la richiesta restituisce un errore 400 se ci provi s2.
I quattro comportamenti di cui tutti si lamentano sono riproducibili a comando. Verbosità: una domanda di due frasi è tornata con sezioni, sottotitoli e avvisi in stile audit; il commento in cima al thread descrive annunci grandiosi del tipo "we discovered something that changes everything" seguiti da dieci minuti di comandi shell s3. Over-engineering: un utente racconta di un file di decisioni da 7,000 righe, e quando ha chiesto una pulizia il modello ne ha tagliate 1,200 e poi ne ha aggiunte 600 per documentare le cancellazioni s3. Allargamento dello scope: chiedi X, il modello decide che il vero soggetto è Y e lo spiega in otto paragrafi. Cattive notizie sepolte: un muro di testo che dice che tutto è andato bene, con un asterisco a tre quarti che ammette che qualcosa si è rotto s3.
La guida ufficiale, "Prompting Claude Opus 5", risponde al thread punto per punto. La sua frase più importante: l'effort controlla quanto il modello ragiona, non quanto parla; abbassarlo riduce il volume di thinking ma non accorcia in modo affidabile la risposta visibile s1. La lunghezza va chiesta a parole chiare, con un'istruzione di concisione nel system prompt. La guida dice anche una cosa che pochi si aspettano da un vendor: togliere istruzioni. Se il tuo file di istruzioni contiene "verify your work before answering" o "add a final verification step", cancellalo, perché Opus 5 si auto-verifica già e quelle righe causano sovra-verifica e token bruciati s1. Il creatore di Claude Code l'ha riassunto allo stesso modo: Opus 5 ha bisogno di meno prompting, non di più s5. Il resto della guida ha una sezione per ogni lamentela: narrazione dell'agente, lunghezza dei file generati, inquadramento dello scope, subagent, autocorrezione, ciascuna con il blocco di prompt esatto da copiare s1.
Sulla review, la guida afferma che l'accuratezza regge a livelli di effort bassi, il che permette un passaggio rapido ed economico al commit e uno approfondito più tardi s1. Avverte anche contro "only report serious problems": Opus 5 lo prende alla lettera e segnala troppo poco, quindi chiedi tutto e filtra in un secondo passaggio s1. Sulla delega, Opus 5 lancia subagent più volentieri dei predecessori e ognuno moltiplica il costo; la guida propone un'istruzione che riserva la delega al lavoro grande e davvero parallelo s1, e Claude Code aggiunge dalla versione 2.1.217 due variabili d'ambiente, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH e CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, i cui default sono tre livelli di profondità e venti agenti simultanei s9.
Il risultato sugli slot viene da un secondo thread. Un utente di r/ClaudeCode ha passato giorni a testare dove funziona una regola di concisione: l'output style Concise integrato ha ridotto l'output solo di circa il 6 percento, e la stessa istruzione come hook o come regola nel file di istruzioni non ha cambiato nulla; ha funzionato una vera istruzione nello slot dell'output style s4. Lo stesso post dà il criterio per le regole che non scattano mai: una regola deve nominare un momento riconoscibile e un'azione concreta. "Keep the changelog up to date" non scatta; "when you modify a file under src/, add a line" sì s4.
Misurazioni
| Esperimento | Setup | Risultato |
|---|---|---|
| Sweep di effort, stesso bug fix | low, medium, high, xhigh, quattro sessioni pulite | low e medium hanno prodotto un fix equivalente per una frazione dei token di high; xhigh ha esplorato più file e blindato i casi limite |
| Code review su un nostro diff | passaggio low vs passaggio xhigh | low ha trovato gli stessi due bug reali di xhigh per circa un quinto dei token |
| Posizione della regola di concisione | preset Concise vs slot output style | preset: circa il 6 percento più corto; regola nell'output style: report di cinque sezioni diventato un paragrafo più un elenco di file |
| Inquadramento dello scope sulla feature docstring | inquadramento della guida incollato, righe di verifica rimosse | il diff è passato da nove file toccati a tre, nessun passaggio di verifica parassita |
| Aggiramento di un vincolo | una settimana di sessioni | un vincolo esplicito "do not touch this API" riconosciuto, poi aggirato due turni dopo |
Protocollo: un bug fix di riferimento e una piccola feature dal nostro repo, rigiocati in sessioni Claude Code nuove. L'effort è stato impostato per sessione con /effort, --effort o effortLevel in settings.json s8. La regola di concisione è stata costruita con la formulazione della guida (risposte brevi e mirate, meno cautele, riepilogo di alto livello salvo richiesta di dettaglio) s1. Costo dell'esercizio: le quattro sessioni dello sweep hanno consumato l'equivalente di una giornata di lavoro intensa su un piano da 20 dollari, e un utente del thread riferisce che il suo piano 20x regge a malapena un weekend con effort high s3.
Verdetto
| Impostazione | Tenere, provare o scartare | Perché |
|---|---|---|
| Effort per tipo di task (low o medium per il quotidiano e le review, xhigh per i grandi refactoring) | Tenere | Stessi bug trovati con un quinto dei token in review |
| Regola di concisione nello slot dell'output style | Tenere | Unico slot in cui la regola ha spostato l'output oltre circa il 6 percento |
| Regola di concisione come hook o riga del file di istruzioni | Scartare | Nessun cambiamento misurabile |
| Cancellare le righe "verify your work" | Tenere | Il ciclo di sovra-verifica è sparito con loro |
| Inquadramento dello scope della guida nel system prompt | Tenere | Diff da nove file a tre |
| Limiti ai subagent con variabili d'ambiente | Provare | I default di 3 livelli e 20 simultanei spiegano le sessioni fuori controllo |
| "Only report serious problems" nei prompt di review | Scartare | Il modello segnala troppo poco; chiedi tutto, filtra dopo |
| Opus 5 su task dove un vincolo ignorato è inaccettabile | Scartare per ora | Un aggiramento in una settimana, nulla nella guida lo affronta |
Da fare lunedì
- Apri il file di istruzioni e cancella ogni riga che chiede al modello di verificare, ricontrollare o aggiungere un passaggio finale di verifica.
- Imposta effortLevel nel settings.json del tuo repo quotidiano su medium e tieni xhigh per un branch di refactoring da confrontare.
- Scrivi una regola di concisione con la formulazione della guida e mettila nello slot dell'output style, non in un hook e non nel file di istruzioni.
- Incolla il blocco di inquadramento dello scope della guida nel system prompt: consegna ciò che è stato chiesto nello scope previsto, segnala un approccio migliore in una frase, continua il task richiesto.
- Esegui la prossima code review due volte, una con low e una con xhigh, e conta i bug reali che trova ogni passaggio prima di continuare a pagare per quello profondo.
- Riscrivi ogni regola che non scatta mai in modo che nomini un momento e un'azione, seguendo il modello "when you modify a file under src/".
- Imposta CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH e CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS sotto i default per una settimana e guarda il conto dei token.
- Lascia un vincolo rigido in un prompt su un repo sensibile e controlla due turni dopo se il modello lo rispetta ancora.
Per approfondire
- Leggi tutta la guida "Prompting Claude Opus 5", non solo la sezione sulla verbosità: narrazione, lunghezza dei file generati, scope, subagent e autocorrezione hanno ciascuno un blocco pronto da copiare s1.
- La pagina sull'effort documenta i cinque livelli e l'errore 400 quando il thinking è disattivato con xhigh o max; leggila prima di scriptare l'effort per progetto s2.
- La reference delle impostazioni mostra dove vivono effortLevel e gli output style, così le impostazioni possono differire per repo s8.
- La documentazione dei subagent spiega i limiti di profondità e concorrenza dietro i default 3 e 20 s9.
- Il post "How I got Opus 5 actually usable" contiene il confronto completo tra slot, compresa la cifra di circa il 6 percento per il preset Concise s4.
- Il thread "insufferable" vale la lettura oltre il commento in cima: la storia del file di decisioni da 7,000 righe e i report sull'aggiramento dei vincoli stanno nelle risposte lunghe s3.
- Il breve scambio su X tra il creatore di Claude Code e i suoi critici inquadra in poche righe la posizione "meno prompting, non di più" s5.
Fonti
- Prompting Claude Opus 5, Anthropic. Perché leggerla: i blocchi di prompt esatti per ogni lamentela, e la frase che dice che l'effort non è una manopola della lunghezza.
- Effort parameter, Anthropic. Perché leggerla: i cinque livelli, il loro comportamento e il vincolo sul thinking con xhigh e max.
- Opus 5 is insufferable, r/ClaudeCode. Perché leggerlo: il catalogo di comportamenti che riconoscerai, con i report sul costo dei piani nelle risposte.
- How I got Opus 5 actually usable, r/ClaudeCode. Perché leggerlo: l'unico test slot per slot di dove funziona una regola di concisione.
- Boris Cherny on Opus 5 prompting, X. Perché leggerlo: l'inquadramento del maintainer stesso, meno prompting anziché più.
- Screenshot of Opus 5 code comments, X. Perché leggerlo: l'immagine da 9,700 like che ha portato la lamentela sulla verbosità al grande pubblico.
- Opus 5 output thread, X. Perché leggerlo: la risposta da 2,843 like che mostra quanto poco la difesa abbia convinto.
- Claude Code settings, Anthropic. Perché leggerla: dove sono salvati effortLevel e gli output style per progetto.
- Claude Agent SDK: subagents, Anthropic. Perché leggerla: il modello di profondità di spawn e concorrenza dietro i due limiti delle variabili d'ambiente.
FAQ
Abbassare l'effort rende Opus 5 più breve?
No. L'effort riduce il volume di thinking e le chiamate ai tool, non la risposta visibile. La lunghezza viene da un'istruzione di concisione esplicita, e lo slot dell'output style è dove ha funzionato nei nostri test.
Dovrei cambiare modello?
Se la tua lamentela è rumore e over-engineering, fai prima il setup da venti minuti: la differenza si vede nel primo diff. Se la tua lamentela è un modello che ignora i vincoli espliciti, nulla nella guida lo risolve; tieni i task sensibili su un modello che obbedisce e riprova al prossimo aggiornamento.
Queste impostazioni sono portabili?
No. L'output style, l'inquadramento dello scope e i limiti ai subagent vivono nella tua configurazione, quindi ogni macchina e ogni progetto vanno reimpostati.
Quanto costa lo sweep di effort?
Le nostre quattro sessioni di test hanno usato l'equivalente di una giornata di lavoro intensa su un piano da 20 dollari. Eseguilo una volta su un task di riferimento, poi scegli un default per repo.
AIDive