Opus 4.7 con Claude Code: test reali su xhigh, adaptive thinking e tool use conservativo

Boris Cherny ha pubblicato ieri, 16 aprile, le best practice ufficiali per Opus 4.7 con Claude Code. Io ho passato le ultime 24 ore a testarle su task reali — workflow n8n che devo debuggare, pipeline Python che orchestrano API, refactor di agenti che girano in produzione.

Non è una review. È un log di osservazioni con un'ipotesi di lavoro forte: il cambiamento più importante di Opus 4.7 non è la performance grezza. È il default xhigh e il modo in cui l'adaptive thinking sta riscrivendo il rapporto costo-qualità sui task agentici.

Se ci riesco, questo si traduce in risparmio token misurabile. Sto facendo i test su Colab proprio per verificarlo. Nel frattempo, ecco cosa vedo.

Il contesto: cosa dice Boris in 5 minuti di lettura

L'articolo di Anthropic è breve e denso. I punti operativi sono cinque.

1. La prima turn deve essere una spec completa. Intent, vincoli, criteri di accettazione, path dei file. Ogni turno aggiuntivo aggiunge overhead di ragionamento, quindi meno turni equivale a output migliore.
2. Il nuovo default raccomandato è xhigh. È un livello inserito tra high e max. Boris dice esplicitamente che è il migliore per la maggior parte del coding. max ha rendimenti decrescenti e rischio overthinking. medium/low rimane comunque superiore a 4.6 allo stesso livello.
3. Adaptive Thinking sostituisce Extended Thinking. Niente più budget fisso di token per il ragionamento. Il modello decide autonomamente quando pensare più a lungo. Se vuoi modularlo, lo fai a livello di prompt.
4. Tool use e subagent spawning più conservativi. Il modello chiama tool meno frequentemente di 4.6. Se vuoi più tool use o fan-out parallelo, devi esplicitarlo.
5. Verbosità calibrata alla complessità. Meno chiacchiere su query semplici, risposte più dense quando serve.

Il messaggio sottotraccia: tratta 4.7 come un ingegnere senior a cui deleghi, non come un pair programmer da guidare riga per riga. È un cambio di paradigma che premia chi sa scrivere spec, non chi sa iterare veloce.

xhigh è davvero l'equilibrio giusto

Su 4.6, il mio workflow standard era: high per l'80% dei task, max quando il problema era davvero complesso. Su max però mi capitava spesso che il modello entrasse in loop di over-reasoning: generava ipotesi, le scartava, ne generava altre, produceva piani che cambiavano tre volte prima di scrivere una riga di codice.

Con xhigh su 4.7 la sensazione è diversa. Il modello è più stabile. Arriva a una decisione e la esegue. Quando il problema lo richiede, approfondisce — ma senza il giro della fiera diagnostico che a volte vedevo su max 4.6.

