Tracker della spesa di Claude Code a confronto

Cosa legge realmente un tracker della spesa di Claude Code

Ogni tracker della spesa di Claude Code legge una delle tre origini dati, e l'origine determina a quale domanda può rispondere. Un parser dei log legge i file delle trascrizioni delle sessioni presenti sul disco locale. Una dashboard legge i dati di utilizzo che Anthropic conserva per il tuo account o la tua organizzazione. Un backend per le metriche legge il flusso OpenTelemetry (OTel) emesso da Claude Code quando lo abiliti. Tutti e tre possono essere corretti nello stesso momento e fornire comunque risultati diversi, perché contano elementi diversi.

Questa guida non rispiega i token. come Claude Code conteggia l'utilizzo dei token illustra i token di input e output, le scritture nella cache e le letture dalla cache; nessuna dashboard è davvero utile finché questo aspetto non è chiaro. Qui la domanda è più circoscritta: per ogni tipo di strumento, che cosa può vedere e che cosa non potrà mai vedere.

Perché in un solo giorno sono comparsi tre tracker della spesa di Claude Code

Nello stesso giorno sono stati pubblicati tre tracker distinti della spesa di Claude Code. Non erano tre versioni dello stesso strumento, ed è proprio questo l’aspetto utile. Uno analizzava i file delle sessioni locali. Uno integrava le schermate di utilizzo dell’account. Il terzo era un backend di tracing self-hosted da eseguire autonomamente.

Sono comparsi insieme perché il costo di una sessione dell’agente è diventato difficile da determinare. Una chat costa all’incirca quanto si vede sullo schermo. Un agente legge venti file, esegue la suite di test e reinvia l’intera conversazione a ogni turno; di conseguenza, il costo dipende dal contesto che non hai mai digitato. Con un abbonamento non viene mostrato alcun importo in dollari: c’è soltanto una barra di utilizzo che in alcuni giorni si esaurisce più rapidamente che in altri. Ognuno dei tre strumenti copre una parte diversa di questa lacuna.

Forma 1: un parser locale dei log mostra quanto è costato oggi

Claude Code salva ogni conversazione come JSON Lines (JSONL) in ~/.claude/projects/<project>/<session-id>.jsonl, dove <project> è il percorso della directory di lavoro con i caratteri non alfanumerici sostituiti da -. Ogni turno dell'assistente in quel file contiene il conteggio dei token della richiesta. Un parser dei log li somma e calcola il costo.

ccusage è lo strumento scelto dalla maggior parte degli utenti. Non richiede installazione:

npx ccusage@latest daily
npx ccusage@latest daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session --json

daily calcola i totali per data. --breakdown suddivide ogni riga per modello: in questo modo puoi verificare se un pomeriggio con Opus rappresenta la maggior parte del consumo della settimana. blocks raggruppa i dati in base alla finestra di cinque ore in cui si azzera l'abbonamento. session calcola i totali per conversazione, mentre --instances raggruppa i dati per progetto per mostrare quale repository è più costoso. Aggiungi --since e --until per delimitare l'intervallo e usa npx ccusage@latest daily --help per il formato della data previsto dalla tua versione. Ad agosto 2026 legge anche i dati di altre CLI per agenti, tra cui Codex e OpenCode. Questo è utile se vuoi confrontarle.

I prezzi provengono da una tabella dei prezzi dei modelli e lo strumento dispone di tre modalità di calcolo dei costi. --mode auto usa il valore costUSD scritto da Claude Code nel file, quando presente, e calcola il costo dai conteggi dei token quando il valore non è disponibile. --mode calculate calcola sempre il costo dai token e ignora qualsiasi costo registrato. --mode display mostra soltanto i costi registrati e stampa $0.00 per le righe che non ne contengono. Se un totale sembra errato, esegui lo stesso report con calculate e poi con display. Una differenza elevata indica che la maggior parte delle voci non contiene un costo registrato, quindi tutti i valori visualizzati sono stime.

