Claude Code, à quelle vitesse ? Les tokens par seconde, mesurés sur 20 000 tours

Claude Code te dit beaucoup de choses sur les tokens. /usage montre ce que tu as consommé de la session et de la semaine, le moniteur de session d'AgentsRoom compte les tokens d'entrée, de sortie, les lectures et les écritures de cache tour par tour, et la ligne de statut peut afficher la part de la fenêtre de contexte utilisée. Aucun d'eux n'imprime le chiffre que les gens cherchent : combien de tokens par seconde le modèle produit vraiment pendant que tu attends.

Le chiffre n'est pas caché, il n'est juste jamais calculé. Chaque message de chaque session atterrit dans une transcription JSONL sous ~/.claude/projects/, et chaque message de l'assistant porte un horodatage et sa consommation de tokens. Alors on l'a calculé, sur notre propre machine, sur les quatre dernières semaines. Voici la méthode, le script, et ce qui en est sorti.

Opus 5.5 : tokens par seconde, mesure du 19 octobre 2026

Nous avons refait la mesure sur les quatre dernières semaines complètes : du 21 septembre au 18 octobre 2026 inclus (UTC). Nous avons inclus le dossier de transcriptions par défaut et les profils Claude supplémentaires utilisés par AgentsRoom, puis compté chaque requête une seule fois entre les fichiers.

Le temps fixe est l'ordonnée à l'origine d'une régression linéaire des secondes écoulées en fonction des tokens de sortie. C'est une estimation du délai incompressible par tour, pas un prix ni une mesure directe du temps jusqu'au premier token. La réflexion est incluse dans les deux débits.

Cette mise à jour corrige aussi le chronométrage. Le parent direct peut être un événement technique, notamment deferred_tools_record, écrit alors que la réponse arrive déjà. Sur une requête, l'ancienne méthode divisait 562 tokens par 0,046 seconde, soit plus de 12 000 tok/s. Remonter les parents jusqu'au message utilisateur ou au résultat d'outil déclencheur restitue environ sept secondes de durée. Avec cette correction et la déduplication des requêtes, aucune requête Opus 5.5 de cette fenêtre ne dépasse 400 tok/s ; nous n'avons pas filtré les débits élevés.

Les tableaux de septembre ci-dessous restent la mesure d'origine. Leur médiane de 94,9 tok/s et leur débit pondéré de 109,3 tok/s utilisent l'ancien chronométrage et un autre échantillon : l'écart ne prouve donc pas qu'Opus 5.5 a ralenti. Ces chiffres décrivent nos tâches, notre réseau et les horodatages des transcriptions, pas un benchmark du modèle isolé.

D'où viennent les données

Claude Code écrit un fichier par session dans ~/.claude/projects/<project slug>/<session id>.jsonl. Une ligne par événement. Les lignes qui comptent ici sont les messages de l'assistant, et chacun ressemble à ceci une fois qu'on ne garde que les champs utiles :

{
  "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"
    }
  }
}

Quatre choses rendent la mesure possible :

• timestamp est écrit au moment où le bloc de contenu est ajouté, donc le dernier bloc d'un tour est daté de la fin du flux.
• parentUuid pointe sur l’événement précédent, qui peut être un événement technique écrit pendant la réponse. Remonter les événements attachment, system et progress jusqu’au message utilisateur ou au résultat d’outil déclencheur : son horodatage donne une approximation du début du tour.
• requestId regroupe les blocs d'un même appel d'API. Un tour qui écrit du texte puis appelle un outil produit deux lignes assistant avec le même requestId et le même usage : les tokens se comptent une fois par requête, pas une fois par ligne.
• usage.output_tokens est la sortie totale de la requête, réflexion comprise ; output_tokens_details.thinking_tokens dit quelle part était de la réflexion.

Rien dans le fichier ne donne le temps jusqu'au premier token. Ce qu'on peut mesurer, c'est le tour entier : du départ de la requête à l'arrivée du dernier token. C'est aussi le seul chiffre que tu ressens en attendant, donc c'est celui qu'on a gardé.

La méthode

