Token input e output Claude: dove nasce la differenza

Perché i token di output costano più dei token di input

I token di output costano cinque volte i token di input su tutti i modelli Claude presenti nel catalogo attuale. La causa dipende dal tipo di calcolo. La lettura di un prompt richiede un solo passaggio sul modello. La generazione di una risposta richiede un passaggio per ogni token, e ogni passaggio deve attendere il completamento di quello precedente.

Questo rapporto è uguale in ogni riga del listino prezzi, quindi il modello scelto non modifica la quota della fattura attribuibile all'output. A determinarla è la struttura del carico di lavoro. Un passaggio di un agente che legge 60,000 token e risponde con 800 token sostiene costi di output quasi nulli. Un'attività di stesura che legge 2,000 token e genera 12,000 token sostiene costi di input quasi nulli. Di seguito vengono analizzati entrambi i casi usando le tariffe pubblicate da Anthropic per August 2026.

Il prefill viene eseguito una volta, il decoding una volta per token

Un server di inferenza gestisce una richiesta in due fasi con costi molto diversi. Il prefill legge il prompt. Il decoding genera la risposta.

Il prefill elabora l'intero prompt in una sola volta. Tutti i token del prompt entrano nella rete nello stesso forward pass, quindi le operazioni di attention e feed-forward diventano un numero ridotto di grandi moltiplicazioni matriciali che coprono migliaia di token alla volta. Una singola lettura dei pesi del modello dalla memoria è sufficiente per l'intero prompt. Le unità matriciali dell'acceleratore restano impegnate. Per questo il prefill è limitato dalla capacità di calcolo: il limite è la velocità con cui il chip può eseguire le moltiplicazioni.

Il decoding non può funzionare nello stesso modo, perché il token 2 dipende dal token 1. Il token appena generato dal modello diventa parte dell'input del passaggio successivo, quindi i passaggi non possono essere eseguiti contemporaneamente. Ogni token di output richiede un proprio forward pass, e ciascuno di questi passaggi legge l'intero insieme dei pesi del modello dalla memoria ad ampia larghezza di banda per generare un singolo token. Per questo il decoding è limitato dalla memoria: il limite è la velocità con cui i pesi possono essere trasferiti, non la velocità con cui possono essere moltiplicati. Lo stesso traffico dei pesi che durante il prefill elabora un intero prompt produce un solo token durante il decoding.

I sistemi di serving compensano usando il batching. Molte richieste eseguono il decoding insieme, quindi una lettura dei pesi produce un token per ogni richiesta nel batch. È questo che rende il decoding sostenibile. Anche in questo caso il limite è la memoria. Ogni richiesta in corso mantiene una KV cache (key/value cache, lo stato di attention memorizzato per ogni token elaborato finora); la cache cresce a ogni token generato e, quando riempie l'acceleratore, il batch non può più aumentare.

Nessuno di questi elementi fornisce un numero esatto e non bisogna interpretare 5x come un rapporto hardware misurato. È un prezzo stabilito da Anthropic e basato su questa asimmetria. Quello che si può verificare direttamente è la direzione della differenza, e servono circa 1 minuto.

Misura personalmente il tempo di elaborazione dell'input e dell'output

Installa gli strumenti su qualsiasi sistema Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

Ora invia in streaming un prompt breve che richieda una risposta lunga e stampa ogni riga con l'ora di arrivo.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s antepone a ogni riga i secondi trascorsi dall'avvio del comando. Nell'output ci sono due valori importanti. La prima riga content_block_delta indica il tempo al primo token; tutto il prefill è avvenuto al suo interno. Ogni riga successiva corrisponde a un piccolo passaggio di decoding e i valori temporali continuano ad aumentare fino all'arrivo di message_stop.

Ora inverti la situazione. Inserisci un documento lungo nel prompt e limita la risposta a pochi token.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

Il primo intervallo richiede più tempo rispetto a quello del prompt breve, perché il prefill deve leggere molto più testo. Dopo il suo arrivo, la risposta termina quasi subito, perché restano da decodificare soltanto pochi token. Sono entrate decine di migliaia di token, ma il tempo è aumentato appena. Ne sono usciti alcune centinaia e il conteggio è proseguito per tutta la durata dell'operazione.

