Wie schnell ist Claude Code? Tokens pro Sekunde, gemessen an 20.000 Runden

Claude Code sagt dir viel über Tokens. /usage zeigt, wie viel von der Sitzung und von der Woche du verbraucht hast, der Sitzungsmonitor in AgentsRoom zählt Eingabe, Ausgabe, Cache-Lesevorgänge und Cache-Schreibvorgänge Runde für Runde, und die Statuszeile kann den belegten Anteil des Kontextfensters anzeigen. Keines davon zeigt die eine Zahl, nach der alle immer wieder suchen: wie viele Tokens pro Sekunde das Modell tatsächlich erzeugt, während du wartest.

Die Zahl ist nicht versteckt, sie wird nur nie berechnet. Jede Nachricht jeder Sitzung landet in einem JSONL-Transkript unter ~/.claude/projects/, und jede Nachricht des Assistenten trägt einen Zeitstempel und ihren Token-Verbrauch. Also haben wir sie berechnet, auf unserem eigenen Rechner, über die letzten vier Wochen. Hier sind die Methode, das Skript und das Ergebnis.

Opus 5.5 Tokens pro Sekunde: Aktualisierung vom 19. Oktober 2026

Wir haben die Messung über die letzten vier vollständigen Wochen wiederholt: vom 21. September bis einschließlich 18. Oktober 2026 (UTC). Einbezogen haben wir das Standardverzeichnis der Transkripte und die zusätzlichen Claude-Profile, die AgentsRoom verwendet, und dann jede Anfrage über alle Dateien hinweg nur einmal gezählt.

Die feste Anlaufzeit ist der Achsenabschnitt einer Regression der verstrichenen Sekunden auf die Ausgabetokens nach der Methode der kleinsten Quadrate. Sie ist eine Schätzung des zeitlichen Mehraufwands pro Runde, kein Preis und keine direkte Messung der Zeit bis zum ersten Token. Das Denken ist in beiden Raten enthalten.

Diese Aktualisierung korrigiert auch die Zeitmessung. Ein direkter Parent kann ein technischer Anhang sein, etwa deferred_tools_record, der geschrieben wird, während die Antwort bereits eintrifft. Bei einer Anfrage teilte die alte Methode 562 Tokens durch 0,046 Sekunden und kam so auf über 12.000 tok/s. Folgt man der Parent-Kette zurück bis zur auslösenden Nachricht des Nutzers oder zum auslösenden Tool-Ergebnis, kommen rund sieben Sekunden verstrichene Zeit wieder hinzu. Mit dieser Korrektur und der Deduplizierung der Anfragen überschreitet keine Opus-5.5-Anfrage in diesem Zeitraum 400 tok/s; hohe Raten haben wir nicht herausgefiltert.

Die Septembertabellen weiter unten bleiben die ursprüngliche Messung. Ihr Median von 94,9 tok/s und ihre gewichtete Rate von 109,3 tok/s beruhen auf der alten Zeitmessung und einer anderen Stichprobe, daher belegt der Unterschied nicht, dass Opus 5.5 langsamer geworden ist. Diese Zahlen beschreiben unsere Arbeitslasten, unser Netzwerk und die Zeitstempel unserer Transkripte, keinen isolierten Benchmark des Modells.

Woher die Daten kommen

Claude Code schreibt eine Datei pro Sitzung nach ~/.claude/projects/<project slug>/<session id>.jsonl. Eine Zeile pro Ereignis. Die Zeilen, die hier zählen, sind die Nachrichten des Assistenten, und jede sieht so aus, wenn du nur die nützlichen Felder behältst:

