Claude API: quanto costa davvero un'automazione in produzione

L'API di Claude si paga a consumo, senza abbonamento fisso. Il listino parte da 1 dollaro per milione di token in ingresso con Haiku 4.5 e arriva a 10 dollari con Fable 5, con l'output che costa cinque volte l'input su tutta la gamma (listino ufficiale, consultato il 2026-08-12). Il mio sistema personale è in produzione da metà febbraio 2026 e oggi conta 35 automazioni. La spesa API, ordine di grandezza: sotto i 50 euro al mese. Ecco i numeri veri, i limiti che incontri davvero e come partire.

Una premessa che vale più di tutto il resto: i prezzi in questo articolo sono stati verificati alla pagina ufficiale Anthropic il 27 luglio 2026, giorno di uscita, e riverificati il 12 agosto 2026. Il listino dei modelli AI cambia più velocemente di quanto un articolo resti fermo, e nel giro di un anno abbondante è cambiato parecchio: più tempo è passato da quella data, più conviene ricontrollare. Prima di mettere un numero in un business plan o in un preventivo firmato, riaprilo alla fonte: pricing ufficiale Anthropic, consultato il 2026-08-12.

Quanto costa davvero l'API di Claude nel 2026?

Il conto si fa su due voci, token in ingresso e token in uscita, misurate in milioni di token (MTok). Un token vale grosso modo 4 caratteri o 0,75 parole in inglese.

Listino base, per milione di token, input e output (listino ufficiale, consultato il 2026-08-12):

• Claude Haiku 4.5 (claude-haiku-4-5): 1 dollaro input, 5 dollari output. Context window 200K token, output massimo 64K.
• Claude Sonnet 5 (claude-sonnet-5): 2 dollari input, 10 dollari output. Il prezzo introduttivo è diventato listino standard: l'aumento a 3 e 15 previsto per il 1° settembre 2026 non ci sarà. Context window 1M token, output massimo 128K.
• Claude Opus 5 (claude-opus-5): 5 dollari input, 25 dollari output. Context window 1M token, output massimo 128K.
• Claude Fable 5 (claude-fable-5): 10 dollari input, 50 dollari output. Context window 1M token, output massimo 128K.

Restano disponibili i modelli della generazione precedente, allo stesso prezzo del pari grado attuale: Opus 4.8, 4.7 e 4.6 stanno tutti a 5 e 25, Sonnet 4.6 a 3 e 15.

Il punto è che questi numeri raccontano una storia. Chi ha scritto un preventivo sull'API nel 2024 aveva in testa, ordine di grandezza: Opus a 15 dollari input e 75 output. Oggi quel prezzo è rimasto solo su Claude Opus 4.1, deprecato e ritirato il 5 agosto 2026. La fascia top di gamma è scesa a un terzo, e nel frattempo la finestra di contesto è passata da 200K a un milione di token senza sovrapprezzo. Sul costo per unità di lavoro siamo a un ordine di grandezza di differenza in due anni.

Un conto concreto, per capire l'ordine di grandezza

Prendi un task tipico di automazione, ipotesi: 8.000 token di contesto in ingresso (istruzioni, schema, documento) e 1.200 token generati in uscita. Trecento esecuzioni al mese.

• Con Haiku 4.5: 2,4 MTok input più 0,36 MTok output. Fanno 2,40 dollari più 1,80. Totale circa 4,20 dollari al mese.
• Con Sonnet 5: 4,80 più 3,60. Totale circa 8,40 dollari al mese.
• Con Opus 5: 12 più 9. Totale circa 21 dollari al mese.

Trecento esecuzioni al mese sono dieci al giorno, cioè un task schedulato che gira più volte per ciclo. Il discorso è che a questi volumi la scelta del modello sposta la bolletta di venti dollari, non di duemila. La domanda vera non è "quale modello costa meno", è "a quale modello posso delegare il task senza doverlo rifare". Un output da rigenerare due volte con Haiku costa più di un output corretto al primo colpo con Sonnet.

Quali sono i tre moltiplicatori che cambiano il conto?

Qui sta la parte che i confronti di listino non raccontano. Il prezzo base è solo il punto di partenza: tre meccanismi lo moltiplicano, verso il basso o verso l'alto.

1) Prompt caching: il layer che taglia la voce più pesante

Se mandi lo stesso blocco di contesto a ogni chiamata (system prompt lungo, documento di riferimento, definizioni di tool, storico conversazione), il prompt caching lo memorizza e te lo rifattura a una frazione.

I moltiplicatori sono questi, applicati al prezzo base dell'input (listino ufficiale, sezione prompt caching, consultato il 2026-08-12):

