Stai consumando troppo Claude?

Probabilmente non perché lo usi tanto.
Probabilmente perché lo usi nel modo più costoso.

È qui che quasi tutti sbagliano.

Si fissano sul prompt perfetto. Cambiano due frasi. Accorciano una riga. Aggiungono un comando. Poi però continuano a fare gli errori che pesano davvero: usano un modello troppo potente per compiti semplici, si fanno restituire risposte lunghissime, rimandano ogni volta lo stesso contesto e trattano come urgenti task che potrebbero tranquillamente andare in batch.

Il risultato è prevedibile: il consumo sale, la qualità non sempre migliora, e il budget si sporca.

La buona notizia è che si può correggere tutto con una strategia pulita.

La prima mossa è scegliere il modello giusto.

Anthropic indica Haiku 4.5 come il modello “fastest, most cost-efficient”, con prezzo di $1/MTok in input e $5/MTok in output. Sullo stesso listino, Sonnet 4.5 è a $3/MTok input e $15/MTok output, mentre Opus 4.6 arriva a $5/MTok input e $25/MTok output. Questo vuol dire una cosa molto semplice: se usi Sonnet o Opus per classificare, ripulire, estrarre o riassumere task banali, stai pagando troppo.

In pratica, Haiku dovrebbe reggere gran parte del lavoro ripetitivo.
Sonnet dovrebbe diventare il tuo livello intermedio.
Opus dovrebbe entrare solo quando serve davvero più profondità.

La seconda mossa è tagliare gli output.

Qui c’è uno spreco enorme e silenzioso. Guardando il pricing ufficiale, l’output costa molto più dell’input sui modelli principali. Questo significa che ogni risposta prolissa, ridondante o piena di introduzioni inutili non è solo fastidiosa da leggere. È costosa.

Se vuoi consumare meno con Claude, devi smettere di chiedere risposte “complete” quando ti serve solo una risposta utile.

Molto meglio:

“Massimo 120 parole.”
“Dammi 5 punti, non di più.”
“Rispondi in JSON.”
“Niente premessa, niente conclusione, solo output operativo.”

Questa singola abitudine cambia il conto molto più di tanti micro-ritocchi al prompt.

La terza mossa è usare il prompt caching quando il contesto si ripete.

Anthropic mostra nel pricing le tariffe di cache write e cache read per i modelli, e specifica che il pricing mostrato riflette una TTL di 5 minuti. Nella documentazione spiega anche quando usare la cache da 5 minuti e quando ha senso la cache da 1 ora, aggiungendo che su prompt lunghi si vede in genere un miglioramento del tempo al primo token.

Tradotto: se mandi spesso lo stesso system prompt, le stesse linee guida, gli stessi esempi o la stessa base documentale, non dovresti pagarli ogni volta come se fossero nuovi.

Dovresti metterli in cache.

È una leva forte per chi lavora con workflow ripetitivi, team, agenti o applicazioni con struttura stabile.

La quarta mossa è smettere di idolatrare le chat infinite.

Qui entra in gioco il context engineering. Anthropic lo descrive come il lavoro di curare ciò che entra in una finestra di contesto limitata, scegliendo ogni volta cosa vale davvero la pena passare al modello. Nello stesso articolo spiega anche un problema chiave: quando i token aumentano troppo, il modello può perdere focus o confondersi.

Questa è una verità poco romantica ma molto utile: più cronologia trascini, più paghi. E spesso ottieni anche risposte peggiori.

Per questo la regola dovrebbe essere semplice:
ogni pochi turni, crea un riassunto di stato.

Tieni solo:

• obiettivo
• vincoli
• decisioni prese
• dati ancora vivi

Il resto non serve sempre. E quando non serve, pesa.

La quinta mossa è evitare di incollare documenti interi “per sicurezza”.

È una delle abitudini più costose in assoluto.
Se hai una base documentale ampia, è molto meglio recuperare solo i passaggi davvero pertinenti e passarli al modello. Meno token, meno rumore, meno dispersione. Il beneficio è doppio: spendi meno e aumenti la probabilità che Claude risponda in modo più pulito.

La sesta mossa è usare il batch quando il task non è urgente.

