Reasoning effort, fast mode o ultracode: quale usare e quando

Cos’è l’effort e come decide quanto ragiona il modello?

L’effort è l’impostazione con cui scegli quanto lavoro il modello mette in una risposta; in OpenAI si chiama reasoning effort, in Google thinking level. Nell’articolo su SWE-bench abbiamo mostrato che lo stesso modello prende un altro punteggio quando cambia solo l’effort, e nell’articolo sui subagenti come i subagenti ereditano l’effort. Questo articolo mette l’effort accanto a due impostazioni con cui viene spesso confuso:

Tutti e tre i provider ormai regolano il ragionamento non con un numero di token, ma con un livello che ha un nome. La documentazione di Anthropic dice chiaramente cos’è il livello: non un budget, ma un’indicazione data al modello («a behavioral signal, not a strict token budget»). Non agisce solo sul ragionamento, ma anche sul testo e sulle chiamate agli strumenti; più l’effort scende, meno chiamate agli strumenti fa il modello, e più brevi.

Fonte: documentazione delle API dei tre provider, 20 ottobre 2026. GPT-6.1 Sol non supporta i livelli none e minimal. In Google il livello minimal non garantisce che il ragionamento sia spento, nemmeno sui modelli che lo supportano.

In tutti e tre il limite rigido è quello sui token di output: max_tokens in Anthropic, max_output_tokens in OpenAI e Google. Anthropic lo dice in breve: l’effort è un’indicazione morbida, max_tokens un limite rigido. Se il modello arriva a quel limite mentre ragiona, la risposta viene troncata o torna vuota; OpenAI e Google scrivono chiaramente che il ragionamento speso viene comunque fatturato.

Quest’anno sono cambiate due cose. La prima: il vecchio budget di token se ne va. In Anthropic budget_tokens è deprecato sui modelli 4.6, e i modelli 4.7 e successivi lo rifiutano; in Google thinking_budget è deprecato per Gemini 4 Argon. Su Opus 5.5 e Gemini 4 Argon il ragionamento non si può nemmeno spegnere; l’unica manopola che hai è il livello. La seconda: i valori predefiniti sono scesi. Opus 5.5, Haiku 5.5, GPT-6.1 Sol e Gemini 4 Argon partono da medium; così Opus 5.5 parte un livello sotto Opus 5. Il predefinito di Sonnet 5.5 dipende da dove gira: high nell’API di Claude, medium in Claude Code.

Non confrontare i nomi dei livelli tra modelli diversi. La documentazione di Claude Code scrive che la scala è calibrata per ogni modello separatamente, quindi lo stesso nome non significa la stessa quantità di ragionamento su modelli diversi; i livelli di Sonnet 5.5 sono stati ricalibrati rispetto a Sonnet 5. La documentazione di Codex dice anche che i livelli non corrispondono esattamente tra generazioni di modelli.

Cambiare l’effort a metà conversazione ha un costo. In Anthropic cambiare l’effort dell’intera richiesta invalida la cache del prompt; l’effort per messaggio (beta) cambia il livello conservando la cache, e funziona su Opus 5.5, Sonnet 5.5 e Haiku 5.5. In OpenAI lo stesso lavoro lo fa configuration_update dal 3 settembre. Perché la cache si rompe l’abbiamo spiegato nell’articolo sul prompt caching.

Come si imposta l’effort nei cinque strumenti?

Tutti e cinque gli strumenti ti fanno scegliere il livello con un comando o un’impostazione. Si differenziano per il valore predefinito e per l’esistenza o meno di una modalità superiore che divide il lavoro tra subagenti. La tabella l’abbiamo ricavata il 20 ottobre 2026 dalla documentazione e dalle note di rilascio di ciascuno strumento:

Fonte: documentazione e note di rilascio di ciascuno strumento, 20 ottobre 2026. «Non nella documentazione»: nelle pagine lette quel giorno non abbiamo trovato una frase che lo dica. --effort è arrivato in Copilot CLI con la versione 1.0.10 (20 marzo), max per i modelli Anthropic con la 1.0.60 (5 giugno). /effort è arrivato in Antigravity CLI con la versione 1.1.5 (21 luglio), /boost nell’app Antigravity con la 2.12.0 (2 settembre). HydraFusion Max è stato annunciato il 14 ottobre.