{
  "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 Dinge machen die Messung möglich:

• timestamp wird geschrieben, wenn der Inhaltsblock angehängt wird, also ist der letzte Block einer Runde auf das Ende des Streams datiert.
• parentUuid zeigt auf das vorhergehende Ereignis, das ein technischer Anhang sein kann, der während der Antwort geschrieben wurde. Folge der Kette über die Ereignisse attachment, system und progress hinweg bis zur auslösenden Nachricht des Nutzers oder zum auslösenden Tool-Ergebnis; der Zeitstempel dieses Ereignisses ist eine Näherung für den Beginn der Runde.
• requestId gruppiert die Blöcke eines API-Aufrufs. Eine Runde, die etwas Text schreibt und dann ein Tool aufruft, erzeugt zwei Assistenten-Zeilen mit derselben requestId und demselben usage, also müssen die Tokens einmal pro Anfrage gezählt werden, nicht einmal pro Zeile.
• usage.output_tokens ist die gesamte Ausgabe der Anfrage, Denken inklusive; output_tokens_details.thinking_tokens sagt, wie viel davon Denken war.

Nichts in der Datei liefert die Zeit bis zum ersten Token. Was du messen kannst, ist die ganze Runde: vom Abgang der Anfrage von deinem Rechner bis zur Ankunft des letzten Tokens. Das ist auch die einzige Zahl, die du beim Warten spürst, also haben wir diese behalten.

Die Methode

Für jede requestId: Nimm die erste und die letzte Assistenten-Zeile, die sie trägt, lies den Verbrauch aus der ersten, folge ihrer Parent-Kette bis zur auslösenden Nachricht des Nutzers oder zum auslösenden Tool-Ergebnis und teile die Ausgabetokens durch die bis zur letzten Assistenten-Zeile verstrichenen Sekunden. Zähle eine Anfrage über alle Dateien hinweg nur einmal und weise jedes Modell und jede Geschwindigkeitseinstellung getrennt aus. Diese Zeitstempel enthalten auch lokale Verzögerungen; sie isolieren nicht die Generierungszeit der API.

Wir verwerfen Runden ohne Ausgabetokens, ohne auffindbaren Auslöser, mit einer Dauer von null oder weniger oder mit einer Dauer über fünfzehn Minuten. Das Skript unten verwendet den Zeitraum der datierten Aktualisierung, mit einem inklusiven Start und einem exklusiven Ende in UTC. Ändere START und END, um einen anderen Zeitraum zu messen.

Das aktualisierte Skript benötigt Python 3.10 oder neuer und keine zusätzlichen Abhängigkeiten. Starte es von überall aus; es liest die Standardprojekte und die zusätzlichen lokalen Claude-Profile, ohne ihren Inhalt hochzuladen.

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

Die Spalte weighted ist die Gesamtzahl der Tokens geteilt durch die Gesamtzahl der Sekunden. Das erlebt ein langer autonomer Lauf; der Median ist das, was eine einzelne interaktive Runde erlebt.

Die Zahlen

Ein Mac in Frankreich, 319 Transkripte, 20.408 Runden zwischen dem 27. August und dem 25. September 2026, 12,0 Millionen Ausgabetokens, erzeugt in 45 Stunden Generierung. Standardgeschwindigkeit in jeder Runde (siehe Fast-Modus weiter unten). Fünf Modelle tauchen in den Transkripten auf, unter den Namen, die Claude Code schreibt.

Zwei Lesarten vor allem anderen. Erstens ist Opus 5.5 nicht ein bisschen schneller als Opus 5, sondern im Median um die Hälfte schneller und beim gewichteten Wert um 57 %, bei einem viel höheren Anteil langer Runden. Zweitens ist die Streuung innerhalb eines Modells größer als der Abstand zwischen den Modellen: Eine Opus-5-Runde am 25. Perzentil streamt mit 51 Tokens pro Sekunde, eine am 75. mit 72. Der Grund ist die Größe der Runde, und die verdient einen eigenen Abschnitt.

Eine kurze Antwort ist immer langsamer

Hier noch einmal Opus 5, aufgeteilt nach der Anzahl der Ausgabetokens in der Runde:

Gleiches Modell, gleicher Monat, gleicher Rechner, und die Rate verdoppelt sich zwischen einer einzeiligen Antwort und einer langen. Das Modell streamt in langen Runden nicht schneller. Jede Runde zahlt eine feste Anlaufzeit, bevor der erste Token erscheint: Die Anfrage geht raus, der Prompt wird verarbeitet, der Stream startet. Bei einer Runde mit 80 Tokens ist diese Anlaufzeit ein Drittel der verstrichenen Zeit; bei einer Runde mit 3.000 Tokens geht sie im Rauschen unter.

Eine lineare Regression der Dauer auf die Ausgabetokens trennt beides. Die Steigung liefert die Streaming-Geschwindigkeit, der Achsenabschnitt die feste Anlaufzeit:

Wenn sich also eine Sitzung voller Tool-Aufrufe langsam anfühlt, liegt es selten am Durchsatz des Modells. Es liegt an der Anzahl der Runden. Ein Agent, der zwölf Dateien einzeln liest, zahlt zwölf feste Anlaufzeiten; derselbe Agent, der sie in einem gebündelten Aufruf liest, zahlt eine. Das ist dieselbe Lehre wie beim Senken der Token-Kosten: weniger, größere Runden, kein schnelleres Modell.

Die längste einzelne Runde des Korpus hat 21.332 Ausgabetokens in 236 Sekunden auf Opus 5, also 90 Tokens pro Sekunde von Anfang bis Ende: Sobald die feste Anlaufzeit amortisiert ist, ist das die Obergrenze, die wir auf diesem Modell bei Standardgeschwindigkeit beobachtet haben.

Denk-Tokens sind Ausgabetokens

output_tokens enthält das Denken, das das Modell vor der Antwort erledigt, und output_tokens_details.thinking_tokens sagt dir, wie viel. In unserem Korpus macht Denken 30 % von allem aus, was Opus 5 erzeugt hat, 18 % bei Opus 5.5, 36 % bei Fable 5.1 und 54 % bei Sonnet 5, das wir überwiegend mit einem höheren Reasoning-Aufwand für Review-Aufgaben laufen ließen.

Das ist wichtig, um eine langsame Runde richtig zu lesen. Eine Runde, die acht Sekunden nachdenkt und zwei Zeilen ausgibt, ist kein langsames Modell, sondern eine Runde, die 600 Tokens erzeugt hat, die du nie gesehen hast. Runden mit Denken sind pro Token etwas schneller als Runden ohne: 67 gegenüber 57 Tokens pro Sekunde auf Opus 5, weil sie länger sind und die feste Anlaufzeit besser amortisieren. Wenn sich eine Sitzung träge anfühlt und du das Reasoning nicht brauchst, ist der Reasoning-Aufwand der Hebel, nicht das Modell.

Cache-Lesevorgänge ändern die Rechnung, nicht die Rate

Fast jede Runde in Claude Code trifft den Prompt-Cache: Nur 130 der 16.680 Opus-5-Runden hatten cache_read_input_tokens bei null, und das sind jeweils die erste Runde einer Sitzung. Bei Runden mit 100 bis 500 Ausgabetokens streamen die gecachten im Median mit 60,6 Tokens pro Sekunde und brauchen 3,4 Sekunden; die ungecachten streamen mit 58,0 und brauchen 3,7 Sekunden. Der Unterschied ist real, aber klein, und er steckt in der festen Anlaufzeit, nicht in der Streaming-Geschwindigkeit. Beim Cache geht es um den Preis des Kontexts, den du mitschleppst, und deshalb zeigt der Token-Zähler im AgentsRoom-Terminal Cache-Lesevorgänge und Cache-Schreibvorgänge als getrennte Werte.

Stabil über den Monat

Eine kumulierte Zahl kann eine Drift verbergen, also haben wir uns auch den wöchentlichen Median von Opus 5 bei Runden mit 100 bis 500 Tokens angesehen, der häufigsten Art: 63,6, 64,1, 60,9, 61,7, 56,9 Tokens pro Sekunde, Woche für Woche, dann 68,7 in der unvollständigen letzten Woche. Zwischen 57 und 69, kein Trend. Wenn sich deine Sitzungen an einem Nachmittag langsamer anfühlen, lohnt es sich, das Skript nur für diesen Tag laufen zu lassen, bevor du dem Modell die Schuld gibst.

Was der Fast-Modus ändert und was wir nicht messen konnten

Jeder usage-Block trägt ein Feld speed, und alle 20.408 von unseren sagen standard. Anthropic dokumentiert einen Fast-Modus für Claude Opus, eingeschaltet mit /fast in der CLI oder mit "fastMode": true in den Benutzereinstellungen, der das Modell bis zu 2,5-mal schneller macht, zu einem höheren Preis pro Token: 8 Dollar pro Million Eingabetokens und 40 pro Million Ausgabetokens auf Opus 5.5, 10 und 50 auf Opus 5 und Opus 4.8. In den Tarifen Pro und Max wird er über Nutzungsguthaben abgerechnet, außerhalb der Fenster des Abos; Sonnet und Haiku unterstützen ihn nicht, und wenn du ihn einschaltest, wechselst du auf Opus. Ein Blitzsymbol neben dem Prompt zeigt, dass er aktiv ist.

Wir haben nicht dafür bezahlt, also haben wir keinen gemessenen Wert, den wir neben die dokumentierten 2,5-mal stellen könnten. Wenn du ihn nutzt, sagt dir dasselbe Skript, was du bekommen hast: Filtere die Runden auf usage["speed"] == "fast" und vergleiche die Mediane. Schick uns die Zahlen.

Was das an der Art ändert, wie wir Agenten laufen lassen

Drei Dinge, und bei keinem geht es darum, ein schnelleres Modell zu wählen.

Das erste betrifft die Erwartungen. Wenn ein nächtlicher Lauf von sieben Agenten zwei Millionen Ausgabetokens erzeugt, sind das acht Stunden Generierung bei 70 Tokens pro Sekunde, verteilt auf Agenten, die parallel laufen. Die Rate zu kennen ist das, was dir erlaubt zu sagen, ob eine geplante Aufgabe fertig werden kann, bevor die nächste startet.

Das zweite betrifft die Runden. Die feste Sekunde pro Runde ist dieselbe bei einer Bestätigung mit 30 Tokens und bei einem Diff mit 3.000 Tokens. Agenten, die vor jedem kleinen Schritt nachfragen oder Dateien einzeln lesen, verbringen ihre Zeit in dieser Sekunde. Deshalb schreiben wir „bündle deine unabhängigen Lesezugriffe“ in die Prompts der Agenten, die unbeaufsichtigt laufen.

Das dritte betrifft das, was der Zähler zeigen sollte. Der Sitzungsmonitor in AgentsRoom zeigt Tokens und Cache und wird rot, wenn eine Sitzung schwer wird; er zeigt keine Rate, und nach dieser Messung sind wir nicht sicher, dass er das sollte. Eine Rate ist eine Eigenschaft des Modells und der Rundengröße, nicht der Sitzung, und die Zahl, die ein Entwickler braucht, steht in den Tabellen oben. Deshalb ist das ein Artikel und kein Widget.

Häufig gestellte Fragen

Wie viele Tokens pro Sekunde erzeugt Claude Opus 5.5?

In unserer am 19. Oktober 2026 aktualisierten Messung erreichte Claude Opus 5.5 im Median 89,4 Ausgabetokens pro Sekunde über 30.119 eindeutige Anfragen vom 21. September bis zum 18. Oktober, alle bei Standardgeschwindigkeit. Die Gesamtzahl der Ausgabetokens geteilt durch die Gesamtzahl der verstrichenen Sekunden ergibt 97,5 tok/s. Denken macht 42,1 % der Ausgabetokens aus. Das sind End-to-End-Messungen aus den Transkripten unserer eigenen Sitzungen, kein universeller Benchmark der Streaming-Geschwindigkeit.

Wie viele Tokens pro Sekunde erzeugt Claude Code?

Auf unseren 20.408 Runden, aufgezeichnet zwischen dem 27. August und dem 25. September 2026: Opus 5 kommt im Median auf 63 Ausgabetokens pro Sekunde (69, wenn du alle Tokens durch alle Sekunden teilst), Opus 5.5 auf 95 (109), Sonnet 5 auf 77 (87), Fable 5.1 auf 75 (80) und Opus 4.8 auf 61 (64). Diese Zahlen zählen die ganze Runde, vom Moment, in dem die Anfrage deinen Rechner verlässt, bis zum letzten gestreamten Token. Das ist also genau die Zeit, auf die du wirklich wartest.

Zeigen /usage oder /cost die Tokens pro Sekunde an?

Nein. /usage zeigt das Kontingent deines Abos, das 5-Stunden- und das Wochenfenster und den belegten Anteil des Kontextfensters; /cost ist ein Alias von /usage. Keiner der beiden gibt eine Rate aus. Der einzige Ort, an dem die Geschwindigkeit existiert, ist das Sitzungstranskript unter ~/.claude/projects/, wo jede Nachricht des Assistenten einen Zeitstempel und ihre Anzahl an Ausgabetokens trägt. Genau das liest das Skript in diesem Artikel.

Warum fühlt sich eine kurze Antwort langsamer an als eine lange?

Weil jede Runde eine feste Anlaufzeit zahlt, bevor der erste Token ankommt: das Hochladen der Anfrage, die Verarbeitung des Prompts, der Start des Streams. In unseren Daten liegt dieser Aufschlag bei etwa einer Sekunde auf Opus 5 und Opus 5.5 und bei einer halben Sekunde auf Sonnet 5. Bei einer Antwort mit 80 Tokens ist eine Sekunde ein Drittel der Runde, also fällt die gemessene Rate auf 40 Tokens pro Sekunde; bei einer Antwort mit 3.000 Tokens verschwindet dieselbe Sekunde und die Rate steigt auf 80 oder mehr. Die Streaming-Geschwindigkeit selbst bleibt konstant.

Zählen Denk-Tokens bei der Geschwindigkeit mit?

Ja. Der usage-Block jeder Nachricht meldet output_tokens mit einer Aufschlüsselung output_tokens_details.thinking_tokens, und die Denk-Tokens sind Teil von output_tokens. In unserem Korpus machen sie 30 % von allem aus, was Opus 5 erzeugt hat, 18 % bei Opus 5.5 und 54 % bei Sonnet 5, das überwiegend mit einem höheren Reasoning-Aufwand lief. Eine Runde, die lange nachdenkt, ist nicht langsam: Sie erzeugt Tokens, die du nicht siehst.

Macht Prompt-Caching Claude Code schneller?

Nicht die Ausgaberate. Bei Runden mit 100 bis 500 Tokens streamt Opus 5 im Median mit 60,6 Tokens pro Sekunde, wenn die Anfrage den Prompt-Cache trifft, und mit 58,0, wenn nicht, und die ganze Runde dauert 3,4 Sekunden gegenüber 3,7. Beim Cache geht es darum, was du für den Kontext bezahlst, nicht darum, wie schnell die Antwort herauskommt.

Was ist der Fast-Modus von Claude Code, und wie viel schneller ist er?

Eine Konfiguration von Claude Opus, die Anthropic als bis zu 2,5-mal schneller dokumentiert, zu einem höheren Preis pro Token: 8 Dollar pro Million Eingabetokens und 40 pro Million Ausgabetokens auf Opus 5.5, 10 und 50 auf Opus 5 und Opus 4.8, abgerechnet über Nutzungsguthaben statt über die Fenster des Abos. Du schaltest ihn mit /fast um, und neben dem Prompt erscheint ein kleines Blitzsymbol. Keine der 20.408 gemessenen Runden lief im Fast-Modus (jedes Transkript sagt speed: standard), daher haben wir dafür keinen gemessenen Wert; die Zahlen in diesem Artikel gelten für die Standardgeschwindigkeit.