• Scrittura in cache con validità 5 minuti: 1,25x
• Scrittura in cache con validità 1 ora: 2x
• Lettura da cache: 0,1x

Fatti il conto: con la cache a 5 minuti paghi il 25% in più la prima volta e poi il 10% del prezzo pieno a ogni riuso (listino ufficiale, sezione prompt caching, consultato il 2026-08-12). Il pareggio arriva dopo una sola rilettura. Con la cache a un'ora paghi il doppio la prima volta e pareggi alla seconda rilettura.

Su Opus 5 significa passare da 5 dollari a 0,50 dollari per milione di token sulla parte ripetuta. Ipotesi: se il tuo prompt è fatto per l'80% di contesto stabile, hai appena tagliato la voce input di circa il 72%.

C'è una condizione tecnica che rovina tutto se la ignori: il caching lavora su corrispondenza di prefisso. Un solo byte diverso all'inizio invalida tutto quello che viene dopo. Se infili un timestamp, un UUID o il nome utente dentro il system prompt, il prefisso cambia a ogni richiesta e la cache non entra mai in funzione. Non ricevi un errore. Ricevi semplicemente il conto pieno. Il modo per accorgersene è leggere cache_read_input_tokens nella risposta: se resta a zero su richieste ripetute, hai un invalidatore silenzioso da qualche parte nel prefisso.

2) Batch API: metà prezzo se puoi aspettare

Se il task non è interattivo, la Batch API (documentazione consultata il 2026-08-12) applica uno sconto del 50% su input e output. Opus 5 scende a 2,50 e 12,50, Sonnet 5 a 1 e 5, Haiku 4.5 a 0,50 e 2,50.

Un aggiornamento su Sonnet 5: quell'1 e 5 era la metà del prezzo introduttivo. Quel prezzo è diventato listino standard e l'aumento previsto per il 1° settembre 2026 non ci sarà, quindi anche in batch i numeri restano questi (listino ufficiale, consultato il 2026-08-12).

La contropartita è la latenza: la maggior parte dei batch chiude entro un'ora, il tetto massimo è 24 ore (Batch API, limitazioni, consultato il 2026-08-12). Per un job notturno che classifica mille documenti è un affare. Per una risposta in chat non esiste.

Lo sconto batch e i moltiplicatori del caching si sommano. Un batch notturno su contesto cachato è il punto più basso raggiungibile del listino.

3) Residenza dati: il moltiplicatore che va in salita

Dai modelli 4.6 in poi puoi forzare l'inferenza su territorio statunitense con il parametro inference_geo: "us". Costa 1,1x su tutte le voci (listino ufficiale, sezione data residency, consultato il 2026-08-12), input, output, scritture e letture di cache. Il default (global) sta a prezzo standard. È l'unico moltiplicatore che alza il conto, e serve solo se hai un vincolo contrattuale sulla residenza dei dati.

Una nota che vale soldi veri: sui modelli 4.6 e successivi il milione di token di contesto è a prezzo standard. Non c'è il premio long-context che qualche concorrente applica oltre una certa soglia. Una richiesta da 900.000 token si paga alla stessa tariffa per token di una da 9.000.

Quali limiti trovi davvero in produzione?

I limiti sono di due tipi e vanno letti insieme, perché quello che ti blocca per primo raramente è quello che ti aspetti.

Tetti di spesa per tier

Ogni organizzazione sta su un tier, assegnato in automatico in base allo storico di utilizzo. Ogni tier ha un tetto di spesa mensile: superato quello, l'API si ferma fino al mese successivo, a meno che tu non chieda un limite più alto dalla pagina Limits della console (tetti di spesa per tier, consultato il 2026-08-12).

• Start: 500 dollari al mese
• Build: 1.000 dollari al mese
• Scale: 200.000 dollari al mese
• Custom: nessun tetto, si concorda con il team commerciale

Puoi impostarti un tetto più basso di quello del tuo tier dalla pagina Limits della console, e per chi automatizza da solo è la prima cosa da fare: il tetto del tier è dimensionato su un'azienda, non su un sistema personale.

Rate limit: richieste e token al minuto

I limiti di frequenza si misurano su tre assi: richieste al minuto (RPM), token di input al minuto (ITPM), token di output al minuto (OTPM). Sono per modello, quindi modelli diversi girano in parallelo sui rispettivi limiti.

Su tier Start, per Claude Opus 5: 1.000 RPM, 2 milioni ITPM, 400.000 OTPM (rate limit per tier, consultato il 2026-08-12). Su Build salgono a 5.000 RPM, 5 milioni ITPM, 1 milione OTPM. Su Scale a 10.000 RPM, 10 milioni ITPM, 2 milioni OTPM. Sonnet 5 e Haiku 4.5 hanno gli stessi valori.

