Hoe snel is Claude Code? Tokens per seconde, gemeten over 20.000 beurten

Claude Code vertelt je veel over tokens. /usage toont hoeveel je van de sessie en van de week hebt gebruikt, de sessiemonitor in AgentsRoom telt invoer, uitvoer, cache-lezingen en cache-schrijvingen beurt voor beurt, en de statusregel kan het gebruikte deel van het contextvenster tonen. Geen van hen toont het ene cijfer waar mensen steeds naar zoeken: hoeveel tokens per seconde het model echt produceert terwijl je wacht.

Het cijfer is niet verborgen, het wordt alleen nooit berekend. Elk bericht van elke sessie belandt in een JSONL-transcript onder ~/.claude/projects/, en elk bericht van de assistent draagt een tijdstempel en zijn tokenverbruik mee. Dus hebben we het berekend, op onze eigen machine, over de afgelopen vier weken. Dit zijn de methode, het script en wat eruit kwam.

Opus 5.5 tokens per seconde: update van 19 oktober 2026

We hebben de meting opnieuw gedraaid op de laatste vier volledige weken: van 21 september tot en met 18 oktober 2026 (UTC). We hebben de standaardmap met transcripten en de extra Claude-profielen die AgentsRoom gebruikt meegenomen, en daarna elk verzoek over alle bestanden heen maar één keer geteld.

De vaste aanlooptijd is het snijpunt met de as van een kleinstekwadratenregressie van de verstreken seconden op de uitvoertokens. Het is een schatting van de tijdsoverhead per beurt, geen prijs en geen directe meting van de tijd tot het eerste token. Denkwerk is in beide snelheden inbegrepen.

Deze update corrigeert ook de tijdmeting. Een directe parent kan een technische bijlage zijn, waaronder deferred_tools_record, die wordt geschreven terwijl het antwoord al binnenkomt. Bij één verzoek deelde de oude methode 562 tokens door 0,046 seconde, wat meer dan 12.000 tok/s opleverde. Door de keten van parents terug te volgen tot het bericht van de gebruiker of het toolresultaat dat de beurt in gang zette, komt er ongeveer zeven seconden verstreken tijd terug. Met die correctie en de deduplicatie van verzoeken komt geen enkel Opus 5.5-verzoek in deze periode boven 400 tok/s; we hebben hoge snelheden niet weggefilterd.

De septembertabellen hieronder blijven de oorspronkelijke meting. Hun mediaan van 94,9 tok/s en hun gewogen snelheid van 109,3 tok/s gebruiken de oude tijdmeting en een andere steekproef, dus het verschil bewijst niet dat Opus 5.5 trager is geworden. Deze cijfers beschrijven onze werklast, ons netwerk en de tijdstempels van onze transcripten, geen geïsoleerde benchmark van het model.

Waar de data vandaan komt

Claude Code schrijft één bestand per sessie in ~/.claude/projects/<project slug>/<session id>.jsonl. Eén regel per gebeurtenis. De regels die hier tellen zijn de berichten van de assistent, en elk ziet er zo uit als je alleen de nuttige velden bewaart:

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

Vier dingen maken de meting mogelijk:

• timestamp wordt geschreven wanneer het inhoudsblok wordt toegevoegd, dus het laatste blok van een beurt is gedateerd op het einde van de stream.
• parentUuid wijst naar de voorafgaande gebeurtenis, die een technische bijlage kan zijn die tijdens het antwoord is geschreven. Volg de keten voorbij de gebeurtenissen attachment, system en progress tot het bericht van de gebruiker of het toolresultaat dat de beurt in gang zette; de tijdstempel daarvan is een benadering van het begin van de beurt.
• requestId groepeert de blokken van één API-aanroep. Een beurt die wat tekst schrijft en daarna een tool aanroept, levert twee assistentregels op met dezelfde requestId en dezelfde usage, dus tokens moeten één keer per verzoek worden geteld, niet één keer per regel.
• usage.output_tokens is de totale uitvoer van het verzoek, denkwerk inbegrepen; output_tokens_details.thinking_tokens zegt hoeveel daarvan denkwerk was.

Niets in het bestand geeft de tijd tot het eerste token. Wat je kunt meten is de hele beurt: van het verzoek dat je machine verlaat tot het laatste token dat aankomt. Dat is ook het enige cijfer dat je voelt terwijl je wacht, dus dat is het cijfer dat we hebben gehouden.