Un esempio concreto dalle ultime 24 ore: workflow n8n con una lambda che orchestrava tre API esterne e doveva gestire un retry pattern con backoff esponenziale. Bug sottile: in un edge case specifico (quando l'API1 rispondeva 200 ma con payload vuoto), il retry non veniva triggerato e il workflow passava dati nulli downstream. Il tipo di bug che richiede di tenere in testa la semantica del flusso, non solo la sintassi.

• Su 4.6 max, con un prompt equivalente, il modello tipicamente leggeva il file, produceva 2–3 ipotesi, chiedeva conferma prima di procedere, e a conferma ricevuta iniziava a modificare.
• Su 4.7 xhigh, stesso task: letto il file, individuato il problema direttamente nel controllo if che filtrava gli status code senza considerare il payload, proposta fix più test case per l'edge case, fatto.

Quattro step contro circa sette. Meno overhead conversazionale, meno token generati, risultato equivalente. Questa è la parte che sto cercando di quantificare su Colab.

Status epistemico: osservazione su N=1. Non ho ancora un benchmark strutturato che isoli solo la variabile effort. Serve.

Adaptive Thinking: la differenza pratica con Extended Thinking

Su 4.6, Extended Thinking era uno strumento potente ma ruvido. Imposti un budget — diciamo 10k token di thinking — e il modello li usa. Punto. Se il task richiedeva meno, li sprecava. Se ne richiedeva di più, si bloccava.

Adaptive Thinking cambia la dinamica. Il modello decide step per step quando allocare ragionamento. Su task semplici non spende nulla. Su task complessi, approfondisce dove serve.

La differenza è visibile nel comportamento. Ho testato uno script Python che deve parsare JSON eterogeneo da webhook diversi (Stripe, Resend, un endpoint custom n8n). Ogni webhook ha schema differente. Il task: scrivere un normalizer che produce un formato unificato.

Su 4.7 con Adaptive Thinking, il modello ha investito ragionamento solo sul design dello schema unificato — il pezzo non banale. Sulla parte boilerplate (parsing dei singoli webhook) è andato diretto. Su 4.6 con Extended Thinking, il budget veniva distribuito uniformemente: anche sulle parti ovvie, con un piccolo costo di latenza aggiuntivo.

Qui c'è un'ipotesi forte che sto testando: Adaptive Thinking + xhigh + tool use conservativo potrebbero generare risparmio token significativo su task agentici complessi, specialmente quelli con struttura 80% boilerplate, 20% decisioni non banali.

Cosa cambia per chi lavora con n8n, Python, workflow agentici

Tre implicazioni pratiche che sto iniziando a integrare nei miei flussi.

Prima: per la scrittura di nodi Code n8n e script Python di orchestrazione, xhigh diventa il default. max lo uso solo quando il problema è davvero cross-file e richiede progettazione architetturale.

Seconda: gli @mention di file diventano più importanti di prima. Con 4.7 che è conservativo sul tool use, puntare esplicitamente i file nel prompt è il modo per assicurarsi che il modello li legga. Scrivere "il nodo HTTP Request nel flow X" funziona meno bene di @workflows/flow-x.json nodo HTTP Request.

Terza: i subagent vanno pensati come scelta esplicita, non come comportamento default. Se ho un task tipo "valida 20 workflow contro uno schema comune", devo dire al modello: spawna un subagent per ogni workflow, eseguili in parallelo, raccogli i risultati. Se non lo dico, 4.7 farà probabilmente un loop sequenziale.

Tutte e tre queste pratiche richiedono di scrivere prompt più strutturati. Il che è allineato con il principio operativo che seguo da mesi: spec prima, codice poi. 4.7 semplicemente alza il costo di non averlo.

Cosa non so ancora

Ci sono tre cose che non ho ancora verificato e che mi tengono in status epistemico cauto.

Primo: il risparmio token su task agentici complessi è un'ipotesi, non un fatto. Le mie osservazioni sono qualitative e su N=1. I test Colab strutturati mi diranno se il pattern regge. Se non regge, aggiorno questo articolo.

Secondo: non so se xhigh ha un costo diverso da high o max. Anthropic non ha pubblicato la pricing differenziata per effort level (o me la sono persa). Se xhigh costa come max, parte del risparmio token potrebbe essere annullato da un costo per token più alto.

Terzo: il comportamento conservativo sui tool call potrebbe peggiorare su task molto lunghi, dove il modello deve mantenere coerenza su file che non ha letto esplicitamente. Non ho ancora testato sessioni da 2+ ore con 4.7.

Questi sono tre buchi. Se hai dati su uno qualsiasi di questi tre punti, scrivimi.

Il punto che conta

Non è che 4.7 sia migliore di 4.6 in astratto. È che richiede un workflow diverso. Chi continua a trattarlo come 4.6 con più potenza perde la parte di valore più interessante: la capacità di delegare in modo strutturato.

La metafora di Boris — ingegnere capace a cui delegare — non è marketing. È una descrizione operativa del rapporto che il modello vuole avere con chi lo usa. Scrivi la spec bene, dagli lo spazio per decidere, controlla il risultato.

Per chi lavora come me — automazione per PMI e freelancer, dove ogni ora spesa a pilotare Claude è un'ora che non faccio altro — questo è un cambio netto. 4.7 costa meno in attenzione umana. Se i miei test confermano anche il risparmio token, costa meno in dollari.

Approfondimenti

Se vuoi approfondire come uso Claude Code in produzione per automazione e SEO:

• Claude Code: Guida Completa 2026 — il pillar con tutti i pattern operativi, effort levels, MCP integration e workflow spec-first.
• Claude Code per la SEO: caso studio reale — come ho usato questi stessi principi per automatizzare l'ottimizzazione di un intero sito con task schedulati.

Se hai testato Opus 4.7 su task agentici e vuoi confrontare numeri, scrivimi. Mi interessa capire se quello che vedo si ripete o è un caso isolato.