Fable 5 è più stretto, ed è giusto sapere perché prima di progettarci sopra: su Start sta a 1.000 RPM, 500.000 ITPM e 100.000 OTPM, cioè un quarto dell'input di Opus 5.

Due dettagli che cambiano il modo di progettare il sistema:

• Opus 5 ha un bucket separato dagli Opus 4.x. Il limite Opus 4.8 + 4.7 + 4.6 + 4.5 è cumulato tra loro, Opus 5 no. Spostare traffico da 4.8 a 5 non libera capacità sul vecchio bucket e non eredita la sua.
• I token letti da cache non contano nell'ITPM. Contano input_tokens e cache_creation_input_tokens, non cache_read_input_tokens. Con un limite da 2 milioni ITPM e l'80% di cache hit passi 10 milioni di token di input effettivi al minuto: è l'esempio che fa la documentazione (rate limit, sezione cache-aware ITPM, consultato il 2026-08-12). Il caching lavora quindi su due fronti insieme: taglia la spesa e alza il throughput.

Context window, output e il conto dei token

Context window a 1M token su Fable 5, Opus 5, Sonnet 5 e tutta la generazione 4.6+. Haiku 4.5 resta a 200K. Output massimo 128K token sulla Messages API sincrona, 64K su Haiku. Sulla Batch API i modelli Opus 5, 4.8, 4.7, 4.6, Sonnet 5 e 4.6 arrivano a 300K token di output con l'header beta output-300k-2026-03-24 (tabella modelli, consultato il 2026-08-24).

Poi c'è la trappola che coglie tutti di sorpresa: dai modelli 4.7 in poi il tokenizer è cambiato, e lo stesso testo produce circa il 30% di token in più (conteggio dei token, consultato il 2026-08-12). Il prezzo per token è quello che leggi in listino, ma i token sono di più. Se stai migrando da Sonnet 4.6 e hai tarato max_tokens e le soglie di compattazione sulla vecchia misura, ti aspetta un troncamento a metà risposta e una bolletta più alta a parità di lavoro. Non stimare con librerie di terze parti tarate su altri modelli: rimisura con l'endpoint count_tokens puntato al modello di destinazione.

Come si inizia: dalla console al primo script in dieci minuti

Il setup è più corto di quanto sembri. Quattro passaggi.

1) Account e crediti. Vai sulla console Anthropic e registrati. I nuovi account ricevono una quota di crediti gratuiti per fare i primi test. L'importo esatto non è più pubblicato: il saldo lo vedi in console, guardalo prima di pianificare i test.

2) Genera la API key dalla sezione API Keys. Copiala subito, non la rivedi più. Poi mettila in una variabile d'ambiente, non nel codice:

export ANTHROPIC_API_KEY="sk-ant-..."

Se la scrivi in un file .env, dagli chmod 600 e mettilo in .gitignore prima di fare qualsiasi commit. Una chiave finita su GitHub viene trovata dagli scanner automatici in pochi minuti.

3) Installa l'SDK e fai la prima chiamata.

pip install anthropic

import anthropic

client = anthropic.Anthropic()  # legge ANTHROPIC_API_KEY dall'ambiente

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "Riassumi in tre punti cosa fa questo testo: ..."}
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(response.usage)  # input_tokens, output_tokens, cache_read_input_tokens

Due cose da notare. response.content è una lista di blocchi tipizzati, non una stringa: se accedi a content[0].text senza controllare block.type prima o poi ti esplode, perché il primo blocco può essere di ragionamento e non di testo. E response.usage è il posto dove leggere quanto hai speso davvero, chiamata per chiamata.

Per scendere di costo cambi una riga: claude-sonnet-5 per il grosso dei carichi, claude-haiku-4-5 per classificazione ed estrazione.

4) Attiva il caching appena il prompt si stabilizza. Il breakpoint va messo a mano, sull'ultimo blocco stabile:

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": CONTESTO_STABILE,
            "cache_control": {"type": "ephemeral"},  # breakpoint sull'ultimo blocco stabile
        }
    ],
    messages=[{"role": "user", "content": domanda_variabile}],
)