De methode

Voor elke requestId: neem de eerste en de laatste assistentregel die hem dragen, lees het verbruik uit de eerste, volg de keten van parents tot het bericht van de gebruiker of het toolresultaat dat de beurt in gang zette, en deel de uitvoertokens door de verstreken seconden tot de laatste assistentregel. Tel een verzoek over alle bestanden heen maar één keer, en rapporteer elk model en elke snelheidsinstelling apart. Deze tijdstempels bevatten ook lokale vertraging; ze isoleren niet de generatietijd van de API.

We laten beurten weg zonder uitvoertokens, zonder teruggevonden trigger, met een duur van nul of minder of met een duur van meer dan vijftien minuten. Het script hieronder gebruikt de periode van de gedateerde update, met een inclusief begin en een exclusief einde in UTC. Pas START en END aan om een andere periode te meten.

Het bijgewerkte script vereist Python 3.10 of nieuwer en geen extra afhankelijkheden. Draai het van waar je maar wilt; het leest de standaardprojecten en de extra lokale Claude-profielen zonder hun inhoud te uploaden.

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}%")

De kolom weighted is het totaal aantal tokens gedeeld door het totaal aantal seconden. Dat is wat een lange autonome run ervaart; de mediaan is wat één interactieve beurt ervaart.

De cijfers

Eén Mac in Frankrijk, 319 transcripten, 20.408 beurten tussen 27 augustus en 25 september 2026, 12,0 miljoen uitvoertokens geproduceerd in 45 uur generatie. Standaardsnelheid bij elke beurt (zie de Fast-modus verderop). Vijf modellen komen in de transcripten voor, onder de namen die Claude Code schrijft.

Twee lezingen voor al het andere. Ten eerste is Opus 5.5 niet een beetje sneller dan Opus 5: het is anderhalf keer zo snel op de mediaan en 57 % sneller op het gewogen cijfer, met een veel groter aandeel lange beurten. Ten tweede is de spreiding binnen een model groter dan het verschil tussen modellen: een Opus 5-beurt op het 25e percentiel streamt met 51 tokens per seconde en een op het 75e met 72. De reden is de omvang van de beurt, en die verdient een eigen sectie.

Een kort antwoord is altijd trager

Hier is Opus 5 nog eens, opgedeeld naar het aantal uitvoertokens in de beurt:

Zelfde model, zelfde maand, zelfde machine, en de snelheid verdubbelt tussen een antwoord van één regel en een lang antwoord. Het model streamt niet sneller bij lange beurten. Elke beurt betaalt een vaste aanlooptijd voordat het eerste token verschijnt: het verzoek gaat eruit, de prompt wordt verwerkt, de stream start. Bij een beurt van 80 tokens is die aanlooptijd een derde van de verstreken tijd; bij een beurt van 3.000 tokens verdwijnt hij in de ruis.

Een lineaire regressie van de duur op de uitvoertokens haalt de twee uit elkaar. De helling geeft de streamsnelheid, het snijpunt met de as geeft de vaste aanlooptijd:

Dus wanneer een sessie vol toolaanroepen traag aanvoelt, ligt het zelden aan de doorvoer van het model. Het ligt aan het aantal beurten. Een agent die twaalf bestanden één voor één leest, betaalt twaalf keer de vaste aanlooptijd; dezelfde agent die ze in één gebundelde aanroep leest, betaalt die één keer. Dat is dezelfde les als bij het verlagen van tokenkosten: minder en grotere beurten, geen sneller model.

De langste enkele beurt van het corpus is 21.332 uitvoertokens in 236 seconden op Opus 5, oftewel 90 tokens per seconde van begin tot eind: zodra de vaste aanlooptijd is terugverdiend, is dat het plafond dat we op dat model bij standaardsnelheid hebben gezien.

Denktokens zijn uitvoertokens

output_tokens omvat het denkwerk dat het model doet voordat het antwoordt, en output_tokens_details.thinking_tokens vertelt je hoeveel. In ons corpus is denkwerk 30 % van alles wat Opus 5 produceerde, 18 % voor Opus 5.5, 36 % voor Fable 5.1 en 54 % voor Sonnet 5, dat we vooral op een hoger inspanningsniveau voor reviewtaken lieten draaien.