Ogni risposta non in streaming termina con i numeri utilizzati per la fatturazione.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Registra tutti e quattro i campi per ogni richiesta. output_tokens include il thinking esteso, quindi un modello che elabora il ragionamento prima di rispondere addebita anche questo ragionamento alla tariffa dell'output. Per calcolare il costo di un prompt prima di inviarlo, POST /v1/messages/count_tokens accetta lo stesso corpo della richiesta, restituisce {"input_tokens": N} senza eseguire il modello ed è gratuito. Non è l'unica parte dell'API che non comporta costi; prima di definire il budget per il primo progetto, conviene verificare quali parti dell'API di Claude non vengono mai fatturate.

Quanto costa Claude per milione di token ad agosto 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

L'ultima colonna è il rapporto tra output e input e mostra 5 in ogni riga. Haiku 4.5 fattura $1 per l'input e $5 per l'output. Opus 5 fattura $5 per l'input e $25 per l'output. Fable 5, il modello più costoso, fattura $10 per l'input e $50 per l'output; vale la pena leggere cosa offrono queste tariffe di Fable 5 prima di escludere quella riga. Salendo nella fascia, entrambi i lati vengono moltiplicati per lo stesso fattore. Il totale cambia, ma la suddivisione tra input e output resta esattamente invariata.

Sonnet 5 compare due volte perché la tariffa introduttiva scade. Fino al 31 agosto 2026 fattura $2 per l'input e $10 per l'output. Dal 1 settembre 2026 si applica la tariffa standard di $3 per l'input e $15 per l'output, superiore del 50% su entrambi i lati. Tutti gli esempi svolti di seguito usano la tariffa di agosto.

Le tariffe cambiano e questa pagina non è la fonte da consultare per verificarle. La fonte ufficiale è claude.com/pricing. Il metodo resta valido anche quando cambiano i prezzi.

C'è una precisazione che il listino non mostra. La documentazione di Anthropic indica che i modelli Claude 4.7 e successivi usano un tokenizer più recente, che produce circa il 30% di token in più per lo stesso testo rispetto al tokenizer usato da Sonnet 4.6 e dai modelli precedenti. Confrontare due modelli soltanto in base al prezzo per milione di token favorisce apparentemente quello più recente, perché lo stesso documento contiene più token quando viene elaborato da quel modello. Confrontali in base al costo per attività completata e misura i tuoi prompt reali sul modello che intendi utilizzare. quanto vale in un testo reale un milione di token Claude spiega che cosa rappresenta in pratica questo volume.

Quando l’output inizia a incidere maggiormente sui costi?

Con un output il cui prezzo è 5 volte quello dell’input, il punto di pareggio è facile da calcolare mentalmente. Indichiamo con I i token di input e con O i token di output. Il costo dell’input è I. Il costo dell’output è 5 volte O. L’output supera metà della spesa quando 5 volte O è maggiore di I, cioè quando il rapporto tra input e output è 5 a 1.

Quindi, se il prompt è più di cinque volte più lungo della risposta, l’input rappresenta la voce di costo maggiore. Al di sotto di questo rapporto, prevale l’output.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

Con un rapporto di 100 a 1, l’output rappresenta il 4.8% della spesa e ridurre il prompt è l’unica attività che vale la pena svolgere. Con un rapporto di 5 a 1, i due costi sono equivalenti. Con un rapporto di 1 a 6, l’output rappresenta il 96.8% e il prompt è trascurabile. La maggior parte delle persone stima in modo errato il proprio rapporto, quindi ricavalo dai log prima di ottimizzare qualsiasi cosa.

Un workload per un agente: molto contesto in ingresso, risposta breve in uscita

Consideriamo un singolo passaggio di un agente di retrieval: 60,000 token in ingresso composti dai documenti recuperati e dalla cronologia della conversazione, e una risposta di 800 token. Il rapporto è 75 a 1, un valore normale per qualsiasi sistema che legge prima di scrivere.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

L'output rappresenta il 6.25% del costo di quella chiamata su ogni modello, perché il rapporto è fisso nell'intero listino prezzi. La chiamata costa $0.32 su Opus 5, $0.128 su Sonnet 5 alla tariffa di agosto e $0.064 su Haiku 4.5. Duecento passaggi di questo tipo al giorno su Opus 5 costano $64 al giorno.

Dopo aver visto la suddivisione, il fattore su cui intervenire è evidente. Ridurre la risposta da 800 token a 400 consente di risparmiare circa il 3% del costo della chiamata. Eliminare dal prompt 20,000 token di contesto obsoleto consente di risparmiare circa un terzo del costo. Ridurre la lunghezza dell'output in un agente che legge molti più dati di quanti ne produca è quasi uno spreco di effort. dove finiscono effettivamente i token di un agente di coding analizza innanzitutto che cosa riempie quel prompt.