Pour chaque requestId : prendre la première et la dernière ligne assistant qui le portent, lire le usage sur la première, remonter ses parents jusqu’au message utilisateur ou au résultat d’outil déclencheur, puis diviser les tokens de sortie par les secondes écoulées jusqu’à la dernière ligne assistant. Compter chaque requête une seule fois entre les fichiers et séparer chaque modèle et réglage de vitesse. Ces horodatages incluent le délai local : ils n’isolent pas le temps de génération de l’API.

Nous écartons les tours sans token de sortie, sans déclencheur retrouvé, à durée négative ou nulle, ou de plus de quinze minutes. Le script ci-dessous utilise la fenêtre de la mise à jour datée, avec un début inclus et une fin exclue en UTC. Modifie START et END pour mesurer une autre période.

Le script actualisé nécessite Python 3.10 ou plus récent, sans dépendance supplémentaire. Lance-le de n’importe où : il lit les projets par défaut et les profils Claude locaux supplémentaires sans envoyer leur contenu.

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 colonne weighted est le total des tokens divisé par le total des secondes. C'est ce que vit un long run autonome ; la médiane est ce que vit un tour interactif.

Les chiffres

Un Mac en France, 319 transcriptions, 20 408 tours entre le 27 août et le 25 septembre 2026, 12,0 millions de tokens de sortie produits en 45 heures de génération. Vitesse standard sur chaque tour (voir le fast mode plus bas). Cinq modèles apparaissent dans les transcriptions, sous les noms que Claude Code écrit.

Deux lectures avant tout le reste. D'abord, Opus 5.5 n'est pas un peu plus rapide qu'Opus 5 : il fait moitié plus sur la médiane et 57 % de mieux sur le chiffre pondéré, avec une part bien plus grande de tours longs. Ensuite, l'écart à l'intérieur d'un modèle est plus large que l'écart entre modèles : un tour d'Opus 5 au 25e centile sort à 51 tokens par seconde, un tour au 75e à 72. La raison, c'est la taille du tour, et elle mérite sa propre section.

Une réponse courte est toujours plus lente

Revoici Opus 5, découpé par le nombre de tokens de sortie du tour :

Même modèle, même mois, même machine, et le débit double entre une réponse d'une ligne et une longue. Le modèle ne sort pas plus vite sur les tours longs. Chaque tour paie un coût fixe avant que le premier token n'apparaisse : la requête part, le prompt est traité, le flux démarre. Sur un tour de 80 tokens, ce coût pèse un tiers du temps écoulé ; sur un tour de 3 000 tokens, il disparaît dans le bruit.

Une régression linéaire de la durée sur les tokens de sortie sépare les deux. La pente donne la vitesse de flux, l'ordonnée à l'origine donne le coût fixe :

Donc quand une session pleine d'appels d'outils paraît lente, ce n'est presque jamais le débit du modèle. C'est le nombre de tours. Un agent qui lit douze fichiers un par un paie douze coûts fixes ; le même agent qui les lit en un seul appel groupé n'en paie qu'un. C'est la même leçon que pour réduire les coûts en tokens : moins de tours, plus gros, pas un modèle plus rapide.

Le plus long tour du corpus fait 21 332 tokens de sortie en 236 secondes sur Opus 5, soit 90 tokens par seconde de bout en bout : une fois le coût fixe amorti, c'est le plafond qu'on a observé sur ce modèle à la vitesse standard.

Les tokens de réflexion sont des tokens de sortie

output_tokens inclut la réflexion que fait le modèle avant de répondre, et output_tokens_details.thinking_tokens dit combien. Dans notre corpus, la réflexion représente 30 % de tout ce qu'Opus 5 a produit, 18 % pour Opus 5.5, 36 % pour Fable 5.1, et 54 % pour Sonnet 5, qu'on a surtout fait tourner avec un niveau de réflexion élevé sur des tâches de relecture.