In Claude Code /effort apre uno slider; puoi anche scrivere direttamente il livello, per esempio /effort high. effortLevel nel file delle impostazioni accetta valori da low a xhigh; max lì non è accettato e si può scegliere solo per una sessione. Anche nella definizione di una skill o di un subagente si può scrivere effort; mentre quella skill o quel subagente gira, questo valore prende il posto del livello della sessione.

In Codex il livello lo fissa model_reasoning_effort in ~/.codex/config.toml; quali livelli puoi scegliere dipende dal modello e dal client. Per la modalità Plan puoi dare un valore a parte; se lo lasci vuoto, la modalità Plan usa il suo predefinito. Un esempio:

model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

La pagina dei modelli di Codex distingue i due livelli più alti: Max dà più tempo per ragionare a un singolo compito, Ultra distribuisce le parti separate di un lavoro complesso tra subagenti in parallelo. La stessa pagina scrive che alla maggior parte dei compiti non serve né l’uno né l’altro.

In Copilot CLI --effort (nome lungo --reasoning-effort) accetta cinque livelli, da low a max; max esiste solo sui modelli Anthropic. Dalla versione 1.0.88 il reasoningEffort nella definizione di un agente personalizzato vale quando quell’agente viene selezionato; un livello che passi esplicitamente da riga di comando ha comunque la precedenza. In VS Code il livello si sceglie dal sottomenu «Thinking Effort», che si apre facendo clic sulla freccia accanto al nome del modello nel selettore, e viene ricordato per sessione. La documentazione di GitHub indica anche il prezzo: un livello più alto consuma più token, e quindi più crediti AI; parti dal livello normale e alzalo solo per i compiti difficili.

In Cursor il piano Plus fa girare i modelli di Cursor con impostazioni fisse: effort medium, Fast spento. Per scegliere un livello di effort e Fast serve Premium o superiore. Il Max Mode dei vecchi piani a richieste, invece, non è un livello di effort ma un’opzione a parte che allarga la finestra di contesto del modello.

In Antigravity CLI /effort sceglie il livello e lo salva per le sessioni successive; --effort vale solo per quell’esecuzione. La maggior parte dei modelli offre low, medium e high; xhigh e max esistono solo su alcuni. Se usi ancora Gemini CLI: nel suo elenco dei comandi non ce n’è uno per l’effort, e l’impostazione del ragionamento sta solo nelle definizioni dei modelli nella configurazione. Google ha sostituito Gemini CLI con Antigravity CLI per gli utenti del livello gratuito e di Google One il 18 giugno 2026; con chiavi API a pagamento Gemini CLI resta utilizzabile.

Cos’è ultracode e in cosa si differenzia dall’effort?

Secondo la documentazione di Claude Code, ultracode non è un livello di effort ma un’impostazione di Claude Code. Quando è attivo, Claude pianifica un workflow dinamico (dynamic workflow) per ogni compito di una certa sostanza: scrive uno script JavaScript che divide il lavoro in parti e coordina molti subagenti, e lo esegue in background. Secondo la documentazione dei workflow, una sola richiesta può diventare più workflow uno dopo l’altro: uno per capire il codice, uno per fare la modifica, uno per verificarla.

L’effort, invece, decide quanto ragiona un singolo agente. I due sono indipendenti: ultracode gira al livello in cui si trova la sessione. Questa separazione è nuova. Quando ultracode è stato annunciato insieme ai workflow dinamici il 28 maggio, portava l’effort a xhigh. Dalla versione 2.1.284 (28 settembre) è un interruttore a parte dentro /effort e non tocca il livello. Quello che è stato scritto prima di quella data descrive il vecchio comportamento. Resta un’eccezione: se avvii la sessione con claude --effort ultracode, anche il livello diventa xhigh. I quattro modi di attivare ultracode li abbiamo descritti nell’articolo sui subagenti.