Un carico di generazione: prompt breve, bozza lunga

Ora invertiamo la proporzione. Un brief di 2,000 token, una bozza di 12,000 token, con un rapporto di 1 a 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

L’output rappresenta il 96.8% di questo costo. Opus 5 costa $0.31 per bozza, contro $0.062 con Haiku 4.5. Questa differenza di cinque volte dipende quasi interamente dall’output, proprio la componente sulla quale un modello più economico consente il maggiore risparmio.

L’ultima colonna mostra lo stesso lavoro tramite Batch API, che dimezza i costi di input e output. Opus 5 scende a $0.155 per bozza. Batch restituisce i risultati entro 24 ore invece che immediatamente, quindi è adatto alla generazione notturna di report e alla classificazione in blocco. Non è adatto alle attività per le quali una persona deve attendere il risultato.

Il routing dei modelli è vantaggioso in questo caso, ma non lo è mai nella fase dell’agente. Se la parte prolissa del lavoro è meccanica, ad esempio riformattare il testo o sviluppare una scaletta già approvata, il modello economico genera quei token a un quinto del prezzo. scegliere tra Opus, Sonnet e Haiku spiega dove si trova effettivamente il limite della qualità.

La memorizzazione nella cache riduce il costo dell'input, e solo dell'input

La memorizzazione nella cache dei prompt conserva un prefisso del prompt sul server e applica una frazione della tariffa di input quando quel prefisso viene letto nuovamente. Ad agosto 2026, i moltiplicatori sono 1.25x la tariffa di input di base per scrivere una cache di 5 minuti, 2x per scrivere una cache di 1 ora e 0.1x per leggere una cache valida.

L'output non rientra in questo meccanismo. Non esiste un output memorizzato nella cache. Ogni token generato dal modello viene addebitato ogni volta alla tariffa di output completa, indipendentemente dalla quantità di prompt restituita dalla cache.

Consideriamo lo stesso passaggio dell'agente su Opus 5, con 55,000 dei 60,000 token di input serviti da una cache già disponibile.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

La chiamata passa da $0.32 a $0.0725. La riga dell'output non cambia: $0.02 prima e $0.02 dopo. La memorizzazione nella cache riduce il costo e ne modifica la composizione. L'output rappresentava il 6.25% di quella chiamata. Ora supera un quarto del totale, quindi cambia quale leva conviene azionare per prima.

La prima chiamata sostiene il costo di scrittura. Una scrittura nella cache di 5 minuti costa 1.25x la tariffa di input di base, quindi si ripaga dopo un solo riutilizzo. Una scrittura nella cache di 1 ora costa 2x, quindi richiede due riutilizzi. i moltiplicatori di scrittura e lettura e quando la memorizzazione nella cache non è più conveniente sviluppa questo calcolo.

Quattro leve sotto il tuo controllo

1. Imposta max_tokens sulla lunghezza p95 delle risposte, non sul limite massimo del modello.
2. Instrada i passaggi più verbosi verso un modello meno costoso.
3. Esegui in batch tutto ciò per cui nessuno sta aspettando una risposta.
4. Elimina le istruzioni che allungano le risposte.

max_tokens è un limite rigido. Impostarlo su un valore alto non ha costi diretti, perché paghi i token prodotti e mai il limite massimo. Un limite generoso fa soltanto venire meno il vincolo su una risposta che procede in modo errato. Ricava la distribuzione di output_tokens dai log, imposta il limite poco sopra il 95° percentile e gestisci stop_reason: "max_tokens" nel codice continuando la risposta oppure eseguendo un nuovo tentativo. Una troncatura rilevata costa meno di un testo prolisso di 4,000 token che devi pagare e poi scartare. Anche il ragionamento esteso rientra in output_tokens, quindi imposta quel budget sulla base degli stessi dati.

Il routing funziona quando la parte costosa di un passaggio è il volume, non la capacità di giudizio. Mantieni il modello più potente per la decisione e assegna la stesura a un modello meno costoso. Prima misura la versione con routing sul tuo set di valutazione, perché un modello economico che richiede due tentativi costa più di un singolo tentativo con un modello costoso.

