L'impostazione “max effort” di Claude Opus 5 fa lievitare il prezzo di una richiesta di routine da 0,76 $ a 19,21 $, pur fornendo essenzialmente lo stesso output funzionale. La spesa extra acquista una fase di audit interno, non una soluzione migliore, e mostra guadagni misurabili solo su compiti che iniziano con una bassa copertura dei test.
Cosa ha mostrato il test
L'esperimento ha confrontato il livello di sforzo predefinito di Claude Opus 5 con la manopola “max effort” su due tipi di prompt: compiti di programmazione quotidiani e problemi deliberatamente difficili.
- Per un compito tipico, l'esecuzione a basso sforzo si è conclusa in due minuti con un costo di 0,76 $. Portando l'impostazione al massimo, il conto è salito a 19,21 $, eppure il punteggio di copertura dei requisiti — la metrica che il modello riporta per indicare quanto bene abbia soddisfatto le istruzioni — è rimasto identico.
- La trascrizione mostra uno spostamento dalla creazione alla revisione. Il modello ha smesso di generare nuovo codice e ha iniziato a rifinire ciò che aveva già scritto. Le modifiche hanno superato le nuove scritture con un rapporto di 2,4 a 1. Le chiamate allo strumento
readsono aumentate di diciotto volte, e le invocazioni dello strumentobashsono cresciute di sei volte. In pratica, il modello ha riletto i moduli, ha rieseguito i propri test, ha effettuato il linting e persino il mutation testing senza che gli venisse chiesto.
La manopola “max effort” non introduce un nuovo algoritmo; aumenta semplicemente il budget che il modello può spendere. Una volta che il budget è sufficientemente ampio, il modello passa a una modalità di auto-audit, cercando qualsiasi piccolo accorgimento su cui possa giustificare la spesa.
Perché i costi aumentano drasticamente
Quando il modello decide di effettuare un audit, ogni chiamata extra a read o bash si aggiunge al conto, e gli effetti moltiplicatori fanno gonfiare rapidamente il costo totale.
La modalità audit è una scelta di progettazione esplicita. Il modello interpreta il budget più elevato come un permesso per “cercare qualcosa che valga la pena di essere corretto”. Se non appare nulla da migliorare, la spesa extra non produce alcun beneficio funzionale.
Quando uno sforzo maggiore ha senso
La modalità audit brilla solo quando l'output iniziale lascia spazio a miglioramenti. In un progetto Go con una copertura dei test di 0,73, spingere lo sforzo al massimo ha portato la copertura a 0,88.
Al contrario, un compito in Python che aveva già raggiunto una copertura di 0,98 non ha mostrato alcun cambiamento quando il budget è stato aumentato. Il modello si è limitato a ricontrollare lo stesso codice di alta qualità, gonfiando il costo senza aggiungere valore.
Possibili svantaggi
- Esplosione del budget – Gli utenti abituati ai prezzi del basso sforzo potrebbero rimanere sorpresi da un aumento di venticinque volte per lo stesso risultato.
Guida pratica per gli sviluppatori
- Mantieni i prompt di routine al livello di sforzo predefinito. Otterrai lo stesso risultato funzionale per una frazione del prezzo.
- Riserva il “max effort” per il codice che non soddisfa una chiara soglia di qualità: bassa copertura dei test, avvisi di lint mancanti o altre lacune misurabili.
- Tratta l'impostazione come una modalità separata: un passaggio opzionale di auto-revisione piuttosto che un comando rapido per ottenere risposte migliori.
In sintesi
L'interruttore “max effort” di Claude Opus 5 scambia denaro con un controllo di qualità interno, non con un codice migliore. Usalo con parsimonia, solo quando i tuoi risultati di base lasciano un vuoto quantificabile da colmare; altrimenti, l'impostazione predefinita economica offre lo stesso risultato senza il prezzo della modalità audit.
Community discussion: https://t.me/GyaanSetuAi