Dat is belangrijk om een trage beurt goed te lezen. Een beurt die acht seconden nadenkt en twee regels afdrukt, is geen traag model, het is een beurt die 600 tokens heeft geproduceerd die je nooit hebt gezien. Beurten met denkwerk zijn per token iets sneller dan beurten zonder: 67 tegenover 57 tokens per seconde op Opus 5, omdat ze langer zijn en de vaste aanlooptijd beter terugverdienen. Als een sessie traag aanvoelt en je het redeneren niet nodig hebt, is het inspanningsniveau de hefboom, niet het model.

Cache-lezingen veranderen de rekening, niet de snelheid

Bijna elke beurt in Claude Code raakt de promptcache: slechts 130 van de 16.680 Opus 5-beurten hadden cache_read_input_tokens op nul, en dat zijn de eerste beurten van een sessie. Bij beurten van 100 tot 500 uitvoertokens streamen de gecachete met een mediaan van 60,6 tokens per seconde en duren ze 3,4 seconden; de niet-gecachete streamen met 58,0 en duren 3,7 seconden. Het verschil is echt maar klein, en het zit in de vaste aanlooptijd, niet in de streamsnelheid. Bij de cache gaat het om de prijs van de context die je meesleept, en daarom toont de tokenteller in de AgentsRoom-terminal cache-lezingen en cache-schrijvingen als aparte cijfers.

Stabiel over de maand

Een cumulatief cijfer kan een verschuiving verbergen, dus hebben we ook gekeken naar de wekelijkse mediaan van Opus 5 bij beurten van 100 tot 500 tokens, de meest voorkomende soort: 63,6, 64,1, 60,9, 61,7, 56,9 tokens per seconde week na week, daarna 68,7 in de onvolledige laatste week. Tussen 57 en 69, geen trend. Als je sessies op een middag trager aanvoelen, is het de moeite waard om het script alleen op die dag te draaien voordat je het model de schuld geeft.

Wat de Fast-modus verandert, en wat we niet konden meten

Elk usage-blok draagt een veld speed, en alle 20.408 van ons zeggen standard. Anthropic documenteert een Fast-modus voor Claude Opus, in te schakelen met /fast in de CLI of met "fastMode": true in de gebruikersinstellingen, die het model tot 2,5 keer sneller maakt tegen een hogere prijs per token: 8 dollar per miljoen invoertokens en 40 per miljoen uitvoertokens op Opus 5.5, 10 en 50 op Opus 5 en Opus 4.8. Op de abonnementen Pro en Max wordt hij gefactureerd op gebruikstegoed, buiten de vensters van het abonnement; Sonnet en Haiku ondersteunen hem niet, en als je hem inschakelt, stap je over op Opus. Een bliksemicoon naast de prompt laat zien dat hij aan staat.

We hebben er niet voor betaald, dus we hebben geen gemeten cijfer om naast de gedocumenteerde 2,5 keer te zetten. Als je hem wel gebruikt, vertelt hetzelfde script je wat je kreeg: filter de beurten op usage["speed"] == "fast" en vergelijk de medianen. Stuur ons de cijfers.

Wat dit verandert aan hoe wij agents laten draaien

Drie dingen, en geen daarvan gaat over het kiezen van een sneller model.

Het eerste gaat over verwachtingen. Als een nachtelijke run van zeven agents twee miljoen uitvoertokens produceert, is dat acht uur generatie tegen 70 tokens per seconde, verdeeld over agents die parallel draaien. De snelheid kennen is wat je laat zeggen of een geplande taak klaar kan zijn voordat de volgende start.

Het tweede gaat over beurten. De vaste seconde per beurt is dezelfde bij een bevestiging van 30 tokens en bij een diff van 3.000 tokens. Agents die voor elke kleine stap iets vragen, of die bestanden één voor één lezen, brengen hun tijd in die seconde door. Daarom schrijven we „bundel je onafhankelijke leesacties” in de prompts van de agents die zonder toezicht draaien.

Het derde gaat over wat de teller zou moeten tonen. De sessiemonitor in AgentsRoom toont tokens en cache, en kleurt rood wanneer een sessie zwaar wordt; hij toont geen snelheid, en na deze meting weten we niet zeker of hij dat zou moeten. Een snelheid is een eigenschap van het model en van de omvang van de beurt, niet van de sessie, en het cijfer dat een ontwikkelaar nodig heeft staat in de tabellen hierboven. Daarom is dit een artikel en geen widget.