Il batching è l'unica leva che riduce il costo dell'output. Si applica uno sconto del 50% su entrambi i lati, i risultati arrivano entro 24 ore e sono idonei tutte le attività pianificate.

L'ultima leva è quella che molti trascurano. Espressioni come "sii scrupoloso" e "spiega il tuo ragionamento" aumentano la lunghezza dell'output in ogni chiamata futura. Sostituiscile con il formato desiderato: "Rispondi con al massimo tre frasi" oppure "Restituisci solo l'oggetto JSON, senza preamboli". Un prompt di sistema che aggiunge 300 token a ogni risposta costa cinque volte più degli stessi 300 token aggiunti al prompt. tenere sotto controllo i costi di un agente in esecuzione continua tratta l'aspetto del monitoraggio, mentre conviene stabilire prima se l'API o un abbonamento a prezzo fisso è più conveniente per il tuo modello di utilizzo di dedicare una settimana all'ottimizzazione della spesa per token che un abbonamento avrebbe assorbito. Per un singolo sviluppatore, la questione si riduce soprattutto a stabilire se Claude Pro, con i suoi $20 al mese e i limiti di utilizzo previsti copre il lavoro che altrimenti misureresti a consumo. Se raggiungi già quei limiti durante la sessione, viene prima capire quale finestra di attesa stai incontrando, perché la soluzione successiva può essere un modello più piccolo, un contesto più leggero, crediti di utilizzo aggiuntivi oppure lo spostamento del lavoro sull'API a consumo. Se l'API a consumo si rivela la soluzione più economica per quel lavoro, passare a un piano più piccolo o annullarlo lascia intatto il mese già pagato, quindi il cambio non comporta costi di uscita. Se il piano con cui stai confrontando Pro è quello di ChatGPT, anziché l'API a consumo, i due livelli di abbonamento con i prezzi affiancati mostrano quale risulta più conveniente per il lavoro di sviluppo. Se la domanda riguarda un team anziché un singolo sviluppatore, considera che Claude Enterprise combina un costo per postazione con token conteggiati alle stesse tariffe dell'API, quindi ogni leva descritta in questa pagina continua ad applicarsi alla parte della fattura calcolata a consumo.

FAQ

Perché i token di output costano più dei token di input?

La loro generazione richiede molto più tempo di elaborazione dell'acceleratore per token. Il prompt viene elaborato in un'unica passata forward sull'intero contenuto: una singola lettura dei pesi del modello copre quindi migliaia di token e l'hardware è limitato dalla velocità delle operazioni di moltiplicazione. Una risposta viene invece generata un token alla volta; ogni token richiede una nuova passata forward che rilegge tutti i pesi del modello, quindi l'hardware è limitato dalla larghezza di banda della memoria. Anthropic applica all'output un prezzo pari a cinque volte quello dell'input in tutto il catalogo attuale, da Haiku 4.5 a Fable 5.

Il prompt caching rende più economici i token di output?

No. Il prompt caching si applica solo all'input. Ad agosto 2026, la lettura della cache costa 0.1x della tariffa base dell'input, mentre la scrittura nella cache costa 1.25x per la durata di 5 minuti o 2x per la durata di 1 ora. L'output viene fatturato alla tariffa completa a ogni chiamata, indipendentemente dalle operazioni eseguite dalla cache. Per questo il caching modifica la composizione della fattura oltre al suo importo: quando il costo dell'input diminuisce drasticamente, l'output diventa la quota su cui intervenire.

Un max_tokens elevato mi costa denaro se la risposta è breve?

No. La fatturazione si basa sui token prodotti effettivamente dal modello, quindi max_tokens è un limite massimo e non una quantità prenotata. Rimane comunque importante, perché è l'unico limite rigido per una risposta che si prolunga senza controllo. Impostalo leggermente al di sopra del 95° percentile del tuo output_tokens osservato, quindi gestisci stop_reason: "max_tokens" nel codice invece di distribuire una risposta troncata senza indicarlo.

Come posso calcolare il rapporto tra i miei token di input e di output?

Registra input_tokens, output_tokens, cache_read_input_tokens e cache_creation_input_tokens dall'oggetto usage di ogni risposta, quindi dividi i totali su una settimana. Oltre un rapporto di 5 token di input per 1 di output, il costo è nell'input: memorizza nella cache la parte stabile e riduci il resto. Al di sotto di questo rapporto, il costo è nella risposta: limita la sua lunghezza e sposta i passaggi che ne generano la maggior parte su un modello più economico o sulla Batch API.