Tracker della spesa Claude Code a confronto

Che 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 record di utilizzo che Anthropic conserva per il tuo account o per la tua organizzazione. Un backend per le metriche legge il flusso OpenTelemetry (OTel) che Claude Code emette quando lo abiliti. Tutti e tre possono essere corretti nello stesso momento e fornire comunque risultati diversi, perché contano elementi diversi.

Questa guida non spiega di nuovo i token. come Claude Code conta l'utilizzo dei token descrive gli input, gli output, le scritture nella cache e le letture dalla cache; nessuna dashboard è davvero comprensibile finché questo aspetto non è chiaro. La domanda qui è 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 strumenti per monitorare la spesa di Claude Code

Nello stesso giorno sono stati pubblicati tre strumenti distinti per monitorare la 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 con i dati sull’utilizzo dell’account. Il terzo era un backend di tracing ospitato che si esegue autonomamente.

Sono comparsi insieme perché il costo di una sessione dell’agente è diventato difficile da valutare. 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 colma una parte diversa di questa lacuna.

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

Claude Code memorizza 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 intervento dell'assistente in quel file contiene il numero di token della richiesta. Un parser dei log li somma e calcola il costo.

ccusage è lo strumento che la maggior parte degli utenti sceglie. 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, mostrando così se un pomeriggio con Opus rappresenta gran parte della settimana. blocks raggruppa i dati in base alla finestra di cinque ore in cui si rinnova un abbonamento. session calcola i totali per conversazione e --instances raggruppa i dati per progetto, così puoi vedere quale repository è più costoso. Usa --since e --until per delimitare l'intervallo e npx ccusage@latest daily --help per verificare il formato delle date previsto dalla tua versione. Ad agosto 2026 lo strumento legge anche i dati di altre CLI per agenti, tra cui Codex e OpenCode. Questo è utile per confrontarle.

I prezzi provengono da una tabella dei prezzi dei modelli e lo strumento supporta 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 non è presente. --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 ne sono prive. 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 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 creazione di una barra di stato per Claude Code per il blocco di configurazione e i campi che riceve.

Un parser dei log non può vedere ciò che non è avvenuto su questa macchina. Un secondo portatile, una sessione su claude.ai o il lavoro di un collega: quei transcript si trovano sui relativi dischi. Anche i dati meno recenti possono mancare, perché per impostazione predefinita i transcript vengono eliminati dopo 30 giorni secondo l'impostazione cleanupPeriodDays. Quindi i dati dell'ultimo trimestre non sono più disponibili, a meno che tu non li abbia archiviati.

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

Infine, il valore in dollari richiede una precisazione per gli abbonamenti. Con Pro o Max non paghi in base al numero di token, quindi il valore indica quanto sarebbe costato il loro utilizzo alle tariffe API standard. 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.

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

Claude Code include funzioni di reporting 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.

Con un piano Pro, Max, Team o Enterprise, la stessa schermata mostra la quota del limite del piano già utilizzata e attribuisce l'utilizzo recente a skill, subagent, plugin e singoli server MCP, come percentuale del totale. Segnala i comportamenti che rappresentano almeno il 10% dell'utilizzo recente, ad esempio contesti lunghi o cache miss. Premi d o w per passare dalle ultime 24 ore agli ultimi 7 giorni e viceversa. Questi valori sono approssimativi e vengono calcolati a partire dalla cronologia locale delle sessioni su questa macchina, quindi l'utilizzo di un secondo dispositivo non viene conteggiato.

Quando gli sviluppatori sono più di uno, i valori vengono associati all'account. Un'organizzazione API dispone della pagina Console usage, 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 offrono un report della spesa nella console di amministrazione, con esportazione CSV e aggiornamento giornaliero; Enterprise aggiunge anche un'analytics API. La visualizzazione disponibile dipende dal metodo con cui ogni sviluppatore ha effettuato l'accesso. Di conseguenza, un'organizzazione mista deve consultare due report e sommare manualmente i valori.

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 di attività e da $150 a $250 per sviluppatore al mese, con il 90% degli utenti sotto $30 per giorno di attività. Consideralo un benchmark pubblicato sulla base di implementazioni enterprise, non una previsione per il tuo team. Esegui un pilot su un gruppo ristretto e misura i risultati prima di fare un'estrapolazione.

Le dashboard non possono mostrare i dettagli inferiori alla granularità giornaliera e al singolo utente. Indicheranno che Opus è stato il modello più utilizzato per la maggior parte di martedì. Non diranno quale prompt, quale repository o quale job CI lo ha causato. Inoltre, i dati sono in ritardo, perché i report dell'organizzazione vengono aggiornati quotidianamente. Sono quindi uno strumento di revisione, non un metodo per rilevare oggi 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 indica 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 i dati relativi a token e costi per singolo utente a un sistema sotto il tuo controllo, 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 è la più interessante per i suoi 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 anche agent.name, skill.name, mcp_server.name e mcp_tool.name. Questi dati bastano per rispondere a domande a cui nessuna dashboard può rispondere: quale quota della fattura deriva dai subagenti anziché dalle tue richieste, se un server MCP ha raddoppiato i token di input, oppure se le letture dalla cache sono diminuite dopo una modifica a CLAUDE.md. Il comportamento della cache è spesso la fonte delle sorprese. quando il prompt caching diventa conveniente spiega come interpretare questi dati.