Sul pricing ufficiale, Anthropic scrive in chiaro: “Save 50% with batch processing.”

Questo cambia completamente l’economia di lavori come:

• tagging
• classificazione
• riassunti in coda
• scoring
• analisi massive
• enrichment di contenuti

Molte aziende trattano tutto come una conversazione live.
È uno spreco.

Non tutto deve essere istantaneo.
Molte cose devono solo essere elaborate bene, in fila, al costo più basso possibile.

La settima mossa è contare i token prima di inviare.

Anthropic documenta un endpoint dedicato al token counting e specifica che la risposta contiene il numero totale di token di input, da considerare come una stima. È un dettaglio tecnico solo in apparenza. In realtà è uno dei modi più semplici per evitare richieste gonfie prima ancora che partano.

Se vedi che il payload è troppo grande, puoi:

• comprimere
• spezzare
• riassumere
• recuperare meno materiale
• imporre un output più corto

Meglio bloccare uno spreco prima dell’invio che giustificarlo dopo.

C’è poi un ultimo punto che molti trascurano: i tool extra.

Anthropic separa anche alcuni costi accessori. Per esempio, indica web search a $10 per 1.000 ricerche e code execution con 50 ore gratuite al giorno per organizzazione, poi $0,05 per ora per container.

Questo significa che non ha senso attivare strumenti più costosi per inerzia.
Se il task si risolve in puro testo, lascialo in puro testo.

Alla fine, consumare meno con Claude non significa usare meno AI.

Significa usarla con più disciplina.

Usa Haiku per il grosso del lavoro semplice.
Tieni Sonnet per il lavoro che deve restare buono e stabile.
Usa Opus solo come escalation vera.
Imponi output corti.
Metti in cache il contesto fisso.
Accorcia la history.
Recupera solo i pezzi davvero utili.
Sposta in batch tutto ciò che non è urgente.
Conta i token prima di inviare.
Evita tool extra quando non servono.

Il risparmio non nasce da un trucco.

Nasce da una scelta: smettere di trattare Claude come una scatola magica e iniziare a trattarlo come un sistema da governare bene.

È lì che il consumo scende.
Ed è lì che il lavoro resta buono.

FAQ

Qual è il modo più veloce per consumare meno con Claude?
Le due leve più rapide sono queste: usare il modello minimo sufficiente e accorciare gli output. Il pricing ufficiale mostra differenze nette tra Haiku, Sonnet e Opus, e l’output pesa molto sul costo finale.

Quando conviene usare Haiku invece di Sonnet o Opus?
Quando il task è semplice, ripetitivo o ad alto volume: classificazione, estrazione, pulizia testo, riscrittura breve, sintesi operativa. Anthropic presenta Haiku 4.5 come il modello più veloce e più conveniente.

Il prompt caching serve davvero?
Sì, soprattutto quando riusi spesso lo stesso prefisso di contesto: system prompt, policy, esempi, guide o documenti base. Anthropic documenta cache da 5 minuti e 1 ora e segnala benefici anche sulla latenza dei prompt lunghi.

Perché le chat lunghe fanno consumare di più?
Perché aumentano i token e rendono il contesto più difficile da governare. Anthropic spiega che il context engineering serve proprio a selezionare cosa far entrare nella finestra limitata e segnala che, quando il contesto cresce troppo, il modello può perdere focus.

Quando conviene usare batch processing?
Quando il lavoro non è urgente e può essere elaborato in coda. Anthropic dichiara un risparmio del 50% con batch processing.

Come posso stimare il consumo prima della richiesta?
Usando il token counting endpoint. Anthropic specifica che restituisce il totale dei token di input come stima prima della creazione del messaggio.

I tool come web search e code execution incidono sui costi?
Sì. Anthropic separa questi costi nel pricing: web search ha una tariffa dedicata e code execution ha una quota gratuita giornaliera, poi un costo per ora container.

Fonti
Anthropic Pricing — prezzi modelli, batch processing, web search, code execution: Claude Pricing
Anthropic Docs — Prompt Caching: Prompt Caching
Anthropic Docs — Token Counting: Token Counting
Anthropic Engineering — Context engineering: Effective context engineering for AI agents