Gli stessi dati possono alimentare il tuo prompt. ccusage statusline stampa una riga compatta per la barra di stato di Claude Code, collegata a ~/.claude/settings.json come qualsiasi altro comando per una riga di stato. Consulta creare una statusline per Claude Code per il blocco delle impostazioni e i campi che riceve.

Un parser dei log non può vedere ciò che non è avvenuto su questa macchina. Un secondo laptop, una sessione su claude.ai o il lavoro di un collega: quelle trascrizioni si trovano sui relativi dischi. Anche i dati meno recenti possono mancare, perché per impostazione predefinita le trascrizioni vengono eliminate dopo 30 giorni in base all'impostazione cleanupPeriodDays. I dati dell'ultimo trimestre sono quindi persi, a meno che tu non li abbia archiviati.

Esiste un ulteriore rischio, di natura strutturale. La documentazione di Anthropic afferma che il formato delle voci è interno a Claude Code e cambia tra le versioni. Gli script che analizzano direttamente questi file possono quindi smettere di funzionare con qualsiasi release. Questo vale per tutti gli strumenti di questo tipo. È anche il motivo per cui una riga jq scritta a mano per analizzare il JSONL è un'idea peggiore di quanto sembri: i parser mantenuti seguono le modifiche al formato, mentre la tua riga restituirà un numero apparentemente certo ma errato il giorno in cui un campo verrà rinominato.

Infine, per un abbonamento, il valore in dollari richiede una precisazione. Con Pro o Max non paghi ogni token. Il valore indica quanto sarebbe costato il tuo consumo applicando i prezzi API pubblici. Misura l'intensità del tuo utilizzo. Non corrisponde alla fattura. Se la domanda reale è quale piano scegliere, il confronto va svolto separatamente: consulta fatturazione API e abbonamento Claude.

Schema 2: le schermate di utilizzo integrate mostrano quale modello ha consumato il budget

Claude Code include funzioni di reportistica proprie, ma la maggior parte degli utenti non le apre mai. Esegui /usage all'interno di una sessione. Il riquadro Session in alto mostra i token per modello e un importo in dollari per la sessione corrente, calcolato localmente a partire dal numero di token e dalle tariffe standard di listino. Questo importo non tiene conto di sconti o prezzi promozionali, quindi può differire da quello della fattura. I totali vengono azzerati quando /clear avvia una nuova conversazione.

Nei piani Pro, Max, Team o Enterprise, la stessa schermata mostra la quota del limite del piano già utilizzata e attribuisce l'utilizzo recente a skills, subagents, plugins e singoli server MCP, come percentuale del totale. Segnala i comportamenti che rappresentano almeno il 10% dell'utilizzo recente, ad esempio un contesto lungo o i cache miss. Premi d o w per passare dalle ultime 24 ore agli ultimi 7 giorni e viceversa. Questi dati sono approssimativi e vengono calcolati dalla cronologia locale delle sessioni su questo computer, quindi l'utilizzo di un secondo dispositivo non viene conteggiato. Quando la barra è vuota, anziché semplicemente bassa, la schermata indica che la finestra è terminata, ma non spiega come continuare a lavorare; cosa fare dopo aver raggiunto il limite è una decisione distinta, relativa a modello, contesto e piano.

Quando gli sviluppatori sono più di uno, i dati vengono associati all'account. Un'organizzazione API dispone della pagina di utilizzo della Console, di una dashboard Claude Code con la spesa e le righe accettate per membro e di una Claude Code Analytics API che restituisce le stesse metriche giornaliere per utente tramite una chiave admin. I piani Team ed Enterprise includono un report della spesa nella console di amministrazione, con esportazione CSV e aggiornamento giornaliero; Enterprise aggiunge un'API di analisi. I dati visualizzati dipendono dal metodo con cui ogni sviluppatore ha effettuato l'accesso. Per questo, un'organizzazione mista deve consultare due report e sommarli manualmente.