Per il costo non c’è un moltiplicatore. Anthropic non pubblica di quante volte ultracode aumenti i token; la documentazione scrive che ogni richiesta consumerà più token e durerà di più, e che con un abbonamento arriverai prima a un limite di sessione o settimanale. Con ultracode attivo saltano due freni: l’avviso «Large workflow» per i workflow che prevedono più di 25 agenti o 1,5 milioni di token non compare, e il limite di subagenti simultanei della sessione non vale per i subagenti avviati con lo strumento Agent. I limiti propri del workflow restano: per impostazione predefinita 16 alla volta e al massimo 1.000 agenti per esecuzione. Ultracode non si attiva se i workflow sono spenti o se il modello non supporta xhigh.

Gli altri strumenti hanno la loro versione della stessa idea. Nessuna è la stessa cosa dell’effort:

Fonte: documentazione di Claude Code, Codex, HydraFusion e Antigravity, 20 ottobre 2026. In Codex Ultra compare come un livello dello slider dell’effort (da Light a Ultra); tra i valori di reasoning.effort dell’API di OpenAI, invece, non c’è.

Ultrathink, dal nome simile, è un’altra cosa. Se scrivi ultrathink nel prompt, Claude Code aggiunge per quel turno un’istruzione che chiede di ragionare più a fondo, ma il livello di effort inviato all’API non cambia. Quindi ultrathink è una richiesta valida per un solo messaggio, l’effort è l’impostazione della sessione e ultracode è con quanti agenti si fa il lavoro.

Nelle fonti che abbiamo letto non c’è una misurazione che confronti ultracode attivo e spento, e nemmeno per le modalità simili. Quindi prova ultracode su un lavoro grande che si possa dividere, e prima su una piccola fetta. Anche la documentazione dei workflow consiglia di partire da una sola cartella, per vedere la spesa prima di avviare un lavoro grande.

Cosa accelera il fast mode e quanto costa?

L’effort cambia quanto ragiona lo stesso modello; il fast mode, quanto velocemente lo stesso modello scrive la risposta. I provider vendono lo stesso modello a più velocità: più economico per chi può aspettare, più caro per chi ha fretta. I dati della tabella li abbiamo letti il 20 ottobre 2026 nella documentazione dei prezzi e dei livelli di servizio dei provider:

Fonte: documentazione dei prezzi e dei livelli di servizio dei provider, 20 ottobre 2026. Prezzi per MTok, input / output. In OpenAI Priority è stato rinominato Fast mode il 30 luglio. Il Flex di Google è in anteprima. In Anthropic il fast mode non si può usare insieme alla Batch API.

La documentazione di Anthropic distingue cosa accelera il fast mode: aumenta i token di output al secondo, non il tempo prima che arrivi il primo token. Il modello e la sua intelligenza restano gli stessi. La differenza si vede in una risposta lunga o in un diff lungo; nelle domande brevi quasi non te ne accorgi. C’è un altro costo: le richieste a velocità diverse non condividono la cache. La documentazione di Claude Code ne spiega la conseguenza: la prima volta che attivi il fast mode in una conversazione, paghi tutto il contesto accumulato fin lì al prezzo del fast mode senza cache. Per questo il momento più economico per attivarlo è l’inizio della sessione.

Ecco come stanno i cinque strumenti:

• Claude Code: /fast lo attiva e lo disattiva. Su Opus 5.5 la velocità di output aumenta fino a 2,5 volte, a $8 / $40 per MTok. Nei piani in abbonamento non si paga con il limite del piano, ma con i crediti d’uso (usage credits). Nell’API il fast mode di Opus 5.5 è uscito dalla research preview il 15 ottobre; la pagina del fast mode di Claude Code il 20 ottobre 2026 diceva ancora «research preview».
• Codex: /fast nella CLI; in modo permanente service_tier = "fast", che nella richiesta diventa priority. Secondo la documentazione il fast mode consuma il limite dell’abbonamento a 2,5 volte la tariffa standard, e i crediti acquistati a 2 volte. Dall’8 ottobre GPT-6.1 Sol ha anche Ultrafast: 8 volte sul limite, 6 volte sui crediti; solo con Pro $500 e con i piani Enterprise ed Edu idonei.
• GitHub Copilot: non c’è un interruttore di velocità per tutto lo strumento; la versione veloce compare nel selettore dei modelli come un modello a parte. «Claude Opus 4.8 (fast mode)» è in anteprima dal 29 giugno 2026 e costa più di Opus 4.8 standard; in Business ed Enterprise deve attivarlo un amministratore.
• Cursor: Fast è un’opzione a parte nella tabella dei modelli; su modelli come Grok 4.7 si può scegliere al doppio del prezzo. Nel piano Plus è spento.
• Antigravity: la documentazione non dice nulla di un livello di velocità a pagamento.

