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.

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 regel er vlak voor, het bericht van de gebruiker of het toolresultaat waarop het model antwoordde. De tijdstempel daarvan is het moment waarop het verzoek vertrok.
• 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, zoek de parent van de eerste regel, en deel de uitvoertokens door de seconden tussen de tijdstempel van de parent en die van de laatste regel. Kijk daarna naar de verdeling per model, nooit naar één enkel gemiddelde, want een beurt van 40 seconden en een beurt van 2 seconden zijn niet hetzelfde object.

We hebben beurten zonder uitvoertokens weggelaten, beurten met een duur van nul of minder (een hervatte sessie kan een parent hebben die na zijn kind is gedateerd) en beurten van meer dan vijftien minuten, die eerder onderbroken sessies zijn dan lange antwoorden. Verder is er niets gefilterd.

Het script is 40 regels Python zonder afhankelijkheden. Draai het van waar je maar wilt; het leest elk project op de machine.

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

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