Il costo di una chiamata non è il costo di un’attività
Un’integrazione può mostrare una sola richiesta dell’utente e, nonostante questo, inviare a Claude diverse richieste prima di completare il lavoro. Il modello può proporre di usare uno strumento; l’applicazione esegue l’operazione e ne restituisce il risultato; poi il modello elabora nuovamente il contesto e decide se rispondere oppure se ha bisogno di un altro strumento. Per stimare la spesa dell’attività occorre conteggiare ogni richiesta al modello, non soltanto quella iniziale o la risposta finale.
Questa guida propone un foglio di calcolo per Claude Sonnet 4.5. Tiene distinti i token di input, quelli di output e gli eventuali costi degli strumenti ospitati sul server. Non include la cache né la Batch API. Inoltre, non presume che tutte le attività abbiano lo stesso numero di round: una ricerca semplice, un flusso in più passaggi e un tentativo non riuscito possono avere costi diversi.
Il calcolo riguarda l’uso della Claude API e un flusso circoscritto in cui l’applicazione esegue gli strumenti. Non va trasferito automaticamente a Bedrock, Google Cloud o altre piattaforme: possono essere diversi gli identificatori, le tariffe, le unità di fatturazione o i calendari. Per la guida ai prezzi, consulta la route interna pricing.index; per il modello, Claude Sonnet 4.5; per il fornitore, Anthropic.
Definisci modello, canale e identificatore prima di stimare
Il nome commerciale non basta per riprodurre un calcolo. Per la Claude API, la documentazione degli identificatori distingue l’alias claude-sonnet-4-5 dalla versione con data claude-sonnet-4-5-20250929. La pagina sul ciclo di vita fornita identifica questa versione come attiva e indica che il suo ritiro non avverrà prima del 29 settembre 2026. È un riferimento utile, non una garanzia di disponibilità futura: verifica lo stato poco prima di pubblicare o riutilizzare il foglio.
Registra anche il canale. Le pagine di Anthropic descrivono identificatori equivalenti per altri fornitori, ma non bisogna presumere che lo stesso prezzo, calendario o formato di utilizzo valga per tutti. La tariffa inserita nel foglio deve corrispondere al canale effettivo e alla data dell’esecuzione. La documentazione dei prezzi è il riferimento per controllare le tariffe aggiornate, le eventuali differenze regionali e le condizioni delle piattaforme associate.
Il materiale di verifica fornito non include gli importi attuali delle tariffe di input e output né il valore delle differenze regionali: perciò qui non vengono presentati come dati confermati. Il modello lascia questi prezzi come campi modificabili. Prima di usare il risultato per un budget, sostituiscili con i valori indicati dalla documentazione applicabile e annota la data in cui li hai verificati.
Dati di controllo per il foglio
Compila queste celle con le informazioni dell’esecuzione e della tariffa corrente. Non riutilizzare il foglio se sono cambiati modello, canale o tariffa senza aggiornare i campi.
| Campo | Che cosa registrare | Perché è importante |
|---|---|---|
| Modello e identificatore | Alias o versione con data effettivamente inviato | Permette di riprodurre il risultato e individuare i cambi di versione |
| Canale | Claude API o un’altra piattaforma | Evita di applicare a un fornitore tariffe o condizioni di un altro |
| Data della tariffa | Giorno in cui sono stati verificati i prezzi | Indica quando è necessario aggiornare il calcolo |
| Prezzi di input e output | Tariffa per unità pubblicata per quel canale | Sono i moltiplicatori del consumo di token |
| Strumenti ospitati | Operazioni fatturabili e relativa unità di addebito | Possono generare costi distinti da quelli dei token |
Conteggia un round completo del ciclo con strumenti
Nell’uso degli strumenti lato client, una risposta del modello può contenere una richiesta di utilizzo di uno strumento. L’applicazione esegue l’azione e invia il risultato dello strumento in un messaggio successivo; a quel punto il modello elabora la continuazione. Lo scambio può ripetersi. Il messaggio che richiede lo strumento non equivale a un’attività completata.
Per ogni richiesta al modello, conteggia l’input effettivamente inviato in quella richiesta. Può includere il messaggio di sistema, i messaggi precedenti, le definizioni degli strumenti, il messaggio dell’utente e i risultati precedenti che l’applicazione ha mantenuto nel contesto. Se una nuova richiesta include di nuovo contenuti precedenti, quei contenuti rientrano nel calcolo dell’input per quella richiesta. Non conteggiare il risultato dello strumento come input del modello finché non lo invii davvero.
Anche l’output viene conteggiato per richiesta. In un round intermedio può consistere in un’istruzione per lo strumento e nei relativi argomenti; nell’ultimo può essere una risposta destinata all’utente. Non presumere che un output intermedio non abbia costi. Per Claude Sonnet 4.5, l’uso degli strumenti può aggiungere token di sistema associati allo strumento selezionato. Il numero dipende dalla configurazione: per verificarlo, fai riferimento alla documentazione dei prezzi. Non aggiungere un valore generico senza aver controllato quale strumento e modalità utilizzi.
Uno strumento ospitato sul server richiede un’ulteriore distinzione. Le sue operazioni possono avere costi propri e alcuni cicli possono essere eseguiti internamente dal servizio. In quel caso, ogni operazione interna non corrisponde necessariamente a una chiamata client visibile. Tieni separati il contatore delle richieste al modello e quello delle operazioni dello strumento, quindi applica a ciascun costo l’unità di fatturazione documentata.
Sequenza da riportare nel registro
Un ciclo lato client può contenere più di una richiesta al modello. Il conteggio deve seguire ciò che è avvenuto realmente, non il numero di turni visibili nell’interfaccia.
- 01L’applicazione invia al modello il contesto disponibile e le definizioni degli strumenti.
- 02Il modello restituisce una risposta, che può richiedere l’uso di uno strumento.
- 03L’applicazione esegue lo strumento e registra il risultato, la durata e gli eventuali errori.
- 04L’applicazione invia al modello il risultato insieme al contesto che decide di mantenere.
- 05Il modello risponde oppure richiede un altro strumento; il ciclo continua fino al criterio di completamento.
Modello di calcolo per round e per attività
Organizza il foglio con una riga per ogni richiesta al modello e una tabella separata, o un blocco distinto, per i costi degli strumenti. Per ciascuna riga del modello, annota i token di input fatturabili, i token di output fatturabili, il prezzo di input e quello di output, tutti riferiti al canale e alla data registrati. Se utilizzi uno strumento ospitato, registra inoltre ogni operazione fatturata da quello strumento. In questo modo puoi sommare la spesa di un’attività senza mescolare unità diverse.
La stima dei token per chiamata è: (token di input ÷ unità tariffaria) × prezzo di input + (token di output ÷ unità tariffaria) × prezzo di output. L’unità tariffaria deve essere quella indicata dal fornitore; se il prezzo è espresso per milione di token, l’unità è un milione. Per calcolare il costo di un’attività, somma i risultati di tutte le chiamate al modello e aggiungi separatamente gli eventuali costi degli strumenti.
La somma degli input non deve deduplicare il contesto in modo teorico. Se un messaggio di sistema, uno schema dello strumento o un risultato precedente compare in tre richieste fatturabili, conteggia l’utilizzo registrato in ciascuna richiesta, anche se il testo è identico. Al contrario, non aggiungere token stimati per contenuti che non sono stati inviati. Se non disponi di misurazioni affidabili, contrassegna il dato come stima e confrontalo con lo strumento per conteggiare i token o con i dati di utilizzo restituiti dall’API.
Colonne consigliate per un foglio riproducibile
Una riga per ogni chiamata al modello. Se gli strumenti ospitati hanno unità di addebito differenti, tienili in una tabella separata.
| Attività e tentativo | Round | Input | Output | Prezzo di input | Prezzo di output | Costo dei token |
|---|---|---|---|---|---|---|
| Identificatore stabile | 1, 2, 3… | Token misurati | Token misurati | Tariffa aggiornata | Tariffa aggiornata | (input/unità × prezzo) + (output/unità × prezzo) |
| Strumento | Operazione | Risultato registrato | Errore o successo | Unità fatturabile | Prezzo applicabile | Operazioni × prezzo |
Tre scenari esemplificativi
Gli scenari seguenti mostrano come strutturare il conteggio, ma non prevedono un utilizzo universale. I volumi di token sono numeri d’esempio per provare il foglio, non misurazioni di Claude né tariffe pubblicate. Per ottenere un costo monetario reale, sostituisci i token illustrativi con i registri della tua applicazione e con i prezzi verificati per il tuo canale.
Scenario A: una richiesta a cui si risponde senza strumenti. Conteggia l’unica richiesta al modello, compresi i messaggi e il contesto inviati, oltre all’output generato. Se l’applicazione include una definizione di uno strumento anche quando non lo usa, controlla il contenuto effettivo della richiesta e non presumere che la definizione fosse gratuita o assente. In questo caso c’è un solo round del modello, ma ciò non significa che tutte le richieste del prodotto abbiano lo stesso costo.
Scenario B: una domanda che richiede una ricerca. Conteggia la prima chiamata, la risposta che richiede lo strumento, l’operazione di ricerca e la chiamata successiva che include il risultato. Se viene utilizzato uno strumento ospitato sul server, registra il relativo costo con l’unità indicata dalla documentazione: non convertirlo in token. Se l’applicazione integra una ricerca esterna lato client, registra fuori dalla fattura dei token di Claude l’eventuale spesa esterna.
Scenario C: un’azione con più chiamate sequenziali o un tentativo non riuscito. Se il primo strumento restituisce un errore e l’applicazione chiede al modello di correggere il problema, somma quella chiamata e quelle successive. Se il processo riparte con un nuovo tentativo, conserva l’identificatore del tentativo e aggiungi il relativo consumo al costo dell’attività completata. Riportare solo il tentativo riuscito nasconderebbe la spesa necessaria per ottenere il risultato.
Quali variabili possono cambiare il risultato
Il numero di round è spesso una variabile determinante. Un’attività che termina dopo la prima risposta può comportare meno chiamate di una che richiede tre decisioni del modello. Non attribuire però ogni differenza al modello: può dipendere dalla logica dell’applicazione, dallo stato dello strumento, dalla qualità dei dati, dal limite di nuovi tentativi o dal criterio di successo.
Conta anche quanto contesto il client mantiene. Inviare definizioni lunghe, messaggi precedenti e risultati voluminosi può aumentare l’input dei round successivi. Ridurre la cronologia può modificare il consumo, ma è corretto farlo solo se si conserva quanto serve per l’attività. Misura l’effetto in un’esecuzione controllata invece di presumere che il contesto venga riassunto o conteggiato una sola volta.
Gli schemi degli strumenti e i token di sistema associati aggiungono un’altra variabile. La quantità effettiva dipende dallo strumento e dalla configurazione: va quindi controllata nella documentazione dei prezzi e nel conteggio della richiesta. Anche un risultato dello strumento lungo può aumentare l’input della chiamata successiva, se viene inviato al modello.
Infine, distingui le attività non riuscite, i nuovi tentativi automatici e le correzioni richieste dall’utente. Un budget basato sul costo medio delle sole attività completate può sottostimare la spesa se tralascia i tentativi falliti. È utile pubblicare sia il costo per tentativo sia il costo aggregato per attività completata, indicando il periodo e l’insieme di esecuzioni misurato.
Come indagare un aumento del costo per attività
Confronta registri equivalenti e modifica una variabile alla volta. La tabella orienta l’analisi, ma non dimostra una causalità senza misurazioni.
| Segnale osservato | Che cosa verificare | Misurazione utile |
|---|---|---|
| Più chiamate al modello | Limite dei round, nuovi tentativi e condizioni di completamento | Richieste per attività tentata e completata |
| Input in crescita nei round successivi | Cronologia reinviata, risultati degli strumenti e schemi | Token di input per chiamata e componente |
| Output in crescita | Lunghezza degli argomenti, spiegazioni intermedie e risposta finale | Token di output per round |
| Aumento senza variazioni apparenti nei token | Costi degli strumenti, canale, area geografica o piattaforma | Operazioni fatturabili e tariffa applicata |
Confronta il foglio con la produzione e dichiara le esclusioni
Per una verifica, conserva un identificatore dell’attività e del tentativo, l’identificatore del modello, il canale, il numero di ogni richiesta, gli strumenti disponibili, i risultati inviati al modello e i dati di utilizzo di ciascuna risposta. Registra anche le chiamate non riuscite e le operazioni che non hanno prodotto una risposta utile. Evita di salvare dati personali o segreti non necessari all’analisi; le metriche di costo possono essere associate a identificatori interni pseudonimi.
La documentazione dell’API comprende un endpoint per il conteggio dei token che accetta messaggi, istruzioni di sistema e strumenti. Può essere utile per stimare una richiesta prima di inviarla. Non sostituisce il confronto con l’utilizzo restituito durante l’esecuzione o con la fattura finale, soprattutto in presenza di più round, errori o costi degli strumenti. Usa la stima preliminare per pianificare e i registri effettivi per verificare.
Confronta il costo calcolato con la fattura per un periodo e un canale equivalenti. Per indagare le discrepanze, cerca chiamate mancanti, unità tariffarie interpretate male, differenze regionali o costi degli strumenti addebitati separatamente. Mantieni una colonna che riporti esplicitamente le esclusioni. Questo calcolo non include cache e Batch API: possono richiedere trattamenti specifici e non vanno aggiunte alla formula come se facessero parte del flusso di base.
Un dato utile non è necessariamente una previsione esatta. Pubblica il metodo, la data dei prezzi, il campione di attività, il numero di tentativi e le esclusioni. Se il campione è poco vario, presentalo come risultato di quel campione, non come costo tipico di qualsiasi attività con Sonnet 4.5.
Questioni aperte
- Le fonti fornite non riportano i valori aggiornati delle tariffe di input e output di Claude Sonnet 4.5; vanno verificati nella documentazione dei prezzi per il canale e la data pertinenti.
- Non sono forniti importi specifici per le differenze regionali o per i prezzi delle piattaforme associate; pertanto non vengono quantificati.
- I token di sistema associati all’uso degli strumenti possono variare in funzione dello strumento e della configurazione: occorre consultare la documentazione aggiornata e misurare il caso specifico.
- Non è specificata una tariffa concreta per gli strumenti ospitati né viene fornita un’esecuzione riproducibile con relativa fattura; non si afferma quindi che l’esempio numerico corrisponda a un addebito reale.
- Lo stato del modello e il calendario di ritiro devono essere verificati nuovamente al momento della pubblicazione; le date di disponibilità possono differire tra Claude API e piattaforme associate.
Continua a esplorare
Fonti consultate
Correzioni e trasparenza
Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.
Proponi una correzione