Per dimensionare un budget, il dato pubblicato nella documentazione sui costi di Anthropic ad agosto 2026 indica una media di circa $13 per sviluppatore per giorno attivo e da $150 a $250 per sviluppatore al mese, con il 90% degli utenti al di sotto di $30 per giorno attivo. Consideralo un benchmark pubblicato ricavato da deployment aziendali, non una previsione per il tuo team. Esegui un progetto pilota con un gruppo di utenti e misura i risultati prima di fare un'estrapolazione.

Le dashboard non possono mostrare informazioni più dettagliate del giorno e della singola persona. Indicheranno che Opus è stato il modello più utilizzato per gran parte di martedì. Non diranno quale prompt, repository o job CI lo abbia determinato. Inoltre, i dati sono ritardati, perché i report dell'organizzazione vengono aggiornati quotidianamente. Sono quindi uno strumento di revisione, non un metodo per rilevare nel pomeriggio un agent fuori controllo. Per rilevare un agent fuori controllo servono limiti, non report. Questo è l'argomento di mantenere sotto controllo i costi degli agent su un VPS.

Forma 3: il tuo stack OpenTelemetry ti mostra quale prompt ha causato la regressione

Claude Code emette metriche ed eventi OpenTelemetry dopo l'impostazione di una variabile d'ambiente. È l'unica opzione che invia a un sistema sotto il tuo controllo i dati relativi a token e costi per utente, quasi in tempo reale. Le metriche includono claude_code.cost.usage in USD, claude_code.token.usage in token, claude_code.session.count e claude_code.active_time.total.

La metrica dei token è quella più utile per via dei relativi attributi. Ogni punto dati contiene type, che può essere input, output, cacheRead o cacheCreation, oltre a model e query_source, che può essere main, subagent o auxiliary. Contiene inoltre agent.name, skill.name, mcp_server.name e mcp_tool.name. Questi dati sono sufficienti per rispondere a domande a cui nessun dashboard può arrivare: quanta parte della fattura è dovuta ai subagenti anziché ai tuoi turni, se un server MCP ha raddoppiato i token di input, oppure se le letture dalla cache sono diminuite dopo che qualcuno ha modificato CLAUDE.md. Spesso le anomalie si nascondono proprio nel comportamento della cache; quando il caching dei prompt diventa conveniente spiega come interpretare questi dati.

È utile correggere un'inesattezza, perché ricorre in ogni discussione sull'argomento. Langfuse è un buon backend di tracing self-hosted, e l'esecuzione su un VPS è descritta in eseguire Langfuse in modalità self-hosted per il tracing degli agenti. Il relativo endpoint OTLP accetta solo trace. Claude Code esporta metriche ed eventi di log, non span. Di conseguenza, indirizzare OTEL_EXPORTER_OTLP_ENDPOINT a Langfuse lascia il progetto vuoto e non produce alcun errore utile da analizzare. Langfuse è lo strumento corretto per gli agenti che sviluppi direttamente tramite API, dove il tuo codice crea ogni span con il relativo prompt, modello e costo. Per la CLI di Claude Code, la scelta corretta è un sistema di archiviazione delle metriche.

Configurare il monitoraggio della spesa di Claude Code sul proprio VPS

Sono sufficienti due servizi: un collector che riceve le metriche e Prometheus che le memorizza. Mantenerli entrambi fuori da Internet pubblico, perché una porta OTLP aperta accetta scritture da chiunque la individui. Scrivere /opt/ccmetrics/compose.yaml:

services:
  collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel/config.yaml"]
    volumes:
      - ./collector.yaml:/etc/otel/config.yaml:ro
    ports:
      - "10.8.0.1:4318:4318"
    restart: unless-stopped
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

volumes:
  prom-data:

10.8.0.1 è l'indirizzo del server all'interno di un tunnel WireGuard, quindi il collector è raggiungibile dalle proprie macchine e da nessun altro. L'indirizzo davanti alla porta è importante, perché le porte Docker pubblicate non vengono filtrate da ufw: vedere perché le porte pubblicate da Docker bypassano ufw. La configurazione del tunnel è descritta in una VPN WireGuard sul proprio VPS.

/opt/ccmetrics/collector.yaml:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

