Claude Code ti offre due impostazioni che sembrano entrambe "migliorare la risposta": il modello e il livello di impegno. Ma cosa fanno realmente queste impostazioni sull'output? E come fai a sapere se devi optare per un modello diverso o semplicemente cambiare il livello di impegno?
È facile supporre che scegliere un modello più grande come Fable ti dia un output più intelligente rispetto a Sonnet, e che un livello di impegno più alto significhi semplicemente che Claude pensa più a lungo prima di rispondere.
La prima supposizione è vera. I nostri modelli più grandi sono più capaci, secondo i benchmark standard del settore.
Ma l'impegno significa più di "tempo di riflessione". L'impegno controlla quanto lavoro Claude svolge sulla tua richiesta in generale. Questo include quanto tempo pensa, ma anche:
- quanti file legge;
- quanto verifica; e
- quanto avanza in un'attività multi-step prima di chiedere il tuo riscontro.
Con un impegno maggiore, Claude esegue più di queste azioni (leggere file, eseguire test, ricontrollare) prima di tornare da te. Con un impegno minore, preferisce chiederti più contesto piuttosto che spendere token per capire qualcosa da solo.
Come funziona la selezione del modello
Per capire cosa controlla effettivamente l'impostazione del modello, è utile iniziare dall'inizio, dal momento in cui premi invio.
Claude Code assembla il tuo messaggio insieme al prompt di sistema, alle definizioni degli strumenti, al tuo CLAUDE.md, alla cronologia della conversazione e a qualsiasi file nel contesto. Tutto questo viene inviato come una singola richiesta all'API.
Tutto ciò che Claude Code ha viene impacchettato in una singola richiesta API. Sul server, il testo viene tokenizzato prima ancora di raggiungere il modello.
Il modello non vede mai tutto questo come testo semplice, però. La prima cosa che accade sul server è la tokenizzazione: il testo viene suddiviso in pezzi, e ogni pezzo viene mappato a un intero da un vocabolario fisso su cui il modello è stato addestrato. \const\ potrebbe essere mappato a 1978, \await\ potrebbe essere mappato a 4293. Da qui in poi, il tuo prompt è un array di interi.
Il tokenizer suddivide il tuo testo in pezzi e mappa ogni pezzo a un intero in un vocabolario fisso. Ogni blocco nella riga superiore diventa il suo ID token (riga inferiore); gli ID mostrati sono illustrativi.
Il compito del modello è prendere quell'array e prevedere quale token viene dopo. Lo fa calcolando una probabilità per ogni token nel suo vocabolario e scegliendo tra i migliori. Dopo "const x = await", un modello ben addestrato assegna un'alta probabilità a "fetch" (molto probabile) e quasi zero a "banana" (per niente probabile).
La previsione del modello è una probabilità per ogni token nel suo vocabolario. Il divario tra la migliore ipotesi e una non correlata è enorme.
Ciò che trasforma i tuoi token di input in quelle probabilità sono i pesi (chiamati anche parametri): miliardi di numeri organizzati in grandi matrici. Per prevedere un token, il modello esegue il tuo input attraverso quelle matrici (una lunga catena di moltiplicazioni di matrici) e legge le probabilità alla fine. I pesi sono dove vive tutto ciò che il modello "sa".
I pesi di ogni modello vengono impostati durante l'addestramento e, quando invii le richieste, sono di sola lettura. Niente nel tuo prompt, nel tuo CLAUDE.md o nel tuo contesto li modifica. Se ti sei imbattuto nella parola inferenza, significa solo questo: usare il modello dopo che l'addestramento è terminato, con i pesi fissi.
Il tuo prompt entra, le probabilità escono. I pesi nel mezzo non cambiano.
Tutto ciò che Claude sa su TypeScript, framework popolari o qualsiasi altra conoscenza generale di programmazione è stato codificato in quei pesi durante l'addestramento.
Il tuo prompt e il contesto possono comunque guidare la previsione. Mettere il tuo codice reale davanti a Claude è una forma di guida, e funziona molto bene. Tuttavia, questo non aggiunge nulla ai pesi stessi.
Se una libreria non esisteva quando il modello è stato addestrato, non è nei pesi. Puoi mettere la documentazione nel contesto e Claude la userà, ma questa è guida, non insegnamento. La risposta di Claude è influenzata solo per quella singola richiesta, ma il modello sottostante non ha trattenuto nulla.
Quando Claude chiama con sicurezza un'API che non esiste (un'allucinazione), sono i pesi che producono una sequenza di token che sembra plausibile dai pattern di addestramento, non una ricerca fallita.
Quindi, cosa fa effettivamente cambiare il modello? Scambia quale insieme di pesi congelati gestisce la tua richiesta.
Il modello non genera un'intera risposta in una volta. Prevede un token, lo aggiunge alla sequenza, e ripete l'intero calcolo per ottenere il successivo. Una risposta di 200 token richiede 200 passaggi separati attraverso i pesi. Questo ciclo è la causa della maggior parte del tuo tempo di attesa (e del costo dell'output).
La sequenza cresce esattamente di un token per passo. Il modello rilegge l'intero array ogni volta per prevedere cosa viene dopo.
L'impostazione del modello decide quali pesi gestiscono la tua richiesta, e decide anche quanto costa ogni token di output.
Ciò che non decide è quanti token vengono generati. Questo numero può variare molto per lo stesso prompt, a seconda di quanto lavoro Claude decide di fare.
Che è esattamente ciò che controlla l'impegno.
Come funziona l'impegno
Mentre Claude Code lavora su un'attività, i token che genera rientrano in alcune categorie:
- Pensiero: il ragionamento che vedi scorrere prima e tra le azioni.
- Chiamate a strumenti: blocchi strutturati che nominano uno strumento come Read o Edit e i suoi argomenti, che Claude Code poi analizza ed esegue.
- Testo per te: il piano, gli aggiornamenti di stato, il riepilogo alla fine.
Tutti questi sono normali token di output dello stesso ciclo, fatturati alla stessa tariffa. I token di pensiero, ad esempio, vengono generati esattamente come gli altri token di output e rimangono nel contesto per il resto di quel turno.
Quando Claude passa a scrivere codice, il suo ragionamento precedente fa parte dell'input, proprio come un file che ha letto.
Tutto l'output di Claude è costituito da token. Pensiero, chiamate a strumenti e testo per te sono tutti generati dallo stesso ciclo.
Quindi, in che modo l'impegno cambia tutto questo? Il livello di impegno viene inviato al modello come parte della richiesta, insieme al tuo prompt. Il modello è stato addestrato per capire come comportarsi a ogni livello di impegno, e questo comportamento appreso è integrato nei pesi congelati.
Quando la tua richiesta arriva, l'impegno è solo un altro input a cui il modello risponde, allo stesso modo in cui risponde al testo del tuo prompt. Imposta quanto approfondito, e quanto certo, Claude deve essere prima di considerare l'attività completata. Questo viene valutato a ogni turno, e una maggiore fiducia richiede più token per essere raggiunta.
Stesso prompt, due livelli di impegno. Il percorso ad alto impegno genera circa 7 volte più token per raggiungere una risposta con maggiore sicurezza.
A livelli di impegno più alti, Claude spesso inizia creando un piano, e il livello di impegno influenza la profondità e l'ampiezza di quel piano. Ma il piano non è scolpito nella pietra. Man mano che Claude ottiene risultati dalle sue azioni, aggiorna la sua immagine di quanti progressi ha fatto e quanto è certo del risultato accumulato.
Quando il passo 1 di un piano di debug a tre ipotesi trova il bug, "investiga le ipotesi 2 e 3" potrebbe non essere più necessario. Claude di solito lo dirà esplicitamente (ad es. "il primo controllo ha trovato il bug, quindi i controlli rimanenti non sono necessari") e salterà avanti. Vedi questo accadere in Claude Code quando gli elenchi di attività vengono rivisti a metà esecuzione.
Un impegno maggiore rende Claude più propenso a ricontrollare, come verificare la risposta trovata, o comunque esaminare le ipotesi che avrebbe potuto saltare. Tuttavia, generalmente non gonfierà artificialmente l'utilizzo su un'attività semplice solo perché il livello di impegno è alzato. Il "pensare troppo" è qualcosa che il nostro team controlla specificamente durante l'addestramento del modello, poiché degrada l'efficacia.
Scegliere un livello di impegno
Per la maggior parte delle attività, usa il livello di impegno predefinito del modello. Il valore predefinito è il livello in cui Claude scala il suo utilizzo di token a ciò che la maggior parte delle persone vorrebbe spendere per un'attività.
Pensa all'impegno come a un override manuale su quanto duramente e a lungo lavora Claude. Usalo deliberatamente quando hai una forte preferenza per la completezza o la velocità in base al tuo dominio o al tipo di lavoro che svolgi, e trattalo come una preferenza generale, non una decisione attività per attività.
Una nota pratica dopo il lancio di Opus 4.8: nei nostri test, l'impostazione di impegno predefinita su Opus 4.8 produce risultati migliori per circa la stessa quantità di token dell'impostazione di impegno predefinita su Opus 4.7 per la stessa attività.
Cosa cambiare quando Claude sbaglia
Quando Claude sbaglia, il tuo primo istinto non dovrebbe essere cambiare un'impostazione. Dovrebbe essere guardare al contesto che gli hai fornito. Il tuo prompt è troppo vago? Claude è connesso agli strumenti giusti? Ha le competenze giuste?
Se stai aumentando l'impegno su un'attività che non dovrebbe richiederlo, la soluzione è di solito a monte: nel tuo contesto, nel tuo CLAUDE.md, o in come è definita l'attività.
Ma supponiamo che tu abbia fornito un contesto chiaro e Claude sbagli ancora. La domanda da porti è: non ha provato abbastanza, o non sapeva abbastanza?
Modello: il problema era troppo difficile
Scegli un modello più grande quando il problema è veramente difficile, come bug sottili, domini sconosciuti, decisioni architetturali. Un modello più grande è ciò che vuoi quando il modello più piccolo è sicuro di sbagliare indipendentemente da quanto contesto gli fornisci.
I modelli più grandi sono anche migliori nel gestire l'ambiguità. Su modelli più piccoli, istruzioni specifiche che guidano l'esecuzione sono una ricetta migliore per il successo.
Scegli un modello più piccolo quando il lavoro è di routine: modifiche che puoi descrivere con precisione, cambiamenti meccanici, domande sul codice già nel contesto. Non c'è motivo di pagare per una capacità di cui l'attività non ha bisogno.
Se Claude aveva tutto il contesto pertinente, ha chiaramente provato, e ha comunque sbagliato; questo è un segnale per scegliere un modello più grande. E se sei sul modello più grande e il lavoro è stato di routine per un po', scendere aumenterà la velocità e tipicamente ridurrà i costi senza influire sulla qualità dell'output.
Impegno: Claude non ha provato abbastanza
Scegli un livello di impegno più alto se Claude ha sbagliato perché non ha provato abbastanza: saltando un file, non eseguendo i test, o non ricontrollando il suo lavoro. Questo è più rilevante se hai selezionato un livello di impegno inferiore a quello predefinito del modello.
Lo specialista, l'esperto e il generalista
Un modo in cui mi piace pensare alle due impostazioni è che Fable è uno specialista che può gestire problemi che quasi nessun altro può, Opus è l'esperto, e Sonnet è un generalista molto bravo. Il livello di impegno decide quanto tempo ognuno di loro dedica alla tua attività.
Opus a basso impegno è come avere cinque minuti con un esperto che ha una profonda esperienza con problemi simili ai tuoi. Portano conoscenza che non è da nessuna parte nel tuo codebase; pattern che hanno già visto, insidie che sanno di dover controllare, il tipo di esperienza che ottieni solo avendo risolto molti problemi simili. Ma cinque minuti significano una lettura veloce del tuo codice, non un passaggio attento attraverso ogni file.
Sonnet ad alto impegno è il generalista con tutto il pomeriggio a disposizione. È bravissimo a programmare, e leggerà tutto, eseguirà cose, ricontrollerà il suo lavoro, e finirà per capire a fondo il tuo codice specifico.
Fable è lo specialista che chiami quando tutti gli altri sono bloccati. Anche a basso impegno, individuerà la cosa che nessun altro vedrebbe. Quel riconoscimento è anche ciò per cui paghi di più, quindi vale la pena riservarlo per le attività che ne hanno bisogno.
Nessuno di questi è universalmente "migliore". L'impostazione del modello è approssimativamente quanto è capace; l'impostazione dell'impegno è approssimativamente quanto è approfondito. La maggior parte delle attività reali ha bisogno di un po' di entrambi.
Impegno, modello e consumo di token
Quindi, come interagiscono selezione del modello, impegno e consumo di token? Dipende dall'attività.
Sul lavoro di routine allo stesso livello di impegno, sia i modelli più grandi che quelli più piccoli generalmente lo fanno bene. Il modello più grande consuma più token con passaggi di verifica extra, a un prezzo per token più alto. Ecco perché scendere al modello più piccolo per tratti di routine fa risparmiare denaro reale senza alcun costo in termini di qualità.
Le curve sono solo a scopo illustrativo, mostrate per una singola attività abbastanza semplice da essere completata rapidamente da entrambi i modelli. Non rappresentano dati di benchmark reali.
Su lavori più difficili e multi-step, l'equazione si capovolge. Il modello più piccolo deve sforzarsi verso il limite della sua capacità, bruciando iterazioni, mentre il modello più grande raggiunge lo stesso livello di qualità in meno passaggi.
Stai pagando di più per token per il modello più grande, ma su attività che mettono veramente alla prova quello più piccolo, il costo totale per attività può risultare inferiore. E, cosa più importante: il modello più grande può completare attività che quello più piccolo non può, anche ai livelli di impegno più alti.
Questo è più pronunciato con Fable. Su lavori lunghi e multi-step, si distacca maggiormente. Nei nostri test, ha completato lavori che Opus e Sonnet non possono raggiungere a nessun livello di impegno. Costa anche di più per token, che è l'altro motivo per riservarlo al lavoro che ne ha veramente bisogno.
Le curve sono solo a scopo illustrativo, mostrate per una singola attività abbastanza difficile da mettere alla prova entrambi i modelli. Non rappresentano dati di benchmark reali.
Il punto chiave nei grafici sopra: l'impegno sceglie quanto lontano Claude è disposto a viaggiare lungo la curva. Questo non significa che Claude avrà bisogno di andare così lontano per completare l'attività.
Infine, l'impegno modella il consumo di token, ma non lo limita. L'unico limite rigido nel sistema è max_tokens, che tronca una risposta a metà flusso quando viene raggiunto, ma è uno strumento grossolano e per lo più rilevante per gli sviluppatori API. Controlli più morbidi come task budgets o chiedere a Claude di essere breve nel tuo prompt sono più utili. Sono linee guida che il modello è addestrato a seguire (cercherà di concludere quando si avvicina al limite) piuttosto che un muro contro cui si scontra.
L'impegno cambia quanto lavoro fa Claude. Il modello cambia ciò che Claude sa.
Quando non sei soddisfatto di un risultato, controlla il contesto prima di toccare una delle due impostazioni: dai a Claude un prompt chiaro, gli strumenti e le competenze giuste, e un modo per verificare il suo stesso lavoro.
Se Claude sbaglia ancora, chiediti: non sapeva abbastanza, o non ha provato abbastanza? Non sapere abbastanza è un problema di modello, non provare abbastanza è un problema di impegno.
Questo articolo è stato scritto da @lydiahallie, membro dello staff tecnico del team Claude Code.
