Claude Code Adaptive Thinking: Calo di Prestazioni e Workaround su Opus 4.7

Il contesto

Con gli ultimi aggiornamenti dei modelli Claude (Opus 4.6, Sonnet 4.6, Opus 4.7), Claude Code ha attivato di default un meccanismo chiamato adaptive thinking (ragionamento adattivo).

Il modello non spende più un budget fisso di token di pensiero a ogni turno, ma lo dosa autonomamente in base alla stima interna di complessità della richiesta: poco su domande che giudica semplici, molto su domande che giudica complesse.

In teoria è un miglioramento: meno token spesi e meno latenza sulle richieste banali, più thinking a disposizione sulle richieste davvero complesse.

In pratica, quando il modello sottostima la difficoltà di una richiesta, può tagliare corto dove non dovrebbe.

Alcuni utilizzi sembrano suggerire che questo produca, in certi casi, un calo di prestazioni percepito: risposte più rapide ma a volte meno accurate, soluzioni accettate al primo pensiero senza verifica, occasionali errori su richieste che in precedenza venivano gestite bene.

Non è un comportamento documentato ufficialmente come regressione, ma una tendenza che può emergere in alcuni workflow.

L'effetto, quando si presenta, è più difficile da mitigare su Opus 4.7, dove adaptive thinking è sempre attivo e non può essere disabilitato per via ufficiale.

Il ruolo di effortLevel

Prima dell'introduzione di adaptive thinking, il setting effortLevel (low, medium, high, xhigh) si comportava come un budget fisso di thinking, speso per intero a ogni turno.

Con adaptive thinking attivo, il significato cambia: effortLevel diventa un tetto massimo consentito, non una quota da spendere sempre.

Tradotto in pratica: impostare effortLevel: "xhigh" non garantisce che il modello pensi sempre al massimo. Garantisce solo che possa arrivarci, se lui decide che la richiesta lo merita.

Su un modello adaptive-only come Opus 4.7, il modello può fermarsi molto sotto quel tetto su qualunque richiesta, e l'utente non ha un modo diretto per forzarlo.

La via ufficiale di disabilitazione

La documentazione di Anthropic espone una variabile d'ambiente che permette di tornare al comportamento a budget fisso:

CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

Si può impostare a livello di shell oppure in modo persistente in ~/.claude/settings.json sotto la chiave env:

{
  "env": {
    "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
  }
}

Quando è attiva, adaptive thinking è spento e il modello torna al budget fisso controllato da MAX_THINKING_TOKENS e effortLevel, con comportamento più lento ma più stabile e prevedibile.

Funziona su Opus 4.6, Sonnet 4.6, Haiku. Non funziona su Opus 4.7.

Opus 4.7: adaptive thinking permanente

La documentazione lo dichiara esplicitamente:

"Opus 4.7 always uses adaptive reasoning. The fixed thinking budget mode and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING do not apply to it." (docs.claude.com/en/model-config)

E ripete:

"Note: This has no effect on Opus 4.7, which always uses adaptive reasoning." (docs.claude.com/en/env-vars)

Su Opus 4.7 la variabile è quindi inerte.

Il modello resta sempre in modalità adattiva, per design, e non è disponibile alcun interruttore lato configurazione.

Anche con effortLevel: "xhigh" già impostato, l'effort continua a essere solo un tetto che il modello può non raggiungere mai.

Una possibile soluzione: forzatura via prompt persistente

Dal momento che su Opus 4.7 la leva tecnica non esiste, questo articolo propone una possibile soluzione basata sull'unica leva operativa rimasta, cioè una leva comportamentale: istruire il modello, via prompt persistente, a usare sempre il tetto massimo dell'effort, indipendentemente dalla stima interna di complessità della richiesta.

La soluzione è attualmente in fase di test.

Dopo un primo utilizzo sembra mitigare un po' il problema percepito, ma non esiste ancora una validazione quantitativa della sua efficacia: l'unico riscontro disponibile è qualitativo, basato sull'output osservato in uso reale.

Va quindi considerata un workaround sperimentale, non una fix garantita, e il suo comportamento su workflow diversi può variare.

