Perché i token di output di Claude costano più dell'input

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

I token di output costano cinque volte tanto rispetto ai token di input in ogni modello Claude presente nel catalogo attuale. La causa risiede nella struttura del calcolo. La lettura di un prompt è un singolo passaggio sul modello. La scrittura di una risposta è un passaggio per ogni token, e ogni passaggio deve attendere quello precedente.

Questo rapporto è identico in ogni riga del listino prezzi, quindi il modello scelto non modifica l'incidenza dell'output sulla fattura. È la natura del carico di lavoro a determinarla. Un'operazione di un agente che legge 60,000 token e risponde con 800 spende quasi nulla per l'output. Un lavoro di stesura che legge 2,000 token e ne scrive 12,000 spende quasi nulla per l'input. Entrambi i casi sono analizzati di seguito in base alle tariffe Anthropic pubblicate nell'agosto 2026.

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

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

Il prefill elabora l'intero prompt in una sola volta. Ogni token del prompt entra nella rete nello stesso passaggio in avanti (forward pass), quindi il lavoro di attenzione e feed-forward si traduce in un numero ridotto di grandi moltiplicazioni di matrici che coprono migliaia di token alla volta. Una singola lettura dei pesi del modello dalla memoria serve l'intero prompt. Le unità di calcolo matriciale dell'acceleratore restano occupate, il che significa che il prefill è limitato dalla capacità di calcolo (compute-bound): il limite è la velocità con cui il chip può eseguire le moltiplicazioni.

Il decoding non può funzionare in questo modo, poiché il token 2 dipende dal token 1. Il token appena prodotto dal modello diventa parte dell'input per il passaggio successivo, quindi i passaggi non possono essere eseguiti contemporaneamente. Ogni token di output richiede il proprio passaggio in avanti e ognuno di questi passaggi legge l'intero set di pesi del modello dalla memoria ad alta larghezza di banda per produrre un singolo token. Questo rende il decoding limitato dalla memoria (memory-bound): il limite è la velocità con cui i pesi possono essere trasferiti, non la velocità con cui possono essere moltiplicati. Lo stesso traffico di pesi che ha consumato un intero prompt durante il prefill garantisce un solo token durante il decoding.

I sistemi di serving contrastano questo limite tramite il batching. Molte richieste vengono decodificate insieme, quindi una singola lettura dei pesi produce un token per ogni richiesta nel batch. È per questo motivo che il decoding risulta sostenibile. Il limite massimo è ancora una volta la memoria. Ogni richiesta in corso mantiene una KV cache (cache chiave/valore, lo stato di attenzione memorizzato per ogni token generato finora); tale cache cresce con ogni token prodotto e, quando satura l'acceleratore, il batch non può più aumentare.

Nessuno di questi elementi fornisce un numero esatto e non si dovrebbe interpretare 5x come un rapporto hardware misurato. Si tratta di un prezzo, stabilito da Anthropic, basato su tale asimmetria. Ciò che è possibile verificare autonomamente è la tendenza, e richiede circa un minuto.

Misura autonomamente il gap tra input e output

Installa gli strumenti su qualsiasi macchina Ubuntu:

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

Ora invia un breve prompt che richieda una risposta lunga e aggiungi un timestamp a ogni riga che arriva.

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 aggiunge come prefisso a ogni riga i secondi trascorsi dall'avvio del comando. Due elementi sono rilevanti in questo output. La prima riga content_block_delta indica il tempo necessario per il primo token; l'intero processo di prefill è avvenuto in questo intervallo. Ogni riga successiva rappresenta un singolo passaggio di decodifica e i timestamp 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 delta richiede più tempo rispetto al prompt breve, poiché il prefill deve elaborare una quantità di testo decisamente superiore. Una volta arrivato, la risposta termina quasi immediatamente, dato che rimangono solo pochi token da decodificare. Decine di migliaia di token sono stati elaborati in ingresso con un incremento minimo del tempo, mentre poche centinaia in uscita hanno richiesto l'intero intervallo temporale.

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 ragionamento esteso; pertanto, un modello che riflette prima di rispondere fattura tale attività alla tariffa dell'output. Per calcolare il costo di un prompt prima dell'invio, POST /v1/messages/count_tokens accetta lo stesso corpo della richiesta, restituisce {"input_tokens": N} senza eseguire il modello ed è gratuito.

Tariffe di 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 rappresenta l'output diviso per l'input e riporta 5 per ogni riga. Haiku 4.5 costa $1 in input e $5 in output. Opus 5 costa $5 e $25. Fable 5, il modello più costoso, costa $10 e $50. Salendo di gamma, entrambi i valori vengono moltiplicati per lo stesso fattore; questo modifica il costo totale, ma mantiene invariato il rapporto tra input e output.

