Claude Code sembra peggiorare? Modello e livello di impegno a confronto

Introduzione

Quando Claude Code produce risultati scadenti, molti sviluppatori passano immediatamente a un modello più grande e costoso.

Questa reazione è comprensibile, ma spesso prende di mira l'impostazione sbagliata.

Claude Code offre due controlli per migliorare l'output: modello e livello di impegno. Entrambi sono correlati, ma con ruoli diversi. La scelta del modello modifica le capacità di base del sistema, mentre il livello di impegno regola quanto lavoro Claude è disposto a dedicare al compito corrente.

Questa differenza spiega perché Claude possa improvvisamente sembrare meno accurato, anche senza cambiamenti nel modello. Spiega anche perché un modello più piccolo con un alto livello di impegno possa talvolta superare un modello più grande con un basso livello di impegno.

Perché Claude Code sembra improvvisamente "meno intelligente"

Questa confusione diventa particolarmente evidente quando gli sviluppatori notano cambiamenti nel comportamento di Claude Code.

Gli utenti segnalano che Claude salta file che dovrebbe leggere, evita di eseguire test, si ferma a metà di lavori in più fasi, o chiede maggiori informazioni all'utente invece di esplorare autonomamente.

Una segnalazione su GitHub ampiamente discussa descrive Claude Code come "inaffidabile per attività di ingegneria complesse". L'analisi citata nell'articolo originale ha esaminato migliaia di sessioni e ha riportato un drastico calo nel ragionamento o nel volume di lavoro eseguito.

Molti utenti inizialmente pensavano che il problema fosse nei loro prompt, nelle istruzioni del repository o nella configurazione locale. La fonte originale indica che la causa più diretta era un cambiamento nell'impostazione predefinita del livello di impegno.

Per ridurre la latenza, Anthropic ha temporaneamente abbassato il livello di impegno predefinito per alcuni utenti di Claude Code da alto a medio. I pesi del modello non sono stati indeboliti, ma Claude è stato incoraggiato a dedicare meno tempo, meno token e meno chiamate a strumenti per ogni attività.

L'effetto visibile è stato facilmente frainteso:

• Meno file esaminati.
• Meno test eseguiti.
• Attività in più fasi concluse prematuramente.
• Claude ha chiesto più frequentemente contesto all'utente.
• Risposte più veloci, ma con meno indagini.

Anthropic ha successivamente ripristinato le impostazioni predefinite più alte per gli utenti interessati. Ma a quel punto, l'evento aveva già dimostrato un punto importante: anche quando il modello non cambia, quando la strategia di impegno viene modificata, il modello sembra "diventare più stupido".

Il modello cambia il cervello, l'impegno cambia il carico di lavoro

La spiegazione di Anthropic può essere riassunta in una frase utile:

Il modello cambia il cervello. Il livello di impegno determina quanto a fondo questo cervello lavora sul compito corrente.

La scelta del modello determina il limite delle capacità

Un modello è definito da un insieme fisso di pesi di addestramento.

Una volta completato l'addestramento, questi pesi determinano la conoscenza generale del modello, i pattern appresi, le capacità di ragionamento, l'esperienza di programmazione e la gamma di competenze. I prompt, i file del repository, CLAUDE.md e la documentazione nel contesto possono guidare il modello, ma non possono riscrivere questi pesi.

Ciò significa che la scelta del modello risponde principalmente a questa domanda:

Questo modello può risolvere questo tipo di problema?

Se una libreria è stata rilasciata dopo la data di cutoff dei dati di addestramento del modello, puoi fornire la documentazione nel contesto della sessione corrente per farla utilizzare al modello. Ma questo non insegna permanentemente la libreria al modello. La conoscenza pertinente esiste solo all'interno del contesto corrente.

La stessa limitazione spiega perché un modello possa inventare con sicurezza un'API inesistente. Sta generando il contenuto più probabile successivo basandosi sui pattern appresi, non interrogando un database interno che garantisca la validità della funzione.