L'obiettivo di questo articolo è documentare l'approccio in modo che possa essere provato, raffinato e confrontato con alternative.

Il posto corretto per un'istruzione persistente globale è ~/.claude/CLAUDE.md (memoria utente, letta in ogni sessione di Claude Code, su qualsiasi progetto).

Blocco da aggiungere a ~/.claude/CLAUDE.md

## Gestione del thinking

Il mio `effortLevel` è impostato a `xhigh`. Con adaptive thinking (obbligatorio su Opus 4.7) questo valore definisce solo il **limite superiore** del budget di thinking che puoi usare per turno: resti libero di spenderne meno, in base alla tua stima interna di complessità della richiesta. Queste istruzioni servono a forzarti a **operare sistematicamente sul limite superiore consentito**, invece di scalare il thinking sulla complessità apparente della domanda.

**Regola principale.** Usa sempre il massimo budget di thinking disponibile, su ogni richiesta, incluse quelle che sembrano banali. La complessità apparente di una domanda è un predittore poco affidabile della difficoltà reale: richieste espresse in forma semplice possono nascondere ambiguità o vincoli impliciti che solo un'analisi più approfondita rileva.

**La latenza non è un obiettivo.** Non ottimizzare per la velocità di risposta. In questo contesto il costo di un errore di comprensione o di un'imprecisione è mediamente più alto del costo di qualche secondo aggiuntivo di elaborazione. L'obiettivo è la precisione dell'output, non il tempo di risposta.

**Non tagliare corto su richieste "semplici".** Anche per lookup, rename, fix di una riga, esecuzione di un comando: prima di agire, verifica che la richiesta sia davvero ciò che sembra e che la soluzione ovvia sia effettivamente la migliore, non solo la prima a cui hai pensato.

**Non confondere "semplice" con "già capito".** Una richiesta con parole semplici può nascondere un'intenzione non ovvia, un vincolo implicito, un contesto che non ho esplicitato. Pensa sull'intenzione, non sulla forma.

**Prima di rispondere, chiediti sempre: "quale errore potrei fare qui?"** Se trovi una risposta non vuota a questa domanda, pensa ancora. Applica questo check anche alle risposte apparentemente ovvie.

**Ragiona esplicitamente sui tradeoff nascosti.** Anche quando una soluzione sembra ovvia: esiste davvero un solo modo? Il modo ovvio è il migliore o solo il più veloce da trovare? C'è una scelta architetturale implicita che sto facendo senza dichiararla?

**Thinking silenzioso di default.** Il pensiero è un investimento interno per rispondere meglio, non un output da mostrarmi. Non riversare il ragionamento nel testo visibile a meno che io non lo chieda o che una singola frase di contesto aiuti davvero.

**Uniche eccezioni in cui puoi abbreviare il thinking:**
- Output esplicitamente richiesto breve ("rispondi sì o no", "una riga").
- Comando di shell completamente meccanico, senza ambiguità possibili e senza rischi (es. `git status`, `ls`).

In tutti gli altri casi: **massimo sempre**.

**Override manuale.** L'utente può cambiare la modalità di thinking per singoli turni con queste formule:

- **"pensiero adattivo" / "modalità adattiva"**: per quel turno abbandoni il "massimo sempre" e torni al tuo adaptive thinking nativo, decidi tu quanto pensare in base alla richiesta.
- **"pensiero rapido" / "modalità veloce" / "rispondi rapido"**: per quel turno usi il minimo di thinking possibile, risposta breve e diretta, niente verifiche estese.

L'override vale solo per il turno in cui è dichiarato. Al turno successivo il comportamento torna al default (massimo sempre).

Usare gli override in pratica

Una volta caricato il blocco in CLAUDE.md, gli override si invocano inserendo la formula nel messaggio, in qualsiasi posizione.

Il modello li riconosce perché CLAUDE.md viene ricaricato a ogni turno.

Esempi per attivare la modalità adattiva

analizza questo file. usa pensiero adattivo

pensiero adattivo: analizza questo file

[modalità adattiva] analizza questo file

Esempi per la modalità veloce

