Token di input e output: perché Claude costa di più

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

I token di output costano cinque volte più dei token di input per ogni modello Claude attualmente disponibile nel catalogo. La causa è il tipo di calcolo richiesto. 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.

Il rapporto è uguale in ogni riga del listino prezzi, quindi il modello scelto non modifica la quota della fattura dovuta all'output. È la struttura del carico di lavoro a determinarla. 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 ne genera 12,000 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 volta. Ogni token del prompt entra nella rete nello stesso forward pass, quindi il lavoro di attention e feed-forward diventa un numero ridotto di moltiplicazioni di matrici di grandi dimensioni, ciascuna delle quali copre migliaia di token. Una sola lettura dei pesi del modello dalla memoria è sufficiente per l'intero prompt. Le unità di calcolo matriciale dell'acceleratore rimangono impegnate. Per questo il prefill è vincolato dal 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 per il 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 alta larghezza di banda per produrre un solo token. Per questo il decoding è vincolato dalla memoria: il limite è la velocità con cui è possibile trasferire i pesi, non la velocità con cui è possibile moltiplicarli. Lo stesso traffico dei pesi che durante il prefill consuma un intero prompt produce un solo token durante il decoding.

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

Tutto questo non fornisce un valore esatto e non bisogna interpretare 5x come un rapporto hardware misurato. È un prezzo stabilito da Anthropic e determinato tenendo conto di questa asimmetria. Quello che si può verificare direttamente è la direzione della differenza, e richiede circa un minuto.

Misura in autonomia la latenza di input e 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 il numero di secondi trascorsi dall'avvio del comando. In quell'output è utile osservare due valori. 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 è più lungo 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 elaborare solo pochi token. Sono entrate decine di migliaia di token e il tempo è aumentato appena. Ne sono usciti alcune centinaia e l'orologio ha continuato a scorrere per tutta la durata dell'elaborazione.

Ogni risposta non in streaming termina con i numeri usati 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 ragionamento esteso, quindi un modello che ragiona prima di rispondere addebita anche questi token alla tariffa di 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 addebitate.

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 applica una tariffa di $1 per l’input e $5 per l’output. Opus 5 applica $5 per l’input e $25 per l’output. Fable 5, il modello più costoso, applica $10 per l’input e $50 per l’output; vale la pena leggere cosa si ottiene con queste tariffe di Fable 5 prima di scartare la prima riga. Salendo nella fascia di prezzo, entrambi i valori vengono moltiplicati per lo stesso fattore. Il costo totale cambia, ma la ripartizione tra input e output resta invariata.

Sonnet 5 compare due volte perché la tariffa introduttiva scade. Fino al 31 agosto 2026 applica $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, ovvero il 50% in più per entrambi. Tutti gli esempi riportati 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 cambia il prezzo.

C’è una precisazione che il listino non mostra. La documentazione di Anthropic afferma 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 artificialmente quello più recente, perché lo stesso documento produce più token su quel modello. Il confronto corretto è il costo per attività completata; inoltre, conta i prompt reali usando il modello che intendi effettivamente adottare. Lo stesso problema esiste tra provider diversi, i cui tokenizer possono differire ancora di più. Per questo calcolare il costo di un’attività reale su Claude e ChatGPT è più utile che mettere semplicemente a confronto i due listini. quanto valgono nella pratica un milione di token Claude spiega che cosa rappresenta questo volume di testo.

Quando l'output inizia a incidere soprattutto sui costi?

Con l'output prezzato a 5 volte l'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è con un rapporto di 5 token di input per 1 token di output.

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'unico intervento che vale la pena eseguire. Con un rapporto di 5 a 1, le due componenti hanno lo stesso peso. Con un rapporto di 1 a 6, l'output rappresenta il 96.8% e il prompt incide per un arrotondamento trascurabile. La maggior parte delle persone stima male il proprio rapporto, quindi ricavalo dai log prima di ottimizzare qualsiasi cosa.

Un carico di lavoro per un agente: molto contesto in ingresso, risposta breve in uscita

Esegui un passaggio di un agente di retrieval: 60,000 token di documenti recuperati e cronologia della conversazione in ingresso, con una risposta di 800 token. Il rapporto è di 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% 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 di questi passaggi al giorno su Opus 5 costano $64 al giorno.

Dopo aver visto la suddivisione, il principale margine di intervento è evidente. Ridurre la risposta da 800 token a 400 fa 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 dati è quasi uno spreco di lavoro. dove finiscono realmente i token di un agente di coding illustra che cosa riempie il prompt.

Un’attività 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 di Haiku 4.5. Questa differenza di cinque volte dipende quasi interamente dall’output, che è esattamente la parte in cui un modello più economico consente il maggiore risparmio.

L’ultima colonna mostra lo stesso lavoro tramite Batch API, che riduce del 50% 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 resta in attesa del risultato.

