Claude Code, ecco 5 strumenti notevoli che (forse) ancora non conoscete

Anthropic ha aggiunto a Claude Code cinque strumenti che cambiano il modo in cui l’agente affronta un compito di programmazione: effort, che regola quanto sforzo di ragionamento dedica prima di agire; plan mode, che separa l’analisi dalla modifica dei file; goal, che lo lascia proseguire da solo per più turni fino a una condizione di completamento verificata; e i comandi /loop e /batch, pensati per compiti che si ripetono nel tempo o su larga scala. La documentazione ufficiale descrive il parametro effort come la leva che decide quanti token il modello spende per rispondere: tempo di ragionamento, ma anche quante volte legge un file, quante verifiche esegue, quanto si spinge avanti prima di fermarsi a chiedere conferma.

L’equivoco più diffuso è credere che effort misuri solo quanto il modello pensa. Il blog tecnico di Anthropic lo ha precisato pochi giorni fa: effort governa l’intero comportamento del turno, comprese le chiamate agli strumenti e le verifiche prima di dichiarare finito un compito. Un livello basso corrisponde a un modello addestrato a chiedere contesto invece di scoprirlo da solo, non un modello reso pigro in astratto.

Tom’s Hardware ha già raccontato come questi strumenti abbiano smesso di essere semplici chatbot per diventare ambienti che lavorano sul contesto reale di un progetto, non solo su una conversazione isolata. I cinque comandi nascono dentro quella logica e regolano quanto contesto l’agente esplora prima di muoversi, dal singolo turno fino ai cicli che si ripetono nel tempo o su larga scala.

I livelli disponibili in Claude Code vanno da low a max, passando per medium, high, il livello di default, e xhigh per gli sviluppi più lunghi. Salire di livello lascia invariata la conoscenza del modello: le competenze restano quelle fissate nell’addestramento. Aggiunge invece margine di verifica, la possibilità di rileggere un file, confrontare due approcci, controllare un’ipotesi prima di scartarla.

Per un compito banale, come correggere un refuso o rinominare una variabile, quel margine è sprecato. La differenza di costo tra un livello basso e uno alto sullo stesso prompt può arrivare a un ordine di grandezza, secondo i materiali tecnici di Anthropic. Il criterio corretto per scegliere il livello resta la complessità del compito, non l’importanza che gli attribuisce chi lo assegna.

Claude Code ha anche un livello chiamato ultracode, che nel menu dell’effort appare come opzione a parte ma tecnicamente abbina xhigh a un permesso permanente di avviare flussi multi-agente. È il punto in cui il costo può salire più in fretta: la ricerca di Anthropic sui sistemi multi-agente ha misurato che un singolo agente consuma circa quattro volte i token di una chat semplice, un sistema multi-agente fino a quindici volte tanti. Ultracode serve ai compiti che richiedono davvero quella scala, non all’uso quotidiano.

Il piano mette una pausa prima dell’errore costoso

Il plan mode risolve un problema diverso da quello dell’effort: riguarda il momento in cui il modello comincia ad agire, non quanto ragiona prima di farlo. Attivato con due pressioni di Shift+Tab o con il comando /plan, blocca gli strumenti di scrittura a livello di sistema. Claude legge file ed esegue comandi di sola lettura, propone un piano, ma la documentazione ufficiale conferma che non può modificare codice finché quel piano non viene approvato.

La logica riguarda il tempismo, più che la competenza cognitiva del modello. Un agente che comincia a scrivere codice prima di aver capito il problema produce errori che, una volta dentro ai file, costano di più correggerli di quanto costasse prevederli. Separare la proposta dall’esecuzione sposta la correzione nel punto più economico del processo.

Una volta approvato, il piano può passare a una modifica automatica dei file, a un’esecuzione supervisionata passo per passo, o a una modalità con controlli di sicurezza in background. Quale grado di supervisione attivare dopo l’approvazione resta comunque una scelta di chi guida la sessione, come racconta anche l’analisi tecnica di come funziona Claude Code sotto il cofano.

Chi controlla che il compito sia davvero finito

Il comando /goal, disponibile da metà maggio 2026, permette di assegnare a Claude Code una condizione di completamento e lasciarlo lavorare turno dopo turno finché quella condizione non risulta soddisfatta. La documentazione ufficiale spiega il meccanismo: dopo ogni turno, un modello più piccolo e veloce, di norma Haiku, legge la conversazione e decide se la condizione regge. Se la risposta è negativa, Claude riparte da solo con quella motivazione come guida.