Il prezzo dei livelli economici è aspettare o essere rifiutati. Il livello flex di OpenAI sotto carico può restituire 429; quelle richieste non vengono addebitate. Il Flex di Google non porta da solo una richiesta al livello standard quando la capacità è piena; il nuovo tentativo lo lascia a te. In un lavoro che qualcuno aspetta davanti allo schermo è una sorpresa; in un lavoro batch che gira di notte è metà prezzo.

Più effort vuol dire un risultato migliore?

Fino a un certo punto. Abbiamo guardato tre tipi di prove: la misurazione del produttore stesso, un indice indipendente e i nostri registri. I risultati dichiarati dal produttore sono segnalati come tali.

Il confronto tra livelli di effort della documentazione di Anthropic sui costi l’abbiamo disegnato nell’articolo su SWE-bench: su un sottoinsieme di SWE-bench Pro scelto da Anthropic stessa, Opus 5.5 risolve sempre più compiti passando da low a xhigh, e il costo per compito si moltiplica. Lo stesso documento contiene un’idea più utile: invece di far girare tutto a un livello alto, far girare prima in low e ripetere in high solo i fallimenti. In low è fallito il 13% dei compiti; ripetendoli in high, è stato risolto circa il 97% dei compiti, a circa $0,17 per compito. Con tutto in high il risultato è stato del 95,3% a $0,29. È un risultato dichiarato dal produttore e ha due condizioni: serve un segnale che indichi il fallimento (lì, i test del benchmark stesso), e ogni compito che fallisce al primo tentativo aspetta due esecuzioni.

Sul fronte indipendente, il Coding Agent Index di Artificial Analysis misura lo stesso modello a ogni livello di effort, dentro uno strumento di programmazione: 303 compiti, 3 tentativi per compito. I risultati del 20 ottobre 2026:

Fonte: Artificial Analysis, la pagina dal vivo il 20 ottobre 2026; una sola istantanea. In ogni cella il punteggio dell’indice e il costo medio per compito. La pagina non dà un intervallo di confidenza; una differenza di pochi punti può essere rumore. Quando un modello rifiuta per motivi di sicurezza, un altro modello può completare il tentativo, e il tentativo conta lo stesso: nelle righe di Sonnet 5.5 è successo in un numero di tentativi tra 18 e 45 su 909. I nomi dei livelli sono calibrati per ogni modello separatamente, quindi leggi la tabella colonna per colonna, non riga per riga.

I tre modelli mostrano tre cose diverse. Sonnet 5.5 sale a ogni livello, ma il costo per compito è di $0,48 in low e di $14,19 in max; anche la durata media di un compito passa da circa 6 minuti a 87 minuti. Su Haiku 5.5 max costa 4,2 volte xhigh e prende un punteggio più basso. GPT-6.1 Sol è quasi piatto tra i livelli: tra il suo punteggio più basso e il più alto ci sono 5,7 punti.

Anche nelle misurazioni del produttore il guadagno si appiattisce ai livelli più alti. Secondo la system card di Opus 5.5 (dichiarato dal produttore), il modello ha ottenuto il 66,4% su Terminal-Bench 4.0 in xhigh e il 64,8% in max; Anthropic considera la differenza dentro il rumore (errore standard ±2,6 punti). Nella stessa card il miglior punteggio di Opus 5.5 su FrontierCode (54,6%) è in medium; sopra medium il punteggio scende, e in max torna in gran parte. FrontierCode penalizza le modifiche che il compito non chiedeva; di come il modello esce dal perimetro con un effort alto abbiamo parlato nell’articolo su SWE-bench.