/opt/ccmetrics/prometheus.yml. La porta 8889 non viene mai pubblicata sull'host, perché Prometheus raggiunge il collector attraverso la rete Compose usando il nome del servizio:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: claude-code
    static_configs:
      - targets: ["collector:8889"]

cd /opt/ccmetrics
docker compose up -d
docker compose logs collector

Il log del collector dovrebbe terminare con Everything is ready. Begin running and processing data.. Se il log si interrompe a causa di un errore di configurazione, significa che il file YAML non è stato analizzato correttamente e il container verrà riavviato in un ciclo continuo.

Ora configurare Claude Code perché utilizzi il collector. Su ogni macchina che esegue Claude Code, aggiungere questo contenuto a ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://10.8.0.1:4318",
    "OTEL_METRIC_EXPORT_INTERVAL": "10000"
  }
}

Avviare una sessione, inviare un prompt, attendere l'intervallo di esportazione (10 secondi in questo esempio, 60 secondi per impostazione predefinita), quindi chiedere a Prometheus quali dati ha ricevuto:

curl -s http://localhost:9090/api/v1/label/__name__/values | grep -o 'claude_code[a-z_]*'

Dovrebbero essere visualizzati diversi nomi che iniziano con claude_code_. L'exporter sostituisce i punti con underscore e aggiunge l'unità, quindi le stringhe esatte dipendono dalla versione del collector. Un risultato vuoto indica che non è arrivato nulla. Verificare che protocollo e porta corrispondano, perché http/protobuf usa la porta 4318 mentre grpc usa la porta 4317; una configurazione non corrispondente fallisce senza messaggi evidenti. Eseguire claude --debug: il log di debug mostrerà gli errori di esportazione OTel.

Per una sola macchina e senza server, ignorare tutti i passaggi precedenti. Impostare OTEL_METRICS_EXPORTER=prometheus: Claude Code espone direttamente un endpoint di scraping all'indirizzo http://localhost:9464/metrics. Quando prometheus è l'unico exporter elencato, Claude Code omette le unità USD, tokens e s dai nomi delle metriche, così lo scraping resta nel formato di testo valido per Prometheus.

Questa configurazione comporta una decisione sulla privacy. Per impostazione predefinita, dalla macchina vengono inviati solo i conteggi, non il testo dei prompt né l'output degli strumenti. OTEL_LOG_USER_PROMPTS=1 e OTEL_LOG_TOOL_CONTENT=1 modificano questo comportamento; in tal caso il sistema di metriche contiene il codice sorgente e qualsiasi altro contenuto presente nel contesto. Abilitare queste opzioni solo consapevolmente e leggere prima evitare i secret nel contesto dell'agent.

Monitoraggio dei costi per esecuzioni tramite script e CI

Le esecuzioni non interattive sono quelle che riservano più sorprese, perché nessuno controlla lo schermo. claude -p con --output-format json restituisce nel payload del risultato il costo di quell'esecuzione:

claude -p "summarise the failing tests" --output-format json | jq '.total_cost_usd'

Il payload contiene total_cost_usd e una suddivisione per modello. In questo modo, un job CI può registrare i propri costi senza usare dashboard. Accodate il valore a un file oppure inviatelo come metrica al collector indicato sopra. È il metodo più economico e utile per monitorare i costi e richiede una chiamata jq per esecuzione.

Modalità di errore e risultati osservabili

Il report è vuoto. npx ccusage@latest daily non stampa alcuna riga perché non sta leggendo il percorso in cui Claude Code scrive i dati. CLAUDE_CONFIG_DIR sposta tale percorso, che deve quindi essere comunicato al parser. Se esistono righe, ma si fermano a circa un mese fa, cleanupPeriodDays funziona come previsto: per impostazione predefinita, le trascrizioni vengono rimosse dopo 30 giorni.

Due macchine riportano totali diversi. È previsto e non indica un errore. Sia /usage sia qualsiasi parser dei log leggono soltanto la cronologia delle sessioni locali, quindi l'utilizzo di un altro dispositivo o di claude.ai non è incluso in nessuno dei due.

