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.

Token al secondo di Opus 5.5: aggiornamento del 19 ottobre 2026

Abbiamo ripetuto la misura sulle ultime quattro settimane complete: dal 21 settembre al 18 ottobre 2026 (UTC). Abbiamo incluso la cartella predefinita delle trascrizioni e i profili Claude aggiuntivi usati da AgentsRoom, poi abbiamo contato ogni richiesta una sola volta tra tutti i file.

Il tempo fisso è l'intercetta di una regressione ai minimi quadrati dei secondi trascorsi rispetto ai token di output. È una stima del tempo aggiuntivo per turno, non un prezzo né una misura diretta del tempo fino al primo token. Il ragionamento è incluso in entrambi i ritmi.

Questo aggiornamento corregge anche la cronometrazione. Il genitore diretto può essere un allegato tecnico, compreso deferred_tools_record, scritto quando la risposta sta già arrivando. Su una richiesta, il vecchio metodo divideva 562 token per 0,046 secondi, ottenendo oltre 12.000 tok/s. Risalire la catena dei genitori fino al messaggio dell'utente o al risultato dello strumento che ha avviato il turno recupera circa sette secondi di tempo trascorso. Con questa correzione e la deduplicazione delle richieste, nessuna richiesta di Opus 5.5 in questo periodo supera i 400 tok/s; non abbiamo filtrato i ritmi alti.

Le tabelle di settembre qui sotto restano la misura originale. La loro mediana di 94,9 tok/s e il loro ritmo ponderato di 109,3 tok/s usano la vecchia cronometrazione e un campione diverso, quindi la differenza non dimostra che Opus 5.5 sia diventato più lento. Questi numeri descrivono i nostri carichi di lavoro, la nostra rete e i timestamp delle trascrizioni, non un benchmark del modello isolato.

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 all'evento precedente, che può essere un allegato tecnico scritto durante la risposta. Segui la catena oltre gli eventi attachment, system e progress fino al messaggio dell'utente o al risultato dello strumento che ha avviato il turno; il suo timestamp è un'approssimazione dell'inizio del turno.
• 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, risali la sua catena di genitori fino al messaggio dell'utente o al risultato dello strumento che ha avviato il turno, e dividi i token di output per i secondi trascorsi fino all'ultima riga dell'assistente. Conta ogni richiesta una sola volta tra i file e riporta separatamente ogni modello e ogni impostazione di velocità. Questi timestamp includono il tempo aggiuntivo locale: non isolano il tempo di generazione dell'API.

Scartiamo i turni senza token di output, senza un messaggio di avvio ritrovato, con una durata negativa o nulla o con una durata superiore a quindici minuti. Lo script qui sotto usa il periodo dell'aggiornamento datato, con inizio incluso e fine esclusa, in UTC. Modifica START e END per misurare un altro periodo.

Lo script aggiornato richiede Python 3.10 o successivo e nessuna dipendenza aggiuntiva. Lancialo da qualsiasi cartella: legge i progetti predefiniti e i profili Claude locali aggiuntivi senza inviarne il contenuto.

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

START, END = "2026-09-21", "2026-10-19"  # UTC, end exclusive
PATTERNS = ("~/.claude/projects/*/*.jsonl",
            "~/.agentsroom/claude-profiles/*/projects/*/*.jsonl")

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

def read_session(path):
    by_uuid, groups = {}, defaultdict(list)
    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"):
                groups[o.get("requestId") or o["uuid"]].append(o)
    return by_uuid, groups

def trigger(first, by_uuid):
    parent, visited = by_uuid.get(first.get("parentUuid")), set()
    while parent and parent.get("type") in ("attachment", "system", "progress"):
        uid = parent.get("uuid")
        if uid in visited: return None
        visited.add(uid)
        parent = by_uuid.get(parent.get("parentUuid"))
    return parent if parent and parent.get("type") == "user" else None

by_model, seen = defaultdict(list), set()
for pattern in PATTERNS:
    for path in glob.glob(os.path.expanduser(pattern)):
        by_uuid, groups = read_session(path)
        for rid, blocks in groups.items():
            first, last = blocks[0], blocks[-1]
            if rid in seen or not START <= first["timestamp"] < END: continue
            usage = first["message"]["usage"]
            out, parent = usage.get("output_tokens", 0), trigger(first, by_uuid)
            if not parent or not parent.get("timestamp") or out <= 0: continue
            dur = ts(last["timestamp"]) - ts(parent["timestamp"])
            if not 0 < dur <= 900: continue
            seen.add(rid)
            thinking = (usage.get("output_tokens_details") or {}).get("thinking_tokens", 0)
            key = first["message"].get("model"), usage.get("speed", "unknown")
            by_model[key].append((out, dur, thinking))

for (model, speed), rows in sorted(by_model.items(), key=lambda kv: -len(kv[1])):
    outputs, durations, thinking = zip(*rows)
    median = st.median(o / d for o, d, _ in rows)
    weighted = sum(outputs) / sum(durations)
    overhead = st.linear_regression(outputs, durations).intercept if len(set(outputs)) > 1 else float("nan")
    print(f"{model} {speed}: turns={len(rows)} median={median:.1f} "
          f"weighted={weighted:.1f} tok/s overhead={overhead:.2f}s "
          f"thinking={100 * sum(thinking) / sum(outputs):.1f}%")

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 Opus 5.5?

Nella nostra misura aggiornata al 19 ottobre 2026, Claude Opus 5.5 ha raggiunto una mediana di 89,4 token di output al secondo su 30.119 richieste uniche dal 21 settembre al 18 ottobre, tutte alla velocità standard. Il totale dei token di output diviso per il totale dei secondi trascorsi dà 97,5 tok/s. Il ragionamento rappresenta il 42,1% dei token di output. Sono misure end-to-end ricavate dalle trascrizioni delle nostre sessioni, non un benchmark universale della velocità di streaming.

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.