Il dettaglio che pesa di più per chi valuta l’affidabilità del sistema è tecnico. Il modello valutatore giudica solo quello che Claude ha già scritto nella conversazione, senza eseguire comandi né leggere file per conto proprio. La condizione di completamento va scritta come un test, non come un desiderio.

“Il report contiene tre fonti verificate per ogni dato numerico” funziona come condizione, perché il valutatore trova la prova già nel testo che sta leggendo. “Il report è più solido” no, perché lascia al modello la decisione di quando fermarsi, e quella decisione raramente coincide con quella di chi ha commissionato il lavoro. La documentazione consiglia di aggiungere anche un limite esplicito, un numero massimo di turni o un tempo oltre cui il ciclo si deve fermare comunque.

Senza quel limite, e senza un perimetro chiaro di file su cui l’agente può intervenire, un obiettivo scritto male produce un ciclo che continua a lavorare senza che nessuno sappia bene fino a quando. È lo stesso meccanismo che rende fragile un /loop senza condizione di stop, applicato qui a un compito singolo invece che a un ciclo ripetuto.

Loop e batch amplificano lo stesso errore, non lo correggono

Altri due comandi nascono dalla stessa logica di lavoro autonomo, come descrive la documentazione ufficiale di Claude Code. /loop ripete un prompt o un comando a intervalli, dentro la stessa sessione: utile per controllare un rilascio, sorvegliare un test, aspettare che un servizio torni raggiungibile. /batch scompone una modifica ampia in unità indipendenti e le esegue in parallelo, ognuna nel proprio ambiente isolato.

/loop senza condizione di stop consuma token senza produrre progressi, un fenomeno che in alcuni ambienti tecnici viene chiamato token hemorrhage, emorragia di token. Un ciclo che gira senza un criterio di uscita esplicito moltiplica quel consumo per il numero di iterazioni, non per un fattore fisso.

/batch senza limiti di ambito applica un’istruzione debole a un intero insieme di file o elementi. Se l’istruzione dice solo “aggiorna la formattazione delle fatture”, e il set contiene fatture con valute e regole fiscali diverse, il risultato è un errore identico ripetuto cento volte invece di un errore isolato che qualcuno avrebbe notato. La scala amplifica la debolezza dell’istruzione, non la corregge.

Le vecchie regole dei cicli funzionano anche sui prompt

Chi applica questa disciplina ai prompt multi-turno prende in prestito quattro principi dalla programmazione classica. Il primo: calcolare una sola volta il contesto stabile, invece di farlo ririchiedere al modello a ogni passaggio del ciclo. Chi fa fare a un agente l’audit di un centinaio di contratti fornitori scrive le regole di conformità una sola volta all’inizio, non le ripete in ogni iterazione sperando che restino coerenti.

Il secondo principio ordina i controlli dal più economico al più costoso. Un controllo di formato, il documento ha tutti i campi richiesti, costa poco e va eseguito prima di un controllo semantico, il contenuto è coerente con gli altri documenti, che richiede più ragionamento e più token. Invertire l’ordine significa pagare il controllo costoso anche sui casi che il controllo economico avrebbe già scartato.

Il terzo principio chiede di costruire un indice del materiale prima di cercarci dentro ripetutamente: mappare una prima volta un migliaio di ticket di supporto per categoria, priorità e cliente, invece di far rileggere l’intero archivio al modello a ogni nuova domanda. Il quarto principio riguarda le dipendenze: prima di lanciare un ciclo su un insieme di attività, capire quali dipendono da altre.

Un /batch che elabora cento contratti in parallelo senza sapere che venti di loro fanno riferimento a un master agreement comune produce venti versioni scollegate dello stesso vincolo. Il livello più avanzato di questa disciplina usa strumenti di template come Jinja2, già adottati da piattaforme come Semantic Kernel di Microsoft, per strutturare i prompt con variabili, condizioni e cicli.

La differenza tecnica è netta: la logica di visualizzazione sostituisce le variabili nel testo, la logica di applicazione garantisce che una struttura venga rispettata a prescindere da cosa il modello vorrebbe fare. Chiedere in prosa di generare cinque sezioni non impedisce al modello di produrne quattro o sei, se ritiene che il risultato resti comunque valido. Un template che genera un ciclo di cinque iterazioni fisse elimina quella libertà di interpretazione: il vincolo strutturale diventa una proprietà del sistema che lo esegue.

