Quanto è veloce Claude Code? Token al secondo, misurati su 20.000 turni

Claude Code ti dice molte cose sui token. /usage mostra quanto hai consumato della sessione e della settimana, il monitor di sessione di AgentsRoom conta input, output, letture e scritture della cache turno per turno, e la riga di stato può mostrare la parte della finestra di contesto in uso. Nessuno di questi mostra il numero che la gente continua a cercare: quanti token al secondo il modello produce davvero mentre aspetti.

Il numero non è nascosto, semplicemente nessuno lo calcola. Ogni messaggio di ogni sessione finisce in una trascrizione JSONL in ~/.claude/projects/, e ogni messaggio dell'assistente riporta un timestamp e il suo consumo di token. Quindi l'abbiamo calcolato, sulla nostra macchina, nelle ultime quattro settimane. Ecco il metodo, lo script e cosa ne è uscito.

Da dove vengono i dati

Claude Code scrive un file per sessione in ~/.claude/projects/<project slug>/<session id>.jsonl. Una riga per evento. Le righe che contano qui sono i messaggi dell'assistente, e ognuno ha questo aspetto quando tieni solo i campi utili:

{
  "type": "assistant",
  "uuid": "24d13076-…",
  "parentUuid": "d4447285-…",
  "requestId": "req_011CepWq…",
  "timestamp": "2026-09-07T18:00:08.412Z",
  "message": {
    "model": "claude-opus-5",
    "usage": {
      "input_tokens": 2,
      "cache_read_input_tokens": 0,
      "cache_creation_input_tokens": 51591,
      "output_tokens": 200,
      "output_tokens_details": { "thinking_tokens": 0 },
      "speed": "standard"
    }
  }
}

Quattro elementi rendono possibile la misura:

• timestamp viene scritto quando il blocco di contenuto viene aggiunto, quindi l'ultimo blocco di un turno è datato alla fine dello streaming.
• parentUuid punta alla riga subito precedente, il messaggio dell'utente o il risultato dello strumento a cui il modello stava rispondendo. Il suo timestamp è il momento in cui è partita la richiesta.
• requestId raggruppa i blocchi di una stessa chiamata API. Un turno che scrive del testo e poi chiama uno strumento produce due righe dell'assistente con lo stesso requestId e lo stesso usage, quindi i token vanno contati una volta per richiesta, non una volta per riga.
• usage.output_tokens è l'output totale della richiesta, ragionamento incluso; output_tokens_details.thinking_tokens dice quanta parte era ragionamento.

Niente nel file indica il tempo fino al primo token. Quello che puoi misurare è il turno intero: dalla richiesta che lascia la tua macchina all'arrivo dell'ultimo token. È anche l'unico numero che percepisci mentre aspetti, quindi è quello che abbiamo tenuto.

Il metodo

Per ogni requestId: prendi la prima e l'ultima riga dell'assistente che lo riportano, leggi l'usage dalla prima, trova il genitore della prima riga e dividi i token di output per i secondi tra il timestamp del genitore e quello dell'ultima riga. Poi guarda la distribuzione per modello, mai una media unica, perché un turno di 40 secondi e uno di 2 secondi non sono la stessa cosa.

Abbiamo scartato i turni senza token di output, i turni con una durata negativa o nulla (una sessione ripresa può avere un genitore datato dopo il figlio) e i turni più lunghi di quindici minuti, che sono sessioni interrotte e non risposte lunghe. Nient'altro è stato filtrato.

Lo script è di 40 righe di Python senza dipendenze. Lancialo da qualsiasi cartella: legge tutti i progetti della macchina.

import json, glob, os, statistics as st
from datetime import datetime
from collections import defaultdict

def ts(s): return datetime.fromisoformat(s.replace("Z", "+00:00")).timestamp()

turns = []
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    by_uuid, groups, order = {}, {}, []
    with open(path) as fh:
        for line in fh:
            try: o = json.loads(line)
            except ValueError: continue
            if "uuid" in o: by_uuid[o["uuid"]] = o
            msg = o.get("message") or {}
            if o.get("type") == "assistant" and msg.get("usage") and o.get("timestamp"):
                rid = o.get("requestId") or o["uuid"]
                if rid not in groups: groups[rid] = []; order.append(rid)
                groups[rid].append(o)
    for rid in order:
        first, last = groups[rid][0], groups[rid][-1]
        out = first["message"]["usage"].get("output_tokens", 0)
        parent = by_uuid.get(first.get("parentUuid"))
        if not parent or not parent.get("timestamp") or out <= 0: continue
        dur = ts(last["timestamp"]) - ts(parent["timestamp"])
        if 0 < dur <= 900:
            turns.append((first["message"].get("model"), out, dur))

by_model = defaultdict(list)
for model, out, dur in turns: by_model[model].append((out, dur))
for model, rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    rates = [o / d for o, d in rows]
    print(f"{model:18s} turns={len(rows):6d} median={st.median(rates):5.1f} tok/s "
          f"weighted={sum(o for o, _ in rows) / sum(d for _, d in rows):5.1f} tok/s")