Il totale locale non corrisponde alla fattura. I valori locali vengono calcolati a partire dai conteggi dei token usando le tariffe standard di listino. Non tengono conto dei prezzi promozionali o di uno sconto contrattuale. Inoltre, con un abbonamento i token non vengono fatturati singolarmente. Per la fatturazione API, la fonte autorevole è la pagina dell'utilizzo nella Console.

Il costo è aumentato anche se hai svolto lo stesso lavoro. Controlla innanzitutto le colonne relative alla cache. Una sessione lunga reinvia l'intera cronologia a ogni turno. Quando la cache è attiva, viene applicata la tariffa per i dati memorizzati nella cache; quando la cache scade, viene applicata la tariffa completa per l'input. Di conseguenza, una lunga pausa può causare la rielaborazione dell'intera conversazione. Questo appare come un numero elevato di token di input accanto a un numero ridotto di token di output. il confronto tra i prezzi dei token di input e di output spiega perché i due valori variano indipendentemente.

Una giornata con subagent sembra impossibile da spiegare. Ogni subagent usa una propria finestra di contesto, quindi il consumo di token aumenta in funzione del numero di subagent eseguiti e della durata di ciascuno. Solo i dati OTel li distinguono, tramite l'attributo query_source su claude_code.token.usage. Un parser dei log mostrerà il totale, lasciandoti senza informazioni per determinare la ripartizione.

FAQ

ccusage mostra quanto mi viene addebitato effettivamente con un piano Max?

No. Con un abbonamento non viene addebitato un importo per token. Un parser dei log applica quindi ai token le tariffe API standard e mostra quanto sarebbe costato lo stesso lavoro tramite API. È una buona misura relativa del carico di una giornata e consente di confrontare progetti o modelli tra loro. Per conoscere l'importo effettivamente dovuto, la pagina dell'utilizzo nella Console contiene la fatturazione API, mentre la pagina di fatturazione del piano contiene quella dell'abbonamento.

Dove archivia Claude Code i file di sessione letti da questi strumenti?

In ~/.claude/projects/<project>/<session-id>.jsonl, dove <project> è il percorso della directory di lavoro con i caratteri non alfanumerici sostituiti da -. Ogni riga è un oggetto JSON che rappresenta un messaggio, l'utilizzo di uno strumento o una voce di metadati. CLAUDE_CONFIG_DIR sposta l'intera directory e cleanupPeriodDays in settings.json controlla la conservazione di 30 giorni. Anthropic documenta il formato delle voci come interno e soggetto a modifiche tra le versioni. Per questo, analizzalo con uno strumento mantenuto invece di usare uno script proprietario.

Posso inviare la telemetria di Claude Code a Langfuse?

Non direttamente. L'endpoint OTLP di Langfuse accetta le trace, mentre Claude Code esporta metriche ed eventi di log, non span. I dati non avrebbero quindi una destinazione compatibile. Invia le metriche di Claude Code a un collector OpenTelemetry e archiviali in Prometheus. Usa Langfuse per gli agenti che sviluppi direttamente tramite API, dove il tuo codice genera span contenenti il prompt, il modello e il costo.

Perché i valori locali non corrispondono alla pagina dell'utilizzo nella Console?

Perché vengono calcolati in modo diverso. /usage e i parser dei log sommano i conteggi dei token dai file di sessione presenti sul computer in uso, quindi applicano le tariffe API standard. La Console indica quanto è stato effettivamente addebitato alla tua organizzazione, su tutti i computer e con tutte le chiavi, dopo l'applicazione degli eventuali sconti. Una differenza è normale. Una differenza molto grande indica solitamente un secondo dispositivo, un runner CI o un altro membro del team che addebita i costi allo stesso account.

Come posso monitorare il costo di un'esecuzione claude -p in CI?

Eseguila con --output-format json e leggi total_cost_usd dal risultato, ad esempio con claude -p "..." --output-format json | jq '.total_cost_usd'. Lo stesso payload include il dettaglio per modello e l'ID della sessione. Registra quel valore per ogni job per ottenere la spesa per pipeline senza agenti, dashboard o servizi aggiuntivi.