Anche Codex converge sugli stessi tre comandi

OpenAI ha costruito, per Codex, il suo strumento di coding agentico concorrente, equivalenti quasi identici agli stessi tre comandi. Il comando /model permette di scegliere un livello di ragionamento tra minimal, low, medium, high e, sui modelli che lo supportano, xhigh o max. Il comando /plan attiva una modalità di sola proposta identica nello spirito a quella di Claude Code, e resta non disponibile mentre un compito è già in corso.

Anche Codex ha un comando /goal con la stessa idea di fondo: un obiettivo durevole, una condizione verificabile, la possibilità di lavorare per ore senza supervisione turno per turno. La differenza sta nella cautela con cui viene presentato: la documentazione di OpenAI lo classifica ancora come funzione sperimentale, da attivare esplicitamente nelle impostazioni, mentre in Claude Code il comando resta disponibile di default in ogni sessione già autorizzata.

Che due concorrenti diretti arrivino agli stessi tre controlli, con nomi diversi ma logica identica, è un segnale strutturale. Il problema che risolvono, agenti che lavorano su più passaggi senza supervisione continua, dipende da come si comportano i modelli quando nessuno controlla ogni singolo passo, più che dal fornitore che li costruisce.

Chi paga quando il ciclo continua da solo

Un modo pratico di combinare i tre controlli è pensarli come fasi diverse dello stesso lavoro. Nella fase di analisi e decisione architetturale, effort alto o xhigh insieme al plan mode aiutano a confrontare approcci diversi prima di scrivere una riga di codice. Una volta che il piano è approvato, l’esecuzione meccanica, applicare la stessa trasformazione su decine di file, può girare con un modello più piccolo e un effort più basso, perché il lavoro cognitivo pesante è già stato fatto a monte.

La modalità goal si presta meglio alla parte finale di questo schema, quando il compito è già scomposto e resta solo da eseguirlo fino a un traguardo misurabile: ogni test che passa, ogni file che rispetta un formato, ogni voce di changelog che manca. Usarla per aprire un progetto ancora ambiguo, senza una condizione verificabile scritta prima di premere invio, produce lavoro che sembra progredire ma che nessuno può davvero chiudere.

Il rischio concreto per chi struttura questi flussi in azienda riguarda meno l’errore su un singolo compito, più la deriva silenziosa di un ciclo lasciato aperto troppo a lungo. Un obiettivo scritto in fretta lascia girare la modalità goal per ore, con un valutatore che legge solo quello che l’agente stesso ha scritto, su un perimetro di file più ampio del previsto. Team che hanno già sperimentato quanto un’istruzione scritta male venga interpretata in modo imprevedibile riconoscono lo stesso rischio, amplificato dall’autonomia multi-turno.

Quel rischio si somma a un secondo, più visibile nei numeri che circolano tra i direttori finanziari. Le aziende che hanno approvato i budget AI con logica da abbonamento si sono trovate davanti a consumi che seguono la logica del cloud, dove il costo varia con l’intensità d’uso invece che restare fisso per postazione, come racconta un approfondimento di Tom’s Hardware sui tetti di spesa imposti da diverse aziende sull’uso agentico.

Un project manager che lancia un /loop su un centinaio di ticket di assistenza, o un analista che usa /batch per riscrivere un migliaio di schede prodotto, espone l’azienda allo stesso consumo esponenziale di token che sta già spingendo altri reparti a preferire gli agenti ai chatbot, con bollette che crescono di conseguenza. Il rischio non riguarda solo chi scrive codice: chi coordina team di project management, ricerca o analisi e adotta questi comandi senza formazione specifica sta replicando lo stesso errore, con la differenza che nessuno se lo aspetta da un reparto non tecnico.

Chi investe il tempo per scrivere condizioni verificabili, ordinare i controlli per costo e mappare le dipendenze prima di iterare ottiene la stessa automazione con una frazione dei token, senza sorprese in fattura a fine mese. Chi salta questo lavoro lo scopre due volte: nel budget che il direttore finanziario deve giustificare, e nel ciclo che ha continuato a girare su un obiettivo scritto male senza che nessuno se ne accorgesse in tempo.