Uno degli aspetti migliori dei nostri modelli Claude più recenti è il modo in cui rispondono all'effort senza invalidare la prompt cache in Claude Code, ma ho ricevuto moltissime domande dagli utenti a riguardo. Cos'è davvero l'effort e quando conviene usare un livello piuttosto che un altro? Perché ne abbiamo bisogno?
Per rispondere, ho deciso di fare un'analisi approfondita delle eval e di testare personalmente l'effort su normali attività lavorative.
nota: puoi trovare diagrammi interattivi e spiegazioni aggiuntive per questo articolo su https://claude.dev/blog/spending-your-effort/
A grandi linee, ho scoperto che l'effort è un ottimo strumento per modulare quanto lavoro di verifica e test sui casi limite Claude svolge, e quanto si affida al proprio giudizio autonomo.
Un effort maggiore ha prodotto risultati migliori negli ambiti in cui verifica e test sui casi limite sono più utili, come hardware, code review e sicurezza.
Ma un effort basso o medio si è rivelato perfetto per portare a termine le cose rapidamente e restare costantemente coinvolti nel processo con Claude.
Per il normale sviluppo software, ora seguo questo ciclo: chiedo al modello di intervistarmi, poi implemento con effort basso/medio, revisiono ciò che ha costruito e infine eseguo la verifica con effort alto.
Cos'è l'effort?
In sintesi, l'effort fornisce al modello un'indicazione approssimativa di quanta potenza di calcolo vuoi che dedichi al task. È in qualche modo legato alla tua percezione della difficoltà del compito.
Pensala così: se qualcuno ti chiedesse di lavorare a qualcosa per 12 ore di fila, daresti per scontato che voglia semplicemente che tu lo faccia, impegnandoti al massimo. Se invece ti chiedesse di completare lo stesso task in 1 ora, cercheresti di consegnargli la versione migliore possibile per poi aspettarti di iterare partendo da lì.
Oppure potresti obiettare, dicendo che quel lavoro richiede almeno 3 ore, e dedicarci quelle 3 ore per completarlo.
Dovresti concepire l'effort esattamente allo stesso modo. Claude cercherà sempre di svolgere il tuo task in modo ragionevole, ma con un effort più elevato agirà in modo più autonomo nelle fasi di valutazione e verifica.
Le curve dell'effort
Le curve di effort di Fable 5.1 e Opus 5.5 sono le migliori che abbiamo mai realizzato: a ogni livello si registra un incremento sia nei punteggi dei benchmark sia nei token consumati. Di seguito trovi un grafico dei punteggi di Terminal Bench 3.0 in base all'effort, misurati durante le mie eval per questo articolo.
Ma cosa significa tutto questo nella pratica? Per scoprirlo, ho provato diversi task a vari livelli di effort e ho analizzato minuziosamente i benchmark.
Sviluppare con l'effort
Il modo migliore per capire come funzionano i modelli è fare esperimenti. Ho eseguito gli stessi task a diversi livelli di effort su Opus 5.5 per comprendere come avrebbe lavorato. L'ho fatto su un'ampia varietà di attività, ma qui lo illustro con alcuni esempi didattici.
Task di sviluppo poco specificato
Se chiedo a Claude di "creare un'app personale per monitorare fitness e allenamenti", l'effort cambia drasticamente il livello di completezza dell'app, ma porta anche Claude a prendere più decisioni lungo il percorso. Con effort basso, l'app di fitness è solo un registro e un grafico semplice. A livelli di effort più alti l'app diventa più complessa e ricca di dettagli. Al massimo effort compare persino una mappa di calore.
Se volessi una base semplice su cui iterare, l'effort basso farebbe al caso mio. Il massimo effort sarebbe la scelta giusta se volessi il miglior risultato possibile da parte di Claude in un colpo solo.
Task di design leggermente specificato
E se avessi un task già abbastanza definito, ma volessi esplorare alcune possibilità insieme a Claude? Come esempio, gli ho chiesto di ridisegnare il menu /config in Claude Code. Ogni tentativo ruotava attorno alla stessa idea di fondo: usare sottomenu e una ricerca migliore.
Con effort basso (che ha richiesto 1 minuto), ho ottenuto uno schizzo interattivo che trasmetteva l'idea, ma non somigliava molto a Claude Code.
Con il massimo effort (che ha richiesto 28 minuti), ho ottenuto un mockup molto simile a Claude Code, accompagnato da una serie di walkthrough per i diversi flussi.
Se il mio obiettivo fosse iterare e dare feedback, l'effort basso ci arriverebbe molto più velocemente. Ma il massimo effort mi consegna subito qualcosa di decisamente più rifinito. Per questo specifico task, credo preferirei usare l'effort basso per capire meglio la visione di Claude.
Task di sviluppo altamente specificato
E se fornissi a Claude molti dettagli? Ho provato a chiedergli di intervistarmi a fondo sull'app di fitness, per poi passare quelle specifiche a modelli diversi affinché le implementassero a vari livelli di effort.
Ho notato che, con specifiche così precise, i modelli si comportavano in modo molto più simile. Ho ottenuto design piuttosto simili tra loro e implementazioni analoghe, seppur con dettagli differenti; al massimo effort, Claude si è preso del tempo per semplificare alcuni di questi dettagli.
Conclusioni
Nello sviluppo software quotidiano, soprattutto quando si lavora a nuove funzionalità, il livello di effort dipende molto da quanto voglio essere coinvolto nel processo. Un effort basso permette a Claude di rispondere rapidamente con un punto di partenza; livelli più alti portano a termine più lavoro, ma spingono Claude a fare più supposizioni al posto mio.
Un ciclo particolarmente efficace per lo sviluppo di feature che sto utilizzando è questo:
- Fornisci a Claude le specifiche e chiedigli di intervistarti sui dettagli mancanti
- Implementa con effort basso
- Revisiona per assicurarti che abbia colto il senso generale e itera con effort basso se necessario
- Verifica e testa con effort alto
Come i livelli di effort influenzano l'output nei task difficili
Questi, ovviamente, sono esempi didattici che Claude riesce a completare senza problemi. Ma cosa succede quando la differenza sta tra portare a termine il task o fallire?
Per trovare problemi davvero ostici bisogna guardare ai benchmark, così mi sono immerso in uno che apprezzo molto: Terminal Bench 3, un benchmark creato dalla community.
I problemi di Terminal-Bench 3.0 possono essere suddivisi in macro-categorie come sicurezza, hardware, ML, scienza, software, operations e media. Puoi consultarli tutti qui: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0; provengono dalla community, quindi chiunque può contribuire.
Vale la pena leggerli per farsi un'idea del tipo di problemi che questi modelli affrontano. Sono rimasto sorpreso dalla portata e dall'ambizione di molti di questi task. Sono decisamente più complessi delle attività medie che mi trovo ad affrontare.
Ad esempio, alcuni dei task includevano:
- Hardware (retro-console-soc): costruire una console di gioco a 8 bit in Verilog che giri su un piccolo FPGA ed esegua il rendering di una ROM di test.
- Scienza (takens-embedding-lean): dimostrare formalmente il teorema di embedding di Takens in Lean 4.
- ML (mp-checkpoint-consolidation): unire 16 shard di un checkpoint mixture-of-experts in un unico file che riproduca i logit di riferimento.
- Operations (intrastat-meldung): gestire da cima a fondo la dichiarazione mensile delle statistiche commerciali UE di un'azienda.
- Media (layout-config-recreation): ricostruire l'immagine di un poster come file di layout modificabile.
Livelli di effort più alti aiutano quando ci sono molti casi limite
La conclusione principale che ho tratto leggendo i risultati di Terminal Bench 3 è che un effort più alto è ideale per i task con molti casi limite nascosti.
Un esempio lampante è html-js-filter, un task di Terminal-Bench 3.0 che richiede un sanitizer HTML capace di bloccare qualsiasi tentativo di introdurre JavaScript in una pagina. Fable 5.1 è passato da 1/5 con effort basso a 5/5 con effort xhigh.
Un tipico tentativo con effort basso richiede circa 2 minuti. In ognuno di questi tentativi, il modello ha scritto un filtro praticamente in un solo passaggio, per poi testarlo su un'unica pagina scritta a mano.
Un'esecuzione con effort alto termina in circa 33 minuti. Nel run che ho analizzato, il modello ha prima revisionato in modo critico la sua bozza iniziale, poi ha letto il codice sorgente del parser installato per cercare bug, ha eseguito numerosi test case puliti finché non hanno restituito lo stesso output dell'input, ha lanciato una suite di test XSS standard e, infine, ha scritto un fuzzer per documenti casuali.
Per qualcosa di così pieno di casi limite come un sanitizer HTML, questo sforzo extra vale assolutamente la pena. Spendere più token per essere meticolosi ha senso anche per task complessi con requisiti di produzione elevati, come l'ottimizzazione delle prestazioni o una security review.
Ma non serve questo livello di effort per ogni task.
Il diagramma seguente mostra tutti i risultati di Terminal-Bench 3.0 e le relative cause di fallimento, suddivisi per modelli e livelli di effort. In generale, aumentare l'effort tende a ridurre i fallimenti dovuti a casi limite trascurati (blocchi viola), ma non risolve le situazioni in cui il modello sceglie un approccio sbagliato (blocchi blu).
Ambiti problematici in cui l'effort fa la differenza
Una delle scoperte più interessanti emerse valutando questi modelli su TerminalBench è che alcuni ambiti problematici hanno beneficiato dell'effort molto più di altri. Puoi vedere il dettaglio nel diagramma seguente:
Per illustrarlo, ho scelto alcuni problemi di aree diverse da Terminal Bench 3.0 in cui Opus 5.5 ha fallito con effort basso ma ha avuto successo con effort alto, principalmente perché ha testato e gestito i casi limite:
mvcc-lsm-compaction: un task di Terminal-Bench 3.0 che chiede di risolvere un bug dello storage engine partendo dal suo crash report, senza compromettere la compaction. Opus 5.5 è passato da 0/5 con effort basso a 4/5 con effort xhigh.
Con effort basso (circa un minuto per tentativo), Claude modificava il codice prima ancora di compilarlo o eseguire il reproducer, e non verificava se il nuovo test avrebbe intercettato il bug originale.
Con effort xhigh (circa 11 minuti), Claude ha prima riprodotto il crash, poi ha scritto un test randomizzato confrontandolo con un riferimento che non esegue mai la compaction, e ha verificato che i suoi test fallissero sulle correzioni incomplete.
cli-2ph-simple: è un task di Terminal-Bench 3.0 che richiede un solver CLI per la programmazione lineare scritto in Python. Opus 5.5 è passato da 0/5 con effort basso a 5/5 con effort alto.
I tentativi con effort basso scrivevano un solver in un solo passaggio, lo testavano su pochi problemi semplici e si fermavano intorno ai 10k token. Nell'ultimo messaggio, Claude avvisava che potrebbe risultare lento su problemi di grandi dimensioni, ma non lo verificava.
Durante i tentativi con effort alto, Claude ha testato il suo solver su problemi casuali confrontandolo con un secondo solver brute-force separato, ha poi cronometrato quelli più grandi, ha individuato casi che richiedevano troppo tempo o andavano in crash e ha rielaborato la sua logica di ricerca.
gsea-proteomics: un task di Terminal-Bench 3.0 che richiede un'analisi di arricchimento genico (GSEA) su dati proteomici per scoprire quali tra otto trattamenti somigliano a un tessuto target. Opus 5.5 è passato da 0/5 con effort basso a 4/5 con effort alto.
Con effort basso, Claude ha scelto un metodo apparentemente sensato per preparare i dati, ha eseguito l'analisi in quell'unico modo e ha riportato il risultato.
Con effort alto, Claude ha provato due metodi diversi per preparare i dati, ha notato che l'elenco dei trattamenti significativi cambiava e ha indagato il motivo prima di scegliere quello corretto.
Se un utente fosse stato coinvolto nel processo, Claude gli avrebbe probabilmente chiesto come impostare il problema; ma senza un umano nel loop, l'effort alto dà risultati migliori.
Quando usare i diversi livelli di effort in Claude Code
Ecco la mia regola pratica su quando usare ciascun livello di effort:
- Low: quando voglio risposte rapide mantenendo il controllo del processo, ad es. brainstorming, bozze, modifiche semplici
- Medium: per la maggior parte del mio lavoro di sviluppo software quotidiano, ad es. l'implementazione di nuove feature.
- High: per lavori in cui la verifica è fondamentale o ci sono casi limite, ad es. correggere un bug in una codebase brownfield.
- Max: quando voglio che Claude operi in totale autonomia per risolvere problemi complessi, ad es. creare e verificare un'app end-to-end, o scovare vulnerabilità di sicurezza in software critico.
Prova a variare l'effort per Opus 5.5 e Fable 5.1 in base al tuo task, o anche a metà conversazione, usando /effort in Claude Code e fammi sapere se corrisponde alla tua intuizione.