È utile fare una precisazione, perché questo punto ricorre in ogni discussione sull'argomento. Langfuse è un buon backend di tracing self-hosted, e l'esecuzione su un VPS è descritta in self-hosting di Langfuse per il tracing degli agenti. Il suo endpoint OTLP accetta soltanto trace. Claude Code esporta metriche ed eventi di log, non span. Di conseguenza, configurare OTEL_EXPORTER_OTLP_ENDPOINT verso Langfuse lascia il progetto vuoto e non produce un errore utile da analizzare. Langfuse è lo strumento adatto 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 archivio di metriche.

Configurare il monitoraggio dei costi di Claude Code sul proprio VPS

Sono sufficienti 2 servizi: un collector che riceve le metriche e Prometheus che le archivia. Teneteli entrambi fuori da Internet, perché una porta OTLP aperta accetta scritture da chiunque la individui. Scrivete /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 vostre macchine e da nessun altro. L'indirizzo anteposto alla porta svolge qui una funzione effettiva, perché le porte Docker pubblicate non sono filtrate da ufw: vedete perché le porte Docker pubblicate 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 tramite 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 per un errore di configurazione, il file YAML non è stato analizzato correttamente e il container verrà riavviato in un ciclo continuo.

Ora configurate Claude Code per usarlo. Su ogni macchina che esegue Claude Code, aggiungete quanto segue 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"
  }
}

Avviate una sessione, inviate un prompt, attendete l'intervallo di esportazione (10 secondi in questo caso, 60 secondi per impostazione predefinita), quindi chiedete a Prometheus quali dati ha ricevuto:

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

Dovreste ottenere diversi nomi che iniziano con claude_code_. L'exporter sostituisce i punti con caratteri di sottolineatura e aggiunge l'unità, quindi le stringhe esatte dipendono dalla versione del collector. Un risultato vuoto indica che non è arrivato nulla. Verificate che protocollo e porta corrispondano, perché http/protobuf usa la porta 4318 e grpc usa la porta 4317; una mancata corrispondenza non genera errori evidenti. Eseguite claude --debug: il log di debug mostrerà gli errori di esportazione OTel.

Per una sola macchina e senza server, ignorate tutto quanto sopra. Impostate OTEL_METRICS_EXPORTER=prometheus: Claude Code esporrà direttamente un endpoint di scraping su 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 mantiene un formato di testo Prometheus valido.

Questa configurazione comporta una scelta relativa alla privacy. Per impostazione predefinita, dalla macchina escono soltanto i conteggi; non vengono inviati 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 server delle metriche contiene codice sorgente e qualsiasi altro dato presente nel contesto. Attivate queste opzioni solo intenzionalmente e leggete prima come evitare i secret nel contesto dell'agent.

Monitoraggio dei costi per esecuzioni tramite script e CI

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

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

Il payload contiene total_cost_usd e una ripartizione per modello. Un job CI può quindi registrare i propri costi senza utilizzare alcun dashboard. Aggiungi il valore a un file oppure invialo come metrica al collector indicato sopra. Questo è il metodo più economico realmente utile per monitorare i costi e richiede una chiamata jq per ogni esecuzione.

Modalità di errore e cosa verrà visualizzato

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 quella posizione e occorre indicarla al parser. Se sono presenti righe, ma si fermano a circa un mese prima, significa che cleanupPeriodDays funziona come previsto: per impostazione predefinita, le trascrizioni vengono rimosse dopo 30 giorni.

Due macchine riportano totali diversi. È previsto e non è un bug. Sia /usage sia qualsiasi parser dei log leggono soltanto la cronologia delle sessioni locali. L'utilizzo di un altro dispositivo o di claude.ai non è quindi 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 di prezzi promozionali o sconti contrattuali. Inoltre, con un abbonamento, i token non vengono fatturati singolarmente. Per la fatturazione API, fa fede la pagina di utilizzo della Console.

I costi sono aumentati 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. Una lunga interruzione può quindi 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 prezzo dei token di input rispetto a quello dei token di output spiega perché i due valori variano indipendentemente.

Una giornata con i subagent sembra impossibile. Ogni subagent usa una propria finestra di contesto. Il consumo di token dipende quindi dal numero di subagent eseguiti e dalla durata di ciascuno. Solo i dati OTel consentono di distinguerli, tramite l'attributo query_source su claude_code.token.usage. Un parser dei log mostra il totale, ma non consente di attribuirlo ai singoli subagent.

FAQ

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

No. Con un abbonamento non viene addebitato ogni token. Un parser dei log calcola il prezzo dei token usando le tariffe API standard di listino e mostra quanto sarebbe costato lo stesso lavoro tramite l'API. È una buona misura relativa del carico di una giornata ed è utile per confrontare tra loro progetti o modelli. Per sapere quanto devi pagare, la pagina di utilizzo della Console riguarda la fatturazione API, mentre la pagina di fatturazione del piano riguarda l'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, mentre 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 trace, mentre Claude Code esporta metriche ed eventi di log anziché span. Di conseguenza, i dati non hanno una destinazione compatibile. Invia le metriche di Claude Code a un collector OpenTelemetry e archivialele in Prometheus. Usa Langfuse per gli agenti che sviluppi direttamente sull'API, dove il tuo codice emette span contenenti prompt, modello e costo.

Perché i valori locali non corrispondono alla pagina di utilizzo della Console?

Perché vengono calcolati in modo diverso. /usage e i parser dei log sommano i conteggi dei token dai file di sessione presenti sulla macchina in uso, quindi applicano le tariffe standard di listino. La Console indica quanto è stato effettivamente addebitato alla tua organizzazione, considerando tutte le macchine e tutte le chiavi, dopo l'applicazione di eventuali sconti. Una differenza è normale. Una differenza molto grande indica in genere un secondo dispositivo, un runner CI o un altro membro del team che utilizza lo stesso account per la fatturazione.

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 una suddivisione 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.