Come il testo arriva al modello

Prima che Claude elabori codice o testo, l'input viene suddiviso in token.

Ad esempio, questa riga di codice:

const x = await fetch(...)

Verrà convertita in ID di token dal vocabolario del modello. Il modello elabora usando queste rappresentazioni numeriche, non leggendo i caratteri come farebbe un umano.

Il modello poi predice un token alla volta. Dopo aver generato ogni token, la sequenza viene rielaborata per predire il successivo.

Questo processo di generazione ripetuta è una delle principali fonti di latenza e costo. I modelli più potenti possono produrre previsioni migliori, ma questo non significa che il modello controlli automaticamente ogni file, esegua ogni test o completi ogni fase di ogni lunga attività in modo continuativo.

Ed è proprio qui che entra in gioco l'impegno.

L'impegno controlla non solo il tempo di riflessione

Molti utenti interpretano un livello di impegno più alto come "far riflettere il modello qualche secondo in più".

Questa comprensione è incompleta.

Il parametro di impegno di Anthropic influenza la volontà complessiva del modello di spendere token ed eseguire lavoro. Può influenzare:

• Quanti file Claude leggerà
• Quanti strumenti chiamerà
• Se eseguire test
• Quanta verifica fare
• Se ricontrollare le modifiche
• Quanto approfondire in attività multi-step
• Quanto velocemente chiedere ulteriori informazioni all'utente
• Quanto ragionamento esteso fare

Con un impegno basso, Claude è ottimizzato per velocità ed efficienza dei token. Potrebbe leggere solo i file più ovvi, fare una modifica ristretta e restituire rapidamente.

Con un impegno alto, Claude è più propenso a controllare il codice circostante, leggere configurazioni, eseguire test, verificare i risultati e perseverare fino al completamento dell'attività.