La colonna weighted è il totale dei token diviso per il totale dei secondi. È ciò che vive una lunga esecuzione autonoma; la mediana è ciò che vive un singolo turno interattivo.

I numeri

Un Mac in Francia, 319 trascrizioni, 20.408 turni tra il 27 agosto e il 25 settembre 2026, 12,0 milioni di token di output prodotti in 45 ore di generazione. Velocità standard su ogni turno (vedi la modalità veloce più sotto). Nelle trascrizioni compaiono cinque modelli, con i nomi che scrive Claude Code.

Due letture prima di tutto il resto. Primo, Opus 5.5 non è un po' più veloce di Opus 5: è una volta e mezza più veloce sulla mediana e il 57% più veloce sul dato ponderato, con una quota molto più alta di turni lunghi. Secondo, la dispersione all'interno di un modello è più ampia dello scarto tra i modelli: un turno di Opus 5 al 25° percentile genera a 51 token al secondo e uno al 75° a 72. Il motivo è la dimensione del turno, e merita una sezione a sé.

Una risposta breve è sempre più lenta

Ecco di nuovo Opus 5, suddiviso per numero di token di output nel turno:

Stesso modello, stesso mese, stessa macchina, e il ritmo raddoppia tra una risposta di una riga e una lunga. Il modello non genera più in fretta sui turni lunghi. Ogni turno paga un costo fisso in tempo prima che compaia il primo token: la richiesta parte, il prompt viene elaborato, lo streaming inizia. Su un turno di 80 token questo costo è un terzo del tempo trascorso; su un turno di 3.000 token sparisce nel rumore.

Una regressione ai minimi quadrati della durata rispetto ai token di output separa le due cose. La pendenza dà la velocità di streaming, l'intercetta dà il costo fisso:

Quindi, quando una sessione piena di chiamate agli strumenti sembra lenta, raramente dipende dalla capacità di generazione del modello. Dipende dal numero di turni. Un agente che legge dodici file uno alla volta paga dodici costi fissi; lo stesso agente che li legge in un'unica chiamata raggruppata ne paga uno. È la stessa lezione di ridurre i costi dei token: meno turni e più grandi, non un modello più veloce.

Il turno singolo più lungo del corpus conta 21.332 token di output in 236 secondi su Opus 5, cioè 90 token al secondo dall'inizio alla fine: una volta ammortizzato il costo fisso, è il tetto che abbiamo osservato su quel modello alla velocità standard.

I token di ragionamento sono token di output

output_tokens include il ragionamento che il modello fa prima di rispondere, e output_tokens_details.thinking_tokens ti dice quanto. Nel nostro corpus il ragionamento è il 30% di tutto ciò che ha prodotto Opus 5, il 18% per Opus 5.5, il 36% per Fable 5.1 e il 54% per Sonnet 5, che abbiamo usato quasi sempre con un livello di sforzo più alto per attività di revisione.

Questo conta quando leggi un turno lento. Un turno che ragiona per otto secondi e stampa due righe non è un modello lento: è un turno che ha prodotto 600 token che non hai mai visto. I turni con ragionamento sono, per token, leggermente più veloci di quelli senza: 67 contro 57 token al secondo su Opus 5, perché sono più lunghi e ammortizzano meglio il costo fisso. Se una sessione sembra fiacca e non ti serve il ragionamento, la leva è il livello di sforzo, non il modello.

Le letture dalla cache cambiano il conto, non il ritmo

Quasi ogni turno in Claude Code trova la cache dei prompt: solo 130 dei 16.680 turni di Opus 5 avevano cache_read_input_tokens a zero, e sono il primo turno di una sessione. Sui turni da 100 a 500 token di output, quelli in cache generano a una mediana di 60,6 token al secondo e durano 3,4 secondi; quelli fuori cache generano a 58,0 e durano 3,7 secondi. La differenza è reale ma piccola, e sta nel costo fisso, non nella velocità di streaming. La cache riguarda il prezzo del contesto che ti porti dietro, ed è per questo che il contatore dei token nel terminale di AgentsRoom mostra le letture e le scritture della cache come due numeri separati.

Stabile nell'arco del mese

Un numero cumulato può nascondere una deriva, quindi abbiamo guardato anche la mediana settimanale di Opus 5 sui turni da 100 a 500 token, i più frequenti: 63,6, 64,1, 60,9, 61,7, 56,9 token al secondo settimana dopo settimana, poi 68,7 nell'ultima settimana, incompleta. Tra 57 e 69, nessuna tendenza. Se un pomeriggio le tue sessioni sembrano più lente, vale la pena lanciare lo script solo su quella giornata prima di dare la colpa al modello.

Cosa cambia con la modalità veloce, e cosa non abbiamo potuto misurare

Ogni blocco usage riporta un campo speed, e tutti i nostri 20.408 dicono standard. Anthropic documenta una modalità veloce (fast mode) per Claude Opus, attivabile con /fast nella CLI o con "fastMode": true nelle impostazioni utente, che rende il modello fino a 2,5 volte più veloce a un prezzo per token più alto: 8 dollari per milione di token di input e 40 per milione di token di output su Opus 5.5, 10 e 50 su Opus 5 e Opus 4.8. Sui piani Pro e Max viene addebitata sui crediti di utilizzo, fuori dalle finestre dell'abbonamento; Sonnet e Haiku non la supportano, e attivarla ti sposta su Opus. Un'icona a forma di fulmine accanto al prompt indica che è attiva.