Nei nostri registri abbiamo visto un’altra cosa. diffox è uno strumento di code review con IA; abbiamo fatto girare più volte il modello Claude che usiamo sulle pull request di un set di benchmark pubblico, cambiando solo l’effort. Ogni esecuzione è fatta delle stesse 100 chiamate al modello. Poiché i token di ragionamento si pagano dentro i token di output, abbiamo contato se una chiamata aveva ragionato guardando se la sua risposta conteneva un blocco thinking:

In medium nessuna chiamata ha ragionato; il modello ha scritto direttamente la risposta. In high ha ragionato la maggior parte delle chiamate, in xhigh tutte, e output e tempo per chiamata sono cresciuti di conseguenza. Con l’adaptive thinking, quindi, l’effort cambia più il fatto che il modello ragioni o no che quanto a lungo ragiona. La documentazione di Anthropic dice la stessa cosa: in modalità adattiva l’effort decide quanto spesso e quanto a fondo ragiona il modello, e ai livelli bassi può saltare del tutto il ragionamento sui problemi semplici. Un secondo set di benchmark ha dato lo stesso quadro: in medium non ha ragionato nessuna delle 200 chiamate, in high 88 su 200. Max l’abbiamo provato solo su due chiamate: hanno ragionato entrambe, con 61.470 e 83.150 token e 423 e 745 secondi per chiamata.

Che alzare l’effort faccia individuare più bug, dai nostri registri non risulta. Per dirlo servono esecuzioni ripetute per ogni impostazione; noi abbiamo una o due esecuzioni per impostazione, e la differenza non supera l’oscillazione normale tra due esecuzioni. Perché non contiamo l’esito di una sola esecuzione come un risultato l’abbiamo spiegato nell’articolo su LLM-as-a-judge.

Quale impostazione scegliere per quale lavoro?

Le fonti concordano: parti dal valore predefinito del modello e alzalo solo misurando sul tuo lavoro. OpenAI consiglia di vedere l’effort come una manopola di regolazione fine, non come la via principale per recuperare qualità. Google propone di provare tutti e tre i livelli nella tua valutazione e di scegliere il più basso che soddisfa il tuo requisito. Un riepilogo per i lavori più comuni:

Le ragioni dietro le schede sono nella documentazione. La documentazione di Claude Code avverte che max può dare rendimenti decrescenti e ragionare troppo, e chiede di provarlo prima di adottarlo in modo esteso; quella di Codex scrive anche che alla maggior parte dei compiti non servono né Max né Ultra. OpenAI mette la sicurezza e la code review tra gli usi comuni di xhigh, ma solo quando la tua valutazione mostra un beneficio chiaro. Le modalità ultra servono quando puoi dividere il lavoro in parti sensate; su un unico problema difficile che non si può dividere, ha più senso che un solo agente ragioni più a lungo. Per i bot delle pull request e i job di CI scegli il livello standard: flex sotto carico può rifiutare, batch può richiedere ore.

Aiutano altre tre abitudini:

• Aggiungi un’istruzione sul perimetro. Se l’output sarà un diff da portare al merge, aggiungi al prompt una frase breve che chieda al modello di restare nel perimetro del compito. Secondo Anthropic, sopra high Opus 5 ha fatto più modifiche di quelle richieste dal compito, e con questa istruzione il punteggio è tornato nella maggior parte di quei compiti.
• Cambia l’effort per messaggio. In una sessione lunga, cambiare il livello dell’intera richiesta invalida la cache. L’effort per messaggio di Anthropic e il configuration_update di OpenAI cambiano il livello conservando la cache.
• Prima il livello economico, poi quello caro. Se puoi controllare l’output con un test o un verificatore, far girare prima a un livello basso e ripetere solo i fallimenti a un livello alto è risultato più economico nella misurazione di Anthropic che far girare tutto in high.