Mettere il contesto stabile prima e la parte variabile dopo è la precondizione, non la soluzione. Quello che decide davvero è dove cade il breakpoint. Se lo piazzi su un blocco che cambia a ogni richiesta (il messaggio dell'utente, un blocco con dentro un timestamp) paghi una scrittura in cache nuova ogni volta e non ottieni mai una lettura: la documentazione ufficiale lo elenca fra gli errori tipici. È esattamente quello che fa il cache_control passato come parametro top-level di messages.create(), che marca in automatico l'ultimo blocco utile, cioè quasi sempre la domanda variabile.

Il secondo motivo per cui la gente vede cache_read_input_tokens a zero è la soglia minima. Su Opus 5 il prefisso deve arrivare a 512 token per essere cachabile: sotto quella soglia la richiesta viene processata senza cache e non ricevi nessun errore. La soglia cambia da modello a modello e non è monotona tra le generazioni, quindi verificala per il modello che usi davvero.

Tre parametri che sui modelli nuovi danno errore

Se copi codice scritto per i modelli vecchi, questi tre ti restituiscono un 400 su Opus 5, Sonnet 5 e Fable 5:

• temperature, top_p, top_k sono stati rimossi. Il comportamento si guida dal prompt.
• thinking: {"type": "enabled", "budget_tokens": N} non esiste più. Il ragionamento è adattivo, e la profondità si regola con output_config: {"effort": "..."} su cinque livelli, da low a max.
• Il prefill dell'ultimo turno assistant è rifiutato. Per vincolare il formato dell'output si usa output_config.format con uno schema JSON.

Su Opus 5 c'è una cosa in più da sapere: il ragionamento è attivo per default, anche se non passi il parametro thinking. E max_tokens è un tetto su ragionamento più testo insieme. Se arrivi da un modello dove il ragionamento era spento e avevi tarato max_tokens stretto intorno alla risposta, ora la risposta ti si tronca. Alza il tetto.

API o abbonamento Claude: quando conviene cosa

Sono due prodotti diversi che risolvono problemi diversi, e la scelta non è un aut-aut. Io uso entrambi.

L'abbonamento (Pro o Max) conviene quando:

• lavori in modo interattivo, sessioni di ragionamento, scrittura, analisi di documenti
• usi Claude Cowork o Claude Code sul tuo Mac, dove il valore sta nell'agente che lavora sui tuoi file
• la spesa è prevedibile e ti serve un tetto mensile certo, non una voce a consumo

L'API conviene quando:

• il task gira senza che tu sia davanti allo schermo (cron, webhook, job schedulati)
• devi integrare Claude dentro un'applicazione tua, un actor, una pipeline
• ti serve controllo fine su modello, caching, batch, tool
• il volume è alto e ripetitivo, cioè esattamente lo scenario in cui caching e batch fanno la differenza

Il confronto dei piani in abbonamento sta in un altro pezzo: prezzi e piani di Claude Pro e Max. Qui basta la regola pratica: se il lavoro lo fai tu davanti a Claude, paghi l'abbonamento. Se il lavoro lo fa un processo mentre dormi, paghi l'API.

C'è un caso ibrido che vale la pena nominare, perché è quello in cui mi sono ritrovato. I task schedulati che girano in locale su un agente desktop non consumano API: pesano sull'abbonamento. Quelli che girano in cloud, sì. Sapere quale metà del tuo sistema sta da che parte è il primo passo per capire la bolletta, e l'ho raccontato nel dettaglio nel caso studio sulle 21 automazioni tra cron locale e cloud.

I miei numeri: cosa spendo davvero

Il sistema è in produzione da metà febbraio 2026 e oggi conta 35 automazioni tra generazione contenuti, monitoraggio SEO, engagement LinkedIn, outreach, report. La spesa API, ordine di grandezza: sta sotto i 50 euro al mese. Non pubblico una media al centesimo perché non tengo una contabilità separata per progetto: è quello che leggo in console, non una voce di bilancio.

Come si distribuisce, in ordine di peso:

• Generazione contenuti long-form. La voce più pesante. Output lungo, modello di fascia alta, poco margine di compressione. È l'unico posto dove il costo per esecuzione supera il mezzo euro.
• Monitoraggio e audit SEO. Contesto grosso e stabile, output corto. È il caso da manuale per il caching: stesso schema di analisi a ogni ciclo, cambia solo il dato in coda.
• Classificazione e triage. Volume alto, task semplice, Haiku. Costa in spiccioli e non merita nemmeno una riga di ottimizzazione.
• Orchestrazione e gate di controllo. Chiamate piccole ma frequenti. Contano più per il rate limit che per la bolletta.

La lezione che porto a casa da metà febbraio: il collo di bottiglia è la disciplina sul contesto, prima ancora del prezzo per token. Le due volte in cui la spesa mensile è salita sensibilmente non è stato per un modello più caro. È stato perché un prompt aveva iniziato a trascinarsi dietro contesto che non serviva, e nessuno se n'era accorto perché il risultato continuava a essere corretto. Un output giusto ma pagato tre volte tanto non fa scattare nessun controllo automatico, quindi l'unico modo per vederlo è leggere response.usage task per task.

Se cerchi il quadro completo di cosa fa il sistema e come è cucito insieme, l'ho scritto nella guida completa a Claude AI, e la parte di sviluppo assistito sta nella guida a Claude Code.

Cinque errori che gonfiano la bolletta

Li ho fatti quasi tutti, quindi non sono ipotesi.

1) Non guardare mai `response.usage`. È il contatore che hai in mano a ogni chiamata. Se non lo logghi, il primo segnale di un problema è la fattura. Loggalo per task, non in aggregato.