Non l'abbiamo pagata, quindi non abbiamo un numero misurato da mettere accanto alle 2,5 volte documentate. Se la usi, lo stesso script ti dice cosa hai ottenuto: filtra i turni con usage["speed"] == "fast" e confronta le mediane. Mandaci i numeri.

Cosa cambia nel modo in cui facciamo lavorare gli agenti

Tre cose, e nessuna riguarda la scelta di un modello più veloce.

La prima riguarda le aspettative. Se un'esecuzione notturna di sette agenti produce due milioni di token di output, sono otto ore di generazione a 70 token al secondo, distribuite tra agenti che lavorano in parallelo. Conoscere il ritmo è ciò che ti permette di dire se un'attività pianificata può finire prima che parta la successiva.

La seconda riguarda i turni. Il secondo fisso per turno è lo stesso su una conferma di 30 token e su un diff di 3.000 token. Gli agenti che chiedono prima di ogni piccolo passo, o che leggono i file uno alla volta, passano il loro tempo in quel secondo. Per questo scriviamo «raggruppa le letture indipendenti» nei prompt degli agenti che lavorano senza supervisione.

La terza riguarda cosa dovrebbe mostrare il contatore. Il monitor di sessione di AgentsRoom mostra i token e la cache, e diventa rosso quando una sessione si appesantisce; non mostra un ritmo, e dopo questa misura non siamo sicuri che dovrebbe. Un ritmo è una proprietà del modello e della dimensione del turno, non della sessione, e il numero che serve a uno sviluppatore è quello delle tabelle qui sopra. Per questo è un articolo e non un widget.

Domande frequenti

Quanti token al secondo genera Claude Code?

Sui nostri 20.408 turni registrati tra il 27 agosto e il 25 settembre 2026: Opus 5 ha una mediana di 63 token di output al secondo (69 se dividi tutti i token per tutti i secondi), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) e Opus 4.8 61 (64). Questi numeri contano il turno intero, dal momento in cui la richiesta lascia la tua macchina fino all'ultimo token ricevuto, quindi sono ciò che aspetti davvero.

/usage o /cost mostrano i token al secondo?

No. /usage mostra la quota del tuo piano, le finestre da 5 ore e settimanale e la parte della finestra di contesto in uso; /cost è un alias di /usage. Nessuno dei due mostra un ritmo. L'unico posto in cui la velocità esiste è la trascrizione della sessione in ~/.claude/projects/, dove ogni messaggio dell'assistente riporta un timestamp e il suo numero di token di output. È quello che legge lo script di questo articolo.

Perché una risposta breve sembra più lenta di una lunga?

Perché ogni turno paga un costo fisso in tempo prima che arrivi il primo token: l'invio della richiesta, l'elaborazione del prompt, l'avvio dello streaming. Nei nostri dati questa attesa è di circa un secondo su Opus 5 e Opus 5.5 e di mezzo secondo su Sonnet 5. Su una risposta di 80 token, un secondo è un terzo del turno, quindi il ritmo misurato scende a 40 token al secondo; su una risposta di 3.000 token lo stesso secondo sparisce e il ritmo sale a 80 o più. La velocità di streaming in sé è costante.

I token di ragionamento contano nella velocità?

Sì. Il blocco usage di ogni messaggio riporta output_tokens con un dettaglio output_tokens_details.thinking_tokens, e i token di ragionamento fanno parte di output_tokens. Nel nostro corpus sono il 30% di tutto ciò che ha prodotto Opus 5, il 18% per Opus 5.5 e il 54% per Sonnet 5, che ha lavorato quasi sempre con un livello di sforzo più alto. Un turno che ragiona a lungo non è lento: sta producendo token che non vedi.

La cache dei prompt rende Claude Code più veloce?

Non il ritmo di output. Sui turni da 100 a 500 token, Opus 5 genera a una mediana di 60,6 token al secondo quando la richiesta trova la cache dei prompt e a 58,0 quando non la trova, e il turno intero dura 3,4 secondi contro 3,7. La cache incide su quanto paghi per il contesto, non sulla velocità con cui esce la risposta.

Cos'è la modalità veloce di Claude Code, e quanto è più veloce?

Una configurazione di Claude Opus che Anthropic documenta come fino a 2,5 volte più veloce, a un prezzo per token più alto: 8 dollari per milione di token di input e 40 per milione di token di output su Opus 5.5, 10 e 50 su Opus 5 e Opus 4.8, addebitati sui crediti di utilizzo e non sulle finestre dell'abbonamento. Si attiva con /fast, e accanto al prompt compare una piccola icona a forma di fulmine. Nessuno dei 20.408 turni che abbiamo misurato ha girato in modalità veloce (tutte le trascrizioni dicono speed: standard), quindi non abbiamo un numero misurato; i numeri di questo articolo sono alla velocità standard.