Modelli, utilizzo e limiti in Claude Code

Questa guida spiega quale modello stai utilizzando, come viene misurato l'utilizzo e come mantenere le sessioni lunghe entro i loro limiti di contesto e utilizzo.

Il modo in cui hai effettuato l'accesso determina come viene misurato l'utilizzo. Tutto il resto di Claude Code si comporta allo stesso modo indipendentemente.

Se hai effettuato l'accesso con un posto Enterprise, generalmente non devi pensare ai token finché non raggiungi un limite. Se stai utilizzando una chiave API, il comando /cost mostra la tua spesa corrente per la sessione attuale.

Esegui /model in qualsiasi momento per vedere quali modelli sono disponibili per il tuo account e per passare da uno all'altro. Come guida approssimativa:

Puoi cambiare modelli a metà sessione senza perdere la tua conversazione. Un modello comune è pianificare con Opus ed eseguire con Sonnet.

Ogni turno invia tre cose al modello:

Di questi, il primo elemento cresce più velocemente. Una lunga sessione di debug in cui Claude ha letto venti file e prodotto quindici diff sta portando tutto questo su ogni messaggio successivo. Qui è dove originano sia il costo che i limiti di contesto.

La finestra di contesto è la quantità massima di testo che il modello può considerare contemporaneamente. Claude Code mostra un indicatore live di quanto è piena. Quando si riempie, Claude non riesce più a vedere chiaramente le parti più vecchie della conversazione e la qualità diminuisce.

Due comandi la mantengono sotto controllo:

Regola pratica: usa /clear quando inizi una nuova attività e /compact quando continui una lunga.

Quasi ogni rapporto "Ho esaurito il mio limite a pranzo" risale a uno di questi cinque.

Ogni messaggio precedente viene rinviato ad ogni turno, quindi una sessione che ha vagato attraverso tre problemi non correlati paga per tutti e tre ad ogni nuovo messaggio. In pratica: hai appena finito di eseguire il debug di un reindirizzamento di accesso e ora vuoi scrivere una migrazione del database. Esegui prima /clear. Un semplice test: se il tuo prossimo prompt avrebbe perfettamente senso in un terminale completamente nuovo, cancella prima di inviarlo. Il tuo CLAUDE.md e i file del progetto rimangono; solo la cronologia della chat se ne va. Un avvertimento: /clear non può essere annullato. Se potresti ancora aver bisogno di qualcosa dalla cronologia, copialo prima o esegui /compact invece, che preserva un riepilogo piuttosto che cancellare tutto.

Opus costa diversi volte di più per turno rispetto a Sonnet, e Sonnet più di Haiku. Spendere Opus su lavoro di routine è il modo più veloce per esaurire un limite giornaliero. Impostazioni predefinite ragionevoli: Sonnet per la maggior parte della codifica (funzionalità, test, bug noti, refactoring); Opus quando sei veramente bloccato o il cambiamento è ampio (debug difficile, refactoring su larga scala, decisioni architettoniche); Haiku per lavoro meccanico veloce (rinominazioni, righe di log, spiegazioni regex, boilerplate).

Tutto ciò che incolli rimane nel contesto, completamente, per il resto della sessione. Fare riferimento a un file per percorso consente a Claude di leggere selettivamente e concentrarsi sulla parte che ti interessa. In pratica: invece di incollare auth.ts, scrivi guarda la funzione validateToken in @src/auth.ts. Per log e stack trace, riduci alle 20 o 30 righe rilevanti prima di incollare. Per qualsiasi cosa di grandi dimensioni (lockfile, log di build, dump di dati), mettilo su disco e fai riferimento al percorso.

Questo file viene anteposto a ogni turno, quindi il suo costo viene moltiplicato per il numero di messaggi che invii. Un CLAUDE.md di 300 righe in una sessione di 40 turni è 12.000 righe di input per cui hai pagato prima di fare qualsiasi lavoro. La regola: due strike, uno schermo. Aggiungi una nota solo la seconda volta che devi correggere Claude sulla stessa cosa (i problemi della prima volta sono solitamente isolati). E non lasciare mai che il file cresca oltre una singola schermata di circa 80-100 righe; se qualcosa di nuovo deve entrare e non c'è spazio, qualcosa di vecchio deve uscire. Quando aggiornarlo: subito dopo una sessione in cui hai dovuto correggere Claude due volte sulla stessa cosa. È quando la correzione è fresca e ci vuole un minuto per scriverla. Ogni poche settimane, leggi l'intero file ed elimina tutto ciò che non è più vero o di cui non ricordi lo scopo. Le note obsolete sono peggio delle note mancanti perché indirizzano attivamente Claude in modo errato.

Un piano costa poche centinaia di token. Un diff di 400 righe sbagliato che ripristini e rigenerare costa migliaia, due volte, più i turni spesi a spiegare cosa è andato storto. In pratica: per qualsiasi cosa che tocchi più di due o tre file, passa alla modalità Piano o semplicemente chiedi: "Prima di cambiare qualcosa, elenca i file che toccherai e cosa farai in ciascuno." Leggi l'elenco, correggilo in inglese semplice ("salta legacy/ e non toccare ancora i test"), quindi lascialo eseguire.

Suggerimento professionale: pianifica con Opus, esegui con Sonnet. L'uso di Opus di più alto valore è scrivere il piano stesso, dove il ragionamento più profondo effettivamente ripaga. Una volta che esiste un buon piano, l'esecuzione è principalmente meccanica e Sonnet la gestisce a una frazione del costo. Flusso di lavoro: /model opus, chiedi il piano, rivedi e correggilo, quindi /model sonnet e "esegui il piano sopra." Il cambio di modelli non cancella la conversazione, quindi Sonnet vede ancora tutto ciò che Opus ha prodotto.