! [Immagine che mostra esempi di impegno basso e alto per l'attività "Ripara test falliti" dalla guida ufficiale Anthropic. Con impegno basso, il modello legge il file di test, modifica e restituisce, impiegando circa 400 token; con impegno alto, legge file di test, file sorgente, file di configurazione, riflette, modifica il codice sorgente, esegue test e verifica, impiegando circa 2.800 token. Questo diagramma mostra visivamente la differenza nei passaggi di elaborazione dell'attività con diversi livelli di impegno, in linea con la spiegazione contestuale dell'effetto del parametro impegno sul comportamento del modello.] (https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/dd8832d9-977a-4e4a-a95a-e1af822e41de-eef46d14-0461-4d5d-a6bb-ae4c3551db57.png)

Il grafico nella guida Anthropic utilizza un esempio illustrativo:

• Il percorso a basso impegno potrebbe utilizzare circa 400 token.
• Il percorso ad alto impegno potrebbe utilizzare circa 2.800 token.

Il multiplo specifico non è una regola fissa. L'impegno è un segnale comportamentale, non un budget rigido di token. Attività diverse possono produrre modelli di consumo diversi.

Il punto chiave è che i token extra non sono usati solo per ragionamento nascosto. Possono anche essere usati per leggere file, generare parametri di strumenti, eseguire passaggi di verifica e scrivere risposte più complete.

Un modello piccolo con alto impegno può superare un modello grande con basso impegno

Questo porta a un risultato apparentemente controintuitivo:

Un modello piccolo con contesto sufficiente e alto impegno può superare un modello grande che può solo elaborare superficialmente.

Immagina due sviluppatori:

• Uno è un generalista potente, con tutto il pomeriggio per esaminare il repository, eseguire applicazioni, testare modifiche e verificare risultati.
• L'altro è un esperto più navigato, ma ha solo cinque minuti, abbastanza per controllare alcuni file.

L'esperto potrebbe avere intuizioni migliori, ma il generalista ha più possibilità di raccogliere prove.

Questo è simile alla differenza tra capacità del modello e impegno.

Un modello grande stabilisce un limite massimo di qualità più alto. Un impegno maggiore determina quanto lontano il modello è disposto a spingersi verso quel limite massimo nell'attività corrente.

! [Immagine è un grafico a linee che mostra come la selezione del modello e l'impegno determinano quanto lontano Claude è disposto ad andare. L'asse orizzontale è il numero di token spesi per attività (= costo e tempo d'attesa), l'asse verticale è la qualità del risultato. Il grafico ha due curve, rossa per il modello più grande, blu per il modello più piccolo. Le due curve si intersecano in diversi punti di spesa token, indicando che in alcune attività, un modello più piccolo può raggiungere la stessa qualità di un modello più grande spendendo meno token. Il grafico è strettamente correlato al contesto, mostrando visivamente l'impatto della dimensione del modello e del livello di impegno sulla qualità del risultato.] (https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/fa902cd7-272e-4a06-9c21-d2001f5b55aa-c275fb8a-03c9-40ec-884d-396ac0be4ef7.png)

Questo non significa che la dimensione del modello non sia importante. Alcune attività sono ancora oltre la capacità di un modello piccolo, indipendentemente dall'impegno. Un modello non può compensare capacità mancanti spendendo più token.

Significa invece che aumentare il modello non è sempre la prima scelta o la soluzione più economica.

Claude fallisce perché non riesce a risolvere l'attività o perché non si impegna abbastanza?

Il consiglio più utile di Anthropic è un quadro diagnostico.

Quando Claude produce risultati scadenti, non cambiare immediatamente modello. Prima determina il tipo di fallimento.

!

Passo 1: Controlla input e contesto

Prima di modificare qualsiasi impostazione, verifica l'attività stessa.

Chiedi:

1. Il prompt è chiaro?
2. Claude ha i file necessari?
3. Gli strumenti corretti sono disponibili?
4. CLAUDE.md è accurato?
5. L'ambito dell'attività è chiaramente suddiviso?
6. Vincoli importanti sono stati omessi?
7. Claude lavora nella directory o nel repository corretto?

Molti problemi che sembrano essere del modello sono in realtà problemi di contesto.

Se il modello riceve requisiti incompleti, istruzioni obsolete o file sbagliati, né un impegno maggiore né un modello più grande risolveranno il problema in modo affidabile.

Passo 2: Cerca segni di impegno insufficiente

Quando Claude mostra quanto segue, il problema è probabilmente impegno insufficiente:

• Salta file correlati
• Non controlla la configurazione
• Evita di eseguire test disponibili
• Si ferma durante un refactoring
• Fa una modifica ma non la verifica
• Chiede informazioni che potrebbero essere trovate con gli strumenti disponibili
• Restituisce prima di completare il flusso di lavoro richiesto

In questi casi, aumenta il livello di impegno.

Il modello potrebbe già avere capacità sufficienti.

Serve solo un segnale più forte che l'attività deve essere completata più a fondo.

Passo 3: Cerca segni di limiti di capacità

Quando si verifica quanto segue, il problema è più probabilmente nel modello stesso:

• Claude ha il contesto corretto
• Legge i file correlati
• Esegue i controlli previsti
• Tenta chiaramente di risolvere il problema
• Arriva comunque a una conclusione errata
• Riformulare l'attività non aiuta
• Aumentare l'impegno produce risultati più lunghi ma ancora errati

In questi casi, passa a un modello più potente.

Un impegno maggiore dà più spazio ai pesi stessi per funzionare, ma non sostituisce questi pesi con un set di capacità più forte.

Come scegliere tra Sonnet, Opus e Fable

I modelli specifici e le impostazioni predefinite cambiano nel tempo, quindi consulta sempre la documentazione corrente di Anthropic. La logica pratica di selezione è più duratura di qualsiasi nome di modello specifico.

Usa modelli più piccoli o bilanciati per lavoro ordinario

Per i seguenti compiti, modelli più veloci come Sonnet sono di solito sufficienti:

• Modifiche ristrette
• Riformattazioni
• Correzioni di bug dirette
• Migrazioni note
• Aggiornamenti di codice ripetitivi
• Modifiche alla documentazione
• Compiti con test solidi

Se l'attività coinvolge più file o richiede verifica, aumenta il livello di impegno prima di passare a un modello più costoso.

Usa modelli più grandi per lavoro ambiguo o difficile

Quando si verifica quanto segue, un modello più forte come Opus è più appropriato:

• La causa principale non è chiara
• L'attività si estende su più sistemi
• I requisiti sono in conflitto
• Il codebase contiene pattern non familiari
• È necessario giudizio architetturale
• La soluzione dipende da esperienze non presenti nel repository

Il vantaggio non è solo più token. Un modello più grande potrebbe aver appreso pattern più forti e avere un limite massimo di capacità più alto.

Riserva i modelli più potenti per i problemi più difficili

L'articolo originale descrive Fable come il modello esperto da chiamare quando gli altri rimangono bloccati.

Tali modelli sono più preziosi per:

• Attività agentive a ciclo lungo
• Diagnosi ingegneristiche complesse
• Lavoro architetturale difficile
• Debug con alta ambiguità
• Problemi non risolti con grandi sforzi da altri modelli

Poiché i modelli più potenti hanno anche il costo più alto in token, usali solo quando la loro capacità extra può cambiare il risultato.

Matrice pratica modello e impegno

| Tipo di attività | Strategia modello iniziale | Livello di impegno suggerito |
||||
| Rinomina, formattazione, modifica testo piccola | Modello veloce o bilanciato | Basso o Medio |
| Bug ristretto con test chiari | Modello bilanciato | Medio |
| Correzione bug multi-file | Modello bilanciato

| Alto |
| Grandi refactoring con requisiti chiari | Modello equilibrato o superiore | Alto o molto alto |
| Fallimento architetturale poco chiaro | Modello più potente | Alto |
| Flusso di lavoro autonomo lungo | Modello forte | Molto alto o massimo |
| Fallimenti ripetuti anche dopo indagini approfondite | Passaggio a un modello più potente | Mantenere abbastanza alto per la verifica |

Questo è un punto di partenza, non una regola fissa.

L'impostazione ottimale dipende da:

• Dimensione del repository
• Grado di ambiguità del compito
• Qualità dei test
• Disponibilità degli strumenti
• Limiti di costo
• Requisiti di latenza
• Requisiti di revisione

Perché non si dovrebbe regolare arbitrariamente il livello di sforzo

Modificare continuamente il livello di sforzo per ogni prompt rende costi e latenza imprevedibili.

Anthropic consiglia di iniziare con il livello di sforzo predefinito del modello scelto, quindi regolarlo come preferenza di lavoro più ampia.

Ad esempio:

• Usare uno sforzo basso per domande rapide e sotto-compiti numerosi.

• Usare uno sforzo medio per lo sviluppo ordinario.

• Usare uno sforzo alto per codifica difficile e flussi di lavoro agentici.

• Usare xhigh o max solo quando è necessaria una maggiore accuratezza.

Per gli utenti API, il parametro effort si applica a testo visibile, chiamate strumento, parametri strumento e pensiero esteso. Non è limitato a un singolo budget di ragionamento nascosto.

Ciò rende effort un controllo operativo diretto su quanto il modello è incoraggiato a lavorare.

Orchestrazione multi-agente e Ultracode

L'articolo originale menziona anche la modalità ultracode di Claude Code.

Un'idea importante è che alcuni compiti lunghi traggono beneficio da più thread agente. Invece di far esaminare a una singola istanza di Claude ogni parte di un compito grande in sequenza, un coordinatore può delegare lavori indipendenti ad agenti specializzati.

Esempi includono:

• Un agente che revisiona la sicurezza
• Un agente che controlla i test
• Un agente che legge la documentazione
• Un agente che implementa le modifiche
• Un coordinatore che integra i risultati

La documentazione di Managed Agents di Anthropic descrive sessioni multi-agente in cui gli agenti possono operare in parallelo, con cronologie di conversazione indipendenti. Ciò può aumentare la copertura e ridurre i tempi di completamento quando il compito è ben suddiviso.

L'esecuzione multi-agente non è automaticamente migliore.

Può aumentare:

• L'uso di token
• Il numero di chiamate strumento
• Il sovraccarico di coordinamento
• Il lavoro ridondante
• La complessità della revisione

Usarla solo quando il compito contiene flussi di lavoro indipendenti, non solo perché disponibile.

Dai ranking dei modelli allo scheduling degli agenti

L'implicazione più ampia è che il coding AI sta superando i ranking dei modelli.

In passato, il flusso di lavoro era semplice:

1. Scegliere il modello più forte disponibile.
2. Inviare il compito.
3. Accettare o rifiutare il risultato.

Il coding agentico moderno richiede uno scheduling più attivo.

Un team potrebbe usare:

• Un modello a costo inferiore per modifiche semplici
• Un modello bilanciato con sforzo alto per lavori a livello di repository
• Un modello più grande per architettura e diagnostica
• Diversi agenti specializzati per ricerche parallele
• Test deterministici per verificare il risultato finale

Ciò è più simile a gestire un team tecnico che a usare una barra di ricerca.

Chi opera questo sistema deve capire:

• Quali compiti richiedono capacità più forti
• Quali compiti richiedono più indagini
• Quali compiti possono essere eseguiti in parallelo
• Quali compiti richiedono approvazione umana
• Quali compiti devono fermarsi quando il budget si esaurisce

L'obiettivo non è consumare il maggior numero di token, ma spenderli dove aumentano la probabilità che il risultato venga accettato.

Checklist pratica per la risoluzione dei problemi

Quando Claude Code produce risultati deboli, eseguire il debug in quest'ordine:

1. Controllare il compito: La richiesta è specifica e testabile?
2. Controllare il contesto: Claude ha i file e le istruzioni corrette?
3. Controllare gli strumenti: Può leggere, modificare, eseguire e verificare ciò di cui il compito ha bisogno?
4. Controllare il comportamento: Ha saltato indagini o si è fermato presto?
5. Aumentare l'effort: Quando il modello non lavora abbastanza a fondo, aumentare l'effort.
6. Controllare le capacità: Ha indagato a fondo ma ha comunque frainteso il problema?
7. Cambiare modello: Quando il limite di capacità è il problema, passare a un modello più forte.
8. Verifica indipendente: Eseguire test, controllare le differenze e rivedere i risultati.
9. Misurare il costo per compito accettato: Non giudicare solo dal prezzo per token.
10. Registrare i fallimenti ripetuti: Aggiungerli al set di valutazione interno.

Domande frequenti

Qual è la differenza tra Modello e Sforzo in Claude Code?

La scelta del modello modifica i pesi di addestramento sottostanti, cambiando così le capacità complessive. Effort controlla quanto lavoro Claude è incoraggiato a svolgere nel compito corrente, inclusi ragionamento, lettura di file, chiamate strumento, test e verifica.

Uno sforzo maggiore può far sì che un modello più piccolo superi uno più grande?

In alcuni compiti sì. Un modello più piccolo con contesto sufficiente e sforzo elevato può indagare più a fondo di un modello più grande con sforzo basso. Tuttavia, lo sforzo non può superare i reali limiti di capacità.

Perché Claude Code salta a volte test o file?

Claude potrebbe funzionare con uno sforzo basso, l'ambito del compito è definito in modo poco chiaro, o mancano gli strumenti e il contesto necessari. Controllare prima il prompt e le istruzioni del repository, quindi aumentare lo sforzo se Claude si ferma prima di completare la verifica disponibile.

Quando passare a un modello Claude più potente?

Quando Claude ha il contesto corretto, indaga chiaramente il compito, esegue i controlli pertinenti, ma arriva comunque a una conclusione sbagliata. Se ha saltato del lavoro, aumentare lo sforzo è solitamente il passo prioritario migliore.

Lo sforzo equivale a un budget di token?

No. Anthropic descrive lo sforzo come un segnale comportamentale, non un limite rigoroso di token. Influenza la disponibilità di Claude a investire token nelle risposte, nelle chiamate strumento, nei parametri di funzione e nel pensiero esteso.

Quale sforzo usare durante il coding?

Usare sforzo predefinito o medio per compiti quotidiani, sforzo alto per coding difficile e compiti agentici, sforzo molto alto o massimo per flussi di lavoro lunghi o particolarmente impegnativi. Rivalutare costi e latenza in base al proprio compito.

Cos'è ultracode in Claude Code?

L'articolo originale descrive ultracode come la modalità ad alta intensità di Claude Code, che combina uno sforzo molto elevato e, quando necessario, coordina più agenti. Poiché il comportamento del prodotto può cambiare, consultare la documentazione corrente di Claude Code prima di fare affidamento su un'implementazione specifica.

Cambiare lo sforzo addestra Claude in modo permanente?

No. Lo sforzo modifica solo il comportamento della richiesta o della sessione. Non aggiorna i pesi del modello né insegna permanentemente nuove conoscenze a Claude.

Strumenti correlati

• Claude Code: Lo strumento di coding agentico di Anthropic per leggere repository, modificare file, eseguire comandi e completare attività software.
• Claude Platform: La piattaforma ufficiale per sviluppatori di Anthropic per utilizzare i modelli e le API di Claude.
• Claude Managed Agents: Toolkit per agenti gestiti con sandbox, strumenti, sessioni e orchestrazione multi-agente.
• Model Context Protocol: Protocollo open source per connettere applicazioni AI a strumenti e fonti di dati esterne.
• GitHub: Usato comunemente come piattaforma del codice sorgente con Claude Code per gestire repository, issue, revisioni del codice e pull request.
• Claude Agent Skills: Pacchetti di istruzioni riutilizzabili che estendono le capacità di Claude con flussi di lavoro e risorse per compiti specifici.

Collegamenti correlati

• [Come selezionare il modello Claude

Modello e livello di impegno: Spiegazione ufficiale di Anthropic sulla selezione del modello e sul livello di impegno in Claude Code.

• Documentazione sul livello di impegno di Claude: Documentazione ufficiale sul livello di impegno, modelli supportati e comportamento dell'API.

• Come scegliere il modello Claude corretto: Guida di Anthropic alla selezione del modello in base a capacità, costi e tipo di attività.

• Registro modifiche di Claude Code: Cronologia ufficiale delle release di Claude Code con modifiche e impostazioni predefinite.

• Sessioni multi-agente con agenti gestiti da Claude: Documentazione ufficiale per coordinare più agenti Claude.

• Schema di orchestrazione: Guida all'uso di Anthropic per combinare alto impegno e orchestrazione multi-agente.

• Repository GitHub di Claude Code: Repository ufficiale del codice sorgente, tracciamento dei problemi e registro modifiche di Claude Code.

Riepilogo

Anche se il modello sottostante non cambia, Claude Code può sembrare meno performante. La causa può essere un'impostazione bassa dell'impegno, un contesto incompleto, la mancanza di strumenti o un ambito del compito poco chiaro.

La scelta del modello determina il limite massimo delle capacità. L'impegno decide quanto Claude utilizza tali capacità attraverso la lettura di file, l'invocazione di strumenti, l'esecuzione di test e la verifica del lavoro.

Inizia correggendo l'input. Aumenta il livello di impegno quando Claude salta lavoro disponibile. Cambia modello quando ha esplorato a fondo il compito ma non riesce comunque a risolverlo.

La migliore configurazione di Claude Code non è sempre il modello più grande, ma il modello giusto con impegno, contesto, strumenti e verifica del compito adeguati.