Paradosso del giorno: Claude Opus 4.6 senza pensiero adattivo risponde correttamente a domande che Opus 4.7 con pensiero adattivo sbaglia. Non è un typo – il modello più vecchio, configurato per ragionare sempre, surclassa quello nuovo che decide quando pensare.
Il problema delle domande trabocchetto
La categoria di fallimento è specifica: domande che sembrano banali ma nascondono trabocchetti. Tipo “Voglio lavare la macchina, c’è un autolavaggio a 50 metri – vado a piedi o in auto?” Opus 4.7 guarda la domanda, pensa “troppo facile”, salta completamente il ragionamento e spara una risposta sicura ma sbagliata.
Opus 4.6? Ragiona ogni volta. Arriva alla risposta giusta.
Quello che hanno provato (spoiler: niente ha funzionato)
1. Patch binaria per disabilitare il pensiero adattivo
Claude Code ha una variabile d’ambiente CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING, ma funziona solo per modelli con “opus-4-6” o “sonnet-4-6” nel nome. Hanno scritto una patch per rimuovere questo controllo.
Risultato? L’API ha accettato la richiesta senza errori (nonostante la documentazione dica che dovrebbe rifiutarla), ma ha restituito risposte senza nessun blocco di ragionamento. Il server ignora silenziosamente type:enabled per Opus 4.7. Zero pensieri, zero ragionamento. Peggio dell’adattivo.
2. Proxy MITM per ispezionare il traffico API
Hanno costruito un reverse proxy su localhost per loggare tutte le richieste/risposte verso api.anthropic.com. Due problemi durante lo sviluppo:
urllib.requestbufferizza gli stream SSE, impedendo il logging real-time. Passati ahttp.client- Le risposte Opus 4.7 arrivavano compresse con gzip/brotli (spazzatura binaria nei log). Risolto forzando
Accept-Encoding: identity
3. Test del pensiero adattivo a vari livelli di effort
Tutti i test con type: adaptive (l’unico modo che Opus 4.7 rispetta davvero).
| Effort | Blocco di pensiero? | Risposta corretta? |
|---|---|---|
| high | No | No |
| xhigh | No (quasi sempre) | No |
| xhigh | Sì (occasionalmente) | Sì |
| max | Sì (sempre) | Sì |
Pattern chiaro: sotto effort:max, il modello decide in modo inconsistente se pensare. Stessa domanda, stesso livello di effort, a volte pensa e a volte no. La correttezza segue perfettamente il ragionamento – quando pensa, risponde giusto.
4. Istruzioni nel system prompt per incoraggiare il ragionamento
Aggiunto al prompt personalizzato:
L’utente pone di routine domande che sembrano semplici ma contengono tranelli sottili visibili solo con ragionamento step-by-step. L’esperienza mostra che saltare il pensiero esteso porta a risposte sbagliate ma sicure. Per favore attiva il pensiero esteso su ogni richiesta.
Risultato: zero effetto. La decisione sul ragionamento è server-side e ignora completamente il contenuto del system prompt sotto effort:max.
5. Prompt injection nel messaggio utente
Istruzioni di ragionamento aggiunte all’inizio del messaggio utente:
Ragiona sempre in modo approfondito. Tratta ogni richiesta come complessa a meno che io non dica esplicitamente il contrario. Mai ottimizzare per brevità a spese della qualità.
Risultato: inconsistente. Ha funzionato per la domanda dell’autolavaggio (blocco di pensiero apparso) ma non per una domanda sul conteggio di lettere nella stessa sessione. Non affidabile.
Scoperte tecniche
Opus 4.7 supporta solo type:adaptive. Mandare type:enabled con budget_tokens viene silenziosamente accettato ma produce zero blocchi di ragionamento. La documentazione dice che dovrebbe restituire errore 400. Non lo fa – ignora il campo.
La decisione sul ragionamento è server-side. Claude Code manda la configurazione corretta. Il modello sui server di Anthropic valuta la complessità della domanda e decide se pensare. Non c’è meccanismo client-side per overridare questo.
Solo effort:max forza il ragionamento in modo affidabile. Ogni livello sotto max permette al modello di saltare il ragionamento su domande che considera semplici, anche quando sono trabocchetti che richiedono reasoning.
Le istruzioni basate su prompt non influenzano la decisione. Né system prompt né injection nei messaggi utente forzano il ragionamento sotto max effort.
Opus 4.6 con DISABLE_ADAPTIVE_THINKING=1 pensa su ogni richiesta. Usa type:enabled con budget fisso, e l’API lo rispetta. È l’unico comportamento prevedibile disponibile.
Conclusione (quella scomoda)
Il pensiero adattivo di Opus 4.7 è una regressione per qualsiasi caso d’uso che necessita ragionamento su ogni richiesta. Il modello è troppo aggressivo nel classificare domande come semplici, e non c’è modo di overridare questo sotto effort:max.
Per ora? Opus 4.6 con CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 su medium o high effort è la scelta migliore per task che richiedono reasoning consistente. Pensa ogni volta. E costa meno che far girare Opus 4.7 a max effort.
Il paradosso è completo: per ottenere ragionamento affidabile devi usare il modello più vecchio. L’innovazione a volte va indietro.