Il routing tra modelli è vantaggioso in questo caso, ma non lo è mai nella fase dell’agente. Se la parte più verbosa dell’attività è meccanica, come riformattare testo o ampliare una scaletta già approvata, il modello economico genera quei token a un quinto del prezzo. scegliere tra Opus, Sonnet e Haiku spiega dove si colloca effettivamente il limite di qualità.

La cache sconta l'input, e solo l'input

La cache del prompt memorizza 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 voce presente nella cache.

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

Considera 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
  }
]

Il costo della chiamata scende da $0.32 a $0.0725. La voce dell'output non cambia: $0.02 prima e $0.02 dopo. La cache riduce la fattura e ne modifica la composizione. L'output rappresentava il 6.25% di quella chiamata. Ora supera un quarto del totale, quindi cambia anche quale leva conviene utilizzare per prima.

La prima chiamata sostiene il costo di scrittura. La scrittura di una cache di 5 minuti costa 1.25x la tariffa di input di base, quindi si ripaga dopo una sola lettura successiva. Una scrittura di 1 ora costa 2x e richiede quindi due letture successive per ripagarsi. i moltiplicatori di scrittura e lettura e i casi in cui la cache non conviene più illustra questi calcoli.

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 verbosi verso un modello meno costoso.
3. Esegui in batch tutto ciò per cui nessuno è in attesa.
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 non il limite massimo. Un limite generoso elimina soltanto il vincolo su una risposta che prende una direzione errata. Ricava dai log la distribuzione di output_tokens, imposta il limite poco sopra il 95° percentile e gestisci stop_reason: "max_tokens" nel codice continuando la risposta o riprovando. Una troncatura rilevata costa meno di una risposta prolissa da 4.000 token che paghi e poi scarti. Anche il ragionamento esteso rientra in output_tokens, quindi imposta il relativo budget sulla base degli stessi dati.

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

L'elaborazione in batch è l'unica leva che riduce il costo dell'output. Offre uno sconto del 50% su entrambi i lati, restituisce i risultati entro 24 ore e si applica a qualsiasi attività pianificata.

L'ultima leva è quella che molti trascurano. Espressioni come "sii esaustivo" 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 introduzione". Un prompt di sistema che aggiunge 300 token a ogni risposta costa cinque volte tanto rispetto agli stessi 300 token aggiunti al prompt. tenere sotto controllo i costi di un agente in esecuzione continua tratta l'aspetto del monitoraggio, mentre stabilire se l'API o un abbonamento a costo fisso è più conveniente per il tuo utilizzo è una decisione da prendere prima di passare una settimana a ottimizzare una spesa per token che un abbonamento avrebbe assorbito. Per un singolo sviluppatore, la questione dipende soprattutto dal fatto che Claude Pro, con i suoi $20 al mese e i limiti di utilizzo previsti copra il lavoro che altrimenti dovresti conteggiare a consumo. Se raggiungi già questi limiti durante la sessione, viene prima capire quale finestra temporale stai aspettando: da lì, la soluzione 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 inferiore 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 e non l'API a consumo, i due livelli di abbonamento con i prezzi affiancati mostra quale risulta più conveniente per il lavoro di sviluppo. Se la domanda riguarda un team e non un singolo sviluppatore, considera che Claude Enterprise abbina un costo per postazione ai token conteggiati secondo queste stesse tariffe 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 sull'acceleratore per token. Il prompt viene elaborato in un'unica passata forward sull'intero contenuto, quindi una singola lettura dei pesi del modello copre migliaia di token e l'hardware è limitato dal throughput delle moltiplicazioni. Una risposta viene 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 un prezzo dell'output pari a cinque volte quello dell'input in tutto il catalogo attuale, da Haiku 4.5 fino a Fable 5.

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

No. Il prompt caching si applica soltanto all'input. Ad agosto 2026, una lettura dalla cache costa 0.1x della tariffa base dell'input. Le scritture nella cache costano 1.25x per la durata di 5 minuti oppure 2x per la durata di 1 ora. L'output viene fatturato alla tariffa completa a ogni chiamata, indipendentemente dal comportamento della cache. Per questo il caching modifica sia la struttura sia l'importo della fattura: quando il costo dell'input si riduce drasticamente, l'output diventa la componente su cui intervenire.

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

No. Paghi i token effettivamente prodotti dal modello, quindi max_tokens è un limite massimo e non una quantità prenotata. Resta comunque importante, perché è l'unico limite rigido per una risposta che continua a crescere senza controllo. Impostalo poco sopra il 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 trovare il mio rapporto tra token di input e token 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 calcolati su una settimana. Oltre 5 token di input per 1 token di output, il costo principale è nel prompt: memorizza nella cache la parte stabile e riduci il resto. Al di sotto di questo rapporto, il costo principale è nella risposta: limita la sua lunghezza e sposta verso un modello più economico o verso la Batch API i passaggi che ne generano la maggior parte.