Veelgestelde vragen

Hoeveel tokens per seconde genereert Claude Opus 5.5?

In onze meting, bijgewerkt op 19 oktober 2026, haalde Claude Opus 5.5 een mediaan van 89,4 uitvoertokens per seconde over 30.119 unieke verzoeken van 21 september tot 18 oktober, allemaal op standaardsnelheid. Het totaal aantal uitvoertokens gedeeld door het totaal aantal verstreken seconden geeft 97,5 tok/s. Denkwerk is goed voor 42,1 % van de uitvoertokens. Dit zijn end-to-end-metingen uit de transcripten van onze eigen sessies, geen universele benchmark van de streamsnelheid.

Hoeveel tokens per seconde genereert Claude Code?

Over onze 20.408 beurten, vastgelegd tussen 27 augustus en 25 september 2026: Opus 5 haalt een mediaan van 63 uitvoertokens per seconde (69 als je alle tokens door alle seconden deelt), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80) en Opus 4.8 61 (64). Deze cijfers tellen de hele beurt, vanaf het moment dat het verzoek je machine verlaat tot het laatste gestreamde token, dus het is precies de tijd waarop je echt wacht.

Tonen /usage of /cost de tokens per seconde?

Nee. /usage toont het quotum van je abonnement, het venster van 5 uur en dat van een week en het gebruikte deel van het contextvenster; /cost is een alias van /usage. Geen van beide geeft een snelheid. De enige plek waar de snelheid bestaat, is het sessietranscript onder ~/.claude/projects/, waar elk bericht van de assistent een tijdstempel en zijn aantal uitvoertokens meedraagt. Dat is wat het script in dit artikel leest.

Waarom voelt een kort antwoord trager dan een lang?

Omdat elke beurt een vaste aanlooptijd betaalt voordat het eerste token aankomt: het verzoek uploaden, de prompt verwerken, de stream starten. In onze data is die overhead ongeveer een seconde op Opus 5 en Opus 5.5 en een halve seconde op Sonnet 5. Bij een antwoord van 80 tokens is een seconde een derde van de beurt, dus zakt de gemeten snelheid naar 40 tokens per seconde; bij een antwoord van 3.000 tokens verdwijnt diezelfde seconde en klimt de snelheid naar 80 of meer. De streamsnelheid zelf blijft constant.

Tellen denktokens mee in de snelheid?

Ja. Het usage-blok van elk bericht meldt output_tokens met een uitsplitsing output_tokens_details.thinking_tokens, en de denktokens maken deel uit van output_tokens. In ons corpus zijn ze 30 % van alles wat Opus 5 produceerde, 18 % voor Opus 5.5 en 54 % voor Sonnet 5, dat vooral op een hoger inspanningsniveau draaide. Een beurt die lang nadenkt is niet traag: hij produceert tokens die je niet ziet.

Maakt de promptcache Claude Code sneller?

Niet de uitvoersnelheid. Bij beurten van 100 tot 500 tokens streamt Opus 5 met een mediaan van 60,6 tokens per seconde wanneer het verzoek de promptcache raakt en met 58,0 wanneer dat niet zo is, en de hele beurt duurt 3,4 seconden tegenover 3,7. Bij de cache gaat het om wat je voor de context betaalt, niet om hoe snel het antwoord eruit komt.

Wat is de Fast-modus van Claude Code, en hoeveel sneller is die?

Een configuratie van Claude Opus die Anthropic documenteert als tot 2,5 keer sneller, tegen een hogere prijs per token: 8 dollar per miljoen invoertokens en 40 per miljoen uitvoertokens op Opus 5.5, 10 en 50 op Opus 5 en Opus 4.8, gefactureerd op gebruikstegoed in plaats van op de vensters van het abonnement. Je schakelt hem in met /fast, en naast de prompt verschijnt een klein bliksemicoon. Geen van de 20.408 gemeten beurten draaide in de Fast-modus (elk transcript zegt speed: standard), dus we hebben er geen gemeten cijfer voor; de cijfers in dit artikel gelden voor de standaardsnelheid.