Sonnet 5 compare due volte perché la sua tariffa promozionale ha una scadenza. Fino al 31 agosto 2026 costa $2 e $10. Dal 1 settembre 2026 si applica la tariffa standard di $3 e $15, pari a un aumento del 50% su entrambi i fronti. Ogni esempio pratico riportato di seguito utilizza la tariffa di agosto.

Le tariffe variano e questa pagina non è il posto dove verificarle. claude.com/pricing è la fonte ufficiale. Ciò che resta valido dopo una variazione di prezzo è il metodo di calcolo.

Un'avvertenza non presente nel listino prezzi: la documentazione di Anthropic specifica che Claude 4.7 e i modelli successivi utilizzano un tokenizer più recente che genera circa il 30% di token in più a parità di testo rispetto al tokenizer di Sonnet 4.6 e versioni precedenti. Confrontare due modelli basandosi solo sul prezzo per milione di token favorisce erroneamente il modello più recente, poiché lo stesso documento produce un numero maggiore di token. È necessario confrontare il costo per attività completata e calcolare i propri prompt reali sul modello che si intende effettivamente utilizzare. a quanto corrisponde un milione di token Claude in testo reale illustra cosa significhi questo volume nella pratica.

Quando il costo dell'output diventa predominante in fattura?

Con l'output tariffato a 5 volte l'input, il punto di pareggio è facile da calcolare a mente. Definiamo I i token di input e O i token di output. L'input costa I. L'output costa 5 volte O. L'output supera la metà della spesa quando 5 volte O è maggiore di I, il che corrisponde a un rapporto di 5 token di input per 1 di output.

Quindi, se il prompt è più di cinque volte più lungo della risposta, l'input rappresenta la voce di spesa maggiore. Al di sotto di tale soglia, è l'output a prevalere.