2) Contesto che cresce e non viene mai potato. Nei loop agentici la storia si accumula, e ogni turno la ripaghi tutta. Le opzioni sono il context editing, che ripulisce i risultati di tool vecchi, e la compattazione, che li riassume. Ignorarle è la causa numero uno di bollette che salgono senza che cambi nulla nel codice.

3) `max_tokens` messo a caso. Non paghi il tetto, paghi i token generati davvero: alzarlo non costa nulla. Ma se lo metti troppo basso la risposta si tronca e la rifai da capo, e quella sì che la paghi due volte. Il valore ragionevole è 16.000 senza streaming e 64.000 con streaming.

4) Modello di fascia alta per task da fascia bassa. Estrarre un campo da un JSON con Opus costa cinque volte lo stesso lavoro fatto con Haiku, a parità di risultato. Il criterio giusto è quale sia il modello più economico che passa il tuo test di accettazione.

5) Nessun tetto di spesa impostato. Il tier Start ne ha uno a 500 dollari (tetti di spesa per tier, consultato il 2026-08-12), ma è comunque un ordine di grandezza sopra quello che serve a un sistema personale. Mettine uno tuo, coerente con quello che ti aspetti di spendere. Costa trenta secondi e ti salva da un loop impazzito.

Domande frequenti

L'API di Claude è gratuita?

No, si paga a consumo sui token consumati. Non c'è un abbonamento fisso: se non chiami, non paghi. I nuovi account ricevono una quota di crediti gratuiti per i primi test, di importo non pubblicato: lo controlli nella console. Ci sono due voci che restano gratuite dentro l'API: il web fetch non ha costi oltre ai token del contenuto recuperato, e il code execution ha una quota mensile di ore incluse per organizzazione, oltre la quale si paga 0,05 dollari l'ora per container. Il web search invece si paga a parte, 10 dollari ogni 1.000 ricerche (listino ufficiale, sezione tool, consultato il 2026-08-12).

Quale modello Claude scegliere per l'API?

Regola pratica in tre righe: Haiku 4.5 per classificazione, estrazione ed etichettatura, dove il task è definito e il volume è alto. Sonnet 5 per la maggior parte dei carichi di produzione, è il punto di equilibrio tra costo e capacità. Opus 5 per lavoro agentico complesso, codice su più file, ragionamento lungo. Fable 5 solo quando serve il massimo disponibile e il costo passa in secondo piano. Il modo giusto di decidere è scrivere prima il test di accettazione, partire dal modello più economico e salire solo quando fallisce.

Quanto costa un milione di token con Claude?

Sull'input: 1 dollaro con Haiku 4.5, 2 con Sonnet 5, 5 con Opus 5, 10 con Fable 5 (listino ufficiale, consultato il 2026-08-12). L'output costa cinque volte l'input su ogni modello.

Il context window da 1 milione di token costa di più?

No. Dai modelli 4.6 in poi l'intera finestra è a tariffa standard, senza premio long-context oltre una soglia. L'unico moltiplicatore in salita resta la residenza dati statunitense, a 1,1x (listino ufficiale, sezione data residency, consultato il 2026-08-12).

Come faccio a sapere quanto sto spendendo prima di lanciare?

Con client.messages.count_tokens(), che conta i token di una richiesta senza eseguirla. Moltiplichi per la tariffa del modello e hai la stima. Conta i token con il modello di destinazione, non con librerie di altri fornitori: i tokenizer sono diversi, e dai modelli 4.7 in poi lo stesso testo produce circa il 30% di token in più rispetto alla generazione precedente (conteggio dei token, consultato il 2026-08-12).

Per i valori aggiornati consulta sempre le fonti ufficiali: listino Anthropic, rate limit per tier e panoramica dei modelli. Prima verifica il 27 luglio 2026, prezzi e limiti riverificati alla fonte il 12 agosto 2026.

Risorse correlate

Per l'agente desktop e i task che girano in locale senza consumare API, la guida a Claude Cowork.