come si chiama questa funzione? rispondi rapido

pensiero rapido: come si chiama questa funzione?

[modalità veloce] come si chiama questa funzione?

Note operative

Il trigger vale solo per il turno in cui è dichiarato. Al messaggio successivo si torna al default "massimo sempre".

Per mantenere la modalità attiva su più turni occorre ripeterla o dichiararla esplicitamente con una formula del tipo "mantieni modalità adattiva finché non ti dico altrimenti".

I trigger riconosciuti sono quelli definiti nel blocco in CLAUDE.md. Per aggiungerne altri (es. @fast, @think) basta estendere quella sezione.

Ricetta finale: setup completo

Per massimizzare il thinking su tutti i modelli, compreso Opus 4.7:

1. ~/.claude/settings.json: impostare "effortLevel": "xhigh" (alza il tetto al massimo).

2. ~/.claude/settings.json → chiave env: aggiungere "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1".

   Su Opus 4.6 e inferiori disabilita adaptive thinking e forza il budget fisso.

   Su Opus 4.7 è inerte ma innocua, quindi conviene lasciarla per coerenza tra modelli.

3. ~/.claude/CLAUDE.md: incollare il blocco "Gestione del thinking" mostrato sopra.

   È il pezzo chiave sui modelli adaptive-only come Opus 4.7: quando la variabile non funziona, il prompt persistente è l'unica leva rimasta.

4. Riavviare le sessioni di Claude Code. Le impostazioni si leggono all'avvio.

Risultato atteso

• Opus 4.6 e inferiori: thinking fisso al massimo, comportamento stabile e prevedibile (garantito dalla variabile).

• Opus 4.7: il modello resta in adaptive thinking; il prompt dovrebbe spingerlo a usare più spesso il tetto massimo consentito dall'effort, ma si tratta di un nudge comportamentale, non di una garanzia deterministica.

Limiti

Il prompt in CLAUDE.md è un nudge comportamentale, non un controllo tecnico del budget di thinking. Di conseguenza il workaround ha alcuni limiti espliciti da tenere presenti.

Nessun controllo deterministico.

Su Opus 4.7 il modello resta libero, in linea di principio, di pensare meno se è convinto che la richiesta sia banale. Il prompt influenza la decisione interna di adaptive thinking ma non la vincola.

Misurabilità cieca.

Non esiste uno strumento utente per misurare la quantità effettiva di token di thinking spesi in un turno. L'efficacia del workaround è valutabile solo a posteriori sull'output finale, in modo qualitativo.

Validazione aneddotica.

Dopo un primo utilizzo il workaround sembra mitigare un po' il problema percepito, ma non c'è validazione quantitativa. L'effetto dipende dal tipo di workflow e dalla sensibilità individuale all'accuratezza delle risposte.

Effetti collaterali accettati.

Spingendo il modello verso il tetto massimo si accettano consumi di token di thinking e latenze mediamente più alti, anche su richieste che avrebbero potuto essere gestite più rapidamente. L'override esplicito "pensiero rapido" resta disponibile per recuperare velocità quando serve.

Fragilità rispetto ai futuri aggiornamenti.

Il comportamento di adaptive thinking e la priorità che il modello assegna alle istruzioni persistenti possono cambiare con le versioni future. Il workaround va considerato valido solo per lo stato attuale e andrà rivalutato dopo ogni aggiornamento significativo del modello.

Ridondanza sui modelli pre-4.7.

Su Opus 4.6 e inferiori il prompt è in larga parte ridondante: la variabile CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 è sufficiente a ottenere un comportamento deterministico.

In quel caso il prompt introduce un overhead minimo ma non nullo di token in context window. Se il workflow è concentrato su modelli pre-4.7, conviene privilegiare la via ufficiale.

Quando il workaround può essere ignorato.

Chi non percepisce un calo di prestazioni con adaptive thinking attivo può non applicare nulla di quanto descritto: la modalità default è già ottimizzata per costo e latenza nel caso generale, e il workaround ha senso solo se il problema è effettivamente osservato.

Fonti

• Model configuration
• Environment variables
• Memory (CLAUDE.md)