[
  {
    "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 l'unica ottimizzazione utile è ridurre il prompt. A 5 a 1 le due componenti si equivalgono. A 1 a 6, l'output è il 96.8% e il prompt è un errore di arrotondamento. La maggior parte degli utenti stima erroneamente il proprio rapporto; pertanto, è necessario estrarre i dati dai log prima di procedere con qualsiasi ottimizzazione.

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

Si consideri un singolo passaggio di un agente di recupero: 60.000 token di input provenienti da documenti recuperati e cronologia della conversazione, e una risposta di 800 token. Si tratta di un rapporto di 75 a 1, valore normale per qualsiasi operazione 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 tale chiamata su ogni modello, poiché 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 equivalgono a 64 $ al giorno.

La leva è evidente una volta osservata la suddivisione. Ridurre la risposta da 800 a 400 token fa risparmiare circa il 3% della chiamata. Rimuovere 20.000 token di contesto obsoleto dal prompt ne fa risparmiare circa un terzo. Limitare la lunghezza dell'output su un agente che esegue molte letture è uno sforzo quasi inutile. dove finiscono realmente i token di un agente di programmazione analizza cosa riempie inizialmente quel prompt.

Carico di lavoro generativo: prompt breve, bozza lunga

Ora invertiamo la struttura. Un brief da 2.000 token, una bozza da 12.000 token, 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 su Haiku 4.5. Questa differenza di cinque volte deriva quasi interamente dal lato dell'output, che è esattamente dove un modello più economico garantisce il risparmio maggiore.

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 di report notturni e alla classificazione di massa. Non è adatto a operazioni che richiedono un'attesa attiva da parte dell'utente.

Il routing dei modelli è vantaggioso in questo caso in un modo che non accade mai durante la fase dell'agente. Se la parte prolissa del lavoro è meccanica, come la riformattazione di testo o l'espansione di una scaletta già approvata, il modello economico produce quei token a un quinto del prezzo. scegliere tra Opus, Sonnet e Haiku descrive dove si colloca realmente la soglia di qualità.

Sconti del caching sull'input, e solo sull'input

Il prompt caching memorizza un prefisso del prompt sul server e addebita una frazione della tariffa di input per rileggerlo. A partire da agosto 2026, i moltiplicatori sono 1,25x la tariffa base di input per scrivere una cache di 5 minuti, 2x per scrivere una cache di 1 ora e 0,1x per leggere un hit.

L'output non rientra in questo accordo. Non esiste output memorizzato nella cache. Ogni token scritto dal modello viene fatturato alla tariffa di output piena, ogni volta, indipendentemente da quanto del prompt sia stato recuperato come hit della cache.

Consideriamo lo stesso passaggio di un agente su Opus 5, con 55.000 dei 60.000 token di input serviti da una cache attiva.

[
  {
    "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 riga dell'output non cambia: $0.02 prima, $0.02 dopo. Il caching riduce la fattura e ne modifica la composizione. L'output rappresentava il 6.25% di quella chiamata. Ora ne rappresenta più di un quarto, il che cambia quale leva conviene azionare successivamente.

La prima chiamata paga la scrittura. Una scrittura in cache di 5 minuti costa 1,25x l'input base, quindi si ripaga dopo un singolo hit. Una scrittura di 1 ora costa 2x, quindi ne richiede due. i moltiplicatori di scrittura e lettura, e dove il caching smette di essere conveniente analizza questi calcoli nel dettaglio.

Quattro leve sotto il tuo controllo

1. Imposta max_tokens sulla lunghezza di output del p95, non sul massimo del modello.
2. Instrada i passaggi prolissi verso un modello più economico.
3. Elabora in batch tutto ciò che non richiede una risposta immediata.
4. Elimina le istruzioni che gonfiano le risposte.

max_tokens è un limite massimo rigido; impostarlo su un valore elevato non comporta costi di per sé, poiché la fatturazione avviene sui token prodotti e mai sul limite impostato. Un tetto generoso serve a rimuovere il limite su una risposta che presenta anomalie. Estrai la distribuzione output_tokens dai tuoi log, imposta il limite poco sopra il 95° percentile e gestisci stop_reason: "max_tokens" nel codice, continuando la risposta o effettuando un nuovo tentativo. Un troncamento rilevato costa meno di un blocco di 4.000 token inutili che paghi e scarti. Anche il ragionamento esteso finisce in output_tokens, quindi imposta quel budget basandoti sulle stesse evidenze.

L'instradamento è efficace quando la parte costosa di un passaggio è il volume piuttosto che il giudizio. Mantieni il modello avanzato per la decisione e delega la scrittura a qualcosa di più economico. Valuta prima la versione instradata sul tuo set di test, poiché 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 offre sconti sull'output. Si ottiene il 50% di sconto su entrambi i fronti, con risultati entro 24 ore; qualsiasi operazione pianificata è idonea.

L'ultima leva è quella che viene spesso ignorata. Frasi come "sii esaustivo" e "spiega il tuo ragionamento" determinano la lunghezza dell'output in ogni chiamata effettuata. Sostituiscile con la forma desiderata: "Rispondi in 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 quanto costerebbero gli stessi 300 token nel prompt. mantenere sotto controllo i costi di un agente in esecuzione copre l'aspetto del monitoraggio, mentre se sia più conveniente l'API o un abbonamento flat per il tuo modello di utilizzo è una valutazione da fare prima di dedicare una settimana a ottimizzare la spesa per singolo token, che un abbonamento avrebbe invece assorbito.

FAQ

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

La loro generazione richiede molto più tempo di calcolo sull'acceleratore per ogni token. Un prompt viene elaborato in un unico passaggio in avanti (forward pass) sull'intero contenuto; una singola lettura dei pesi del modello copre migliaia di token e l'hardware è limitato dal throughput delle moltiplicazioni. Una risposta viene prodotta un token alla volta, e ogni token richiede il proprio passaggio in avanti che rilegge l'intero set di pesi del modello; di conseguenza, l'hardware è limitato dalla larghezza di banda della memoria. Anthropic prezza l'output a cinque volte l'input in tutto il catalogo attuale, da Haiku 4.5 fino a Fable 5.

La cache dei prompt rende i token di output più economici?

No. La cache dei prompt si applica solo all'input. Ad agosto 2026, una lettura dalla cache costa 0.1x la tariffa base di input, mentre le scritture in cache costano 1.25x per la durata di 5 minuti o 2x per la durata di 1 ora. L'output viene fatturato alla tariffa piena a ogni chiamata, indipendentemente dall'azione della cache. Ecco perché la cache modifica sia la struttura che l'entità della fattura: una volta che la parte relativa all'input si riduce, l'output diventa la quota su cui è necessario intervenire.

Un valore elevato di max_tokens comporta costi aggiuntivi se la risposta è breve?

No. La fatturazione avviene in base ai token effettivamente prodotti dal modello, quindi max_tokens rappresenta un tetto massimo e non una prenotazione. Rimane comunque importante, poiché è l'unico limite rigido per una risposta che rischia di diventare troppo lunga. Impostalo leggermente al di sopra del 95° percentile del tuo output_tokens osservato, quindi gestisci stop_reason: "max_tokens" nel codice invece di fornire una risposta troncata silenziosamente.

Come posso determinare il mio rapporto tra 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 base settimanale. Con un rapporto superiore a 5 token di input per 1 di output, la spesa è concentrata nel prompt: memorizza nella cache la parte stabile e riduci il resto. Al di sotto di tale soglia, la spesa è concentrata 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.