Ça compte pour lire un tour lent. Un tour qui réfléchit huit secondes et imprime deux lignes n'est pas un modèle lent, c'est un tour qui a produit 600 tokens que tu n'as jamais vus. Les tours avec réflexion sont, par token, légèrement plus rapides que les tours sans : 67 contre 57 tokens par seconde sur Opus 5, parce qu'ils sont plus longs et amortissent mieux le coût fixe. Si une session paraît molle et que tu n'as pas besoin du raisonnement, le levier, c'est le niveau de réflexion, pas le modèle.

Les lectures de cache changent la facture, pas le débit

Presque chaque tour de Claude Code touche le cache de prompt : seuls 130 des 16 680 tours d'Opus 5 avaient cache_read_input_tokens à zéro, et ce sont les premiers tours d'une session. Sur les tours de 100 à 500 tokens de sortie, les tours en cache sortent à 60,6 tokens par seconde en médiane et prennent 3,4 secondes ; les tours hors cache sortent à 58,0 et prennent 3,7 secondes. La différence est réelle mais petite, et elle se loge dans le coût fixe, pas dans la vitesse de flux. Le cache, c'est le prix du contexte que tu transportes, et c'est pour ça que le compteur de tokens du terminal AgentsRoom affiche les lectures et les écritures de cache comme deux chiffres séparés.

Stable sur le mois

Un chiffre cumulé peut cacher une dérive, donc on a aussi regardé la médiane hebdomadaire d'Opus 5 sur les tours de 100 à 500 tokens, les plus fréquents : 63,6, 64,1, 60,9, 61,7, 56,9 tokens par seconde semaine après semaine, puis 68,7 sur la dernière semaine, incomplète. Entre 57 et 69, pas de tendance. Si tes sessions paraissent plus lentes un après-midi, ça vaut le coup de lancer le script sur cette seule journée avant d'accuser le modèle.

Ce que change le fast mode, et ce qu'on n'a pas pu mesurer

Chaque bloc usage porte un champ speed, et les 20 408 nôtres disent standard. Anthropic documente un fast mode pour Claude Opus, activé avec /fast dans le CLI ou "fastMode": true dans les réglages utilisateur, qui rend le modèle jusqu'à 2,5 fois plus rapide à un prix par token plus élevé : 8 dollars par million de tokens d'entrée et 40 par million de tokens de sortie sur Opus 5.5, 10 et 50 sur Opus 5 et Opus 4.8. Sur les forfaits Pro et Max, il est facturé sur les crédits d'usage, hors des fenêtres de l'abonnement ; Sonnet et Haiku ne le supportent pas, et l'activer te bascule sur Opus. Une icône éclair à côté du prompt dit qu'il est actif.

On ne l'a pas payé, donc on n'a pas de chiffre mesuré à mettre à côté des 2,5 fois documentés. Si tu le fais tourner, le même script te dit ce que tu as obtenu : filtre les tours sur usage["speed"] == "fast" et compare les médianes. Envoie-nous les chiffres.

Ce que ça change dans notre façon de faire tourner des agents

Trois choses, aucune ne consiste à choisir un modèle plus rapide.

La première concerne les attentes. Si un run de nuit de sept agents produit deux millions de tokens de sortie, ça fait huit heures de génération à 70 tokens par seconde, réparties entre des agents qui tournent en parallèle. Connaître le débit, c'est ce qui permet de dire si une tâche planifiée peut finir avant que la suivante ne démarre.

La deuxième concerne les tours. La seconde fixe par tour est la même sur une confirmation de 30 tokens et sur un diff de 3 000 tokens. Les agents qui demandent avant chaque petite étape, ou qui lisent les fichiers un par un, passent leur temps dans cette seconde. C'est pour ça qu'on écrit « groupe tes lectures indépendantes » dans les prompts des agents qui tournent sans surveillance.

La troisième concerne ce que le compteur devrait montrer. Le moniteur de session d'AgentsRoom affiche les tokens et le cache, et passe au rouge quand une session devient lourde ; il n'affiche pas de débit, et après cette mesure on n'est pas sûrs qu'il le devrait. Un débit est une propriété du modèle et de la taille du tour, pas de la session, et le chiffre dont un développeur a besoin est celui des tableaux ci-dessus. C'est pour ça que c'est un article et pas un widget.

Questions fréquentes

Combien de tokens par seconde Claude Opus 5.5 génère-t-il ?

Dans notre mesure actualisée le 19 octobre 2026, Claude Opus 5.5 atteint une médiane de 89,4 tokens de sortie par seconde sur 30 119 requêtes uniques du 21 septembre au 18 octobre, toutes en vitesse standard. Le total des tokens de sortie divisé par le total des secondes donne 97,5 tok/s. La réflexion représente 42,1 % des tokens de sortie. Ce sont des mesures de bout en bout issues de nos propres transcriptions, pas un benchmark universel de vitesse de génération.

Combien de tokens par seconde Claude Code produit-il ?

Sur nos 20 408 tours enregistrés entre le 27 août et le 25 septembre 2026 : Opus 5 fait 63 tokens de sortie par seconde en médiane (69 si on divise tous les tokens par toutes les secondes), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) et Opus 4.8 61 (64). Ces chiffres comptent le tour entier, du départ de la requête jusqu'au dernier token reçu : c'est ce que tu attends réellement.

Est-ce que /usage ou /cost affichent les tokens par seconde ?

Non. /usage montre le quota du forfait, les fenêtres de 5 heures et hebdomadaire et la part de la fenêtre de contexte utilisée ; /cost est un alias de /usage. Aucun des deux n'imprime un débit. Le seul endroit où la vitesse existe, c'est la transcription de session sous ~/.claude/projects/, où chaque message de l'assistant porte un horodatage et son nombre de tokens de sortie. C'est ce que lit le script de cet article.

Pourquoi une réponse courte paraît-elle plus lente qu'une longue ?

Parce que chaque tour paie un coût fixe avant l'arrivée du premier token : l'envoi de la requête, le traitement du prompt, le démarrage du flux. Dans nos données, ce coût est d'environ une seconde sur Opus 5 et Opus 5.5 et d'une demi-seconde sur Sonnet 5. Sur une réponse de 80 tokens, une seconde représente un tiers du tour, donc le débit mesuré tombe à 40 tokens par seconde ; sur une réponse de 3 000 tokens, la même seconde disparaît et le débit monte à 80 ou plus. La vitesse de flux elle-même ne bouge pas.

Les tokens de réflexion comptent-ils dans la vitesse ?

Oui. Le bloc usage de chaque message rapporte output_tokens avec un détail output_tokens_details.thinking_tokens, et les tokens de réflexion font partie d'output_tokens. Dans notre corpus, ils représentent 30 % de tout ce qu'Opus 5 a produit, 18 % pour Opus 5.5 et 54 % pour Sonnet 5, qui a surtout tourné avec un niveau de réflexion élevé. Un tour qui réfléchit longtemps n'est pas lent : il produit des tokens que tu ne vois pas.

Le cache de prompt rend-il Claude Code plus rapide ?

Pas le débit de sortie. Sur les tours de 100 à 500 tokens, Opus 5 sort à 60,6 tokens par seconde en médiane quand la requête touche le cache de prompt et à 58,0 quand elle ne le touche pas, et le tour entier prend 3,4 secondes contre 3,7. Le cache joue sur ce que tu paies pour le contexte, pas sur la vitesse à laquelle la réponse sort.

Qu'est-ce que le fast mode de Claude Code, et combien de fois plus vite va-t-il ?

Une configuration de Claude Opus qu'Anthropic documente comme jusqu'à 2,5 fois plus rapide, à un prix par token plus élevé : 8 dollars par million de tokens d'entrée et 40 par million de tokens de sortie sur Opus 5.5, 10 et 50 sur Opus 5 et Opus 4.8, facturés sur les crédits d'usage et non sur les fenêtres de l'abonnement. On l'active avec /fast, et une petite icône éclair apparaît à côté du prompt. Aucun des 20 408 tours mesurés n'a tourné en fast mode (toutes les transcriptions disent speed: standard), donc nous n'avons pas de chiffre mesuré pour lui ; les chiffres de cet article sont à la vitesse standard.