Jak szybki jest Claude Code? Tokeny na sekundę zmierzone na 20 000 tur

Claude Code mówi ci sporo o tokenach. /usage pokazuje, ile sesji i tygodnia już wykorzystałeś, monitor sesji w AgentsRoom liczy tura po turze tokeny wejściowe, wyjściowe, odczyty i zapisy pamięci podręcznej, a pasek stanu może wyświetlać zajętą część okna kontekstu. Żadne z nich nie pokazuje tej jednej liczby, której ludzie wciąż szukają: ile tokenów na sekundę model naprawdę generuje, kiedy ty czekasz.

Ta liczba nie jest ukryta, po prostu nikt jej nie liczy. Każda wiadomość z każdej sesji trafia do transkryptu JSONL w ~/.claude/projects/, a każda wiadomość asystenta ma znacznik czasu i swoje zużycie tokenów. Więc ją policzyliśmy, na własnym komputerze, z ostatnich czterech tygodni. Oto metoda, skrypt i wyniki.

Skąd pochodzą dane

Claude Code zapisuje jeden plik na sesję w ~/.claude/projects/<project slug>/<session id>.jsonl. Jedna linia na zdarzenie. Liczą się tu linie z wiadomościami asystenta, a każda z nich wygląda tak, gdy zostawisz tylko przydatne pola:

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

Cztery rzeczy umożliwiają pomiar:

• timestamp jest zapisywany w chwili dopisania bloku treści, więc ostatni blok tury ma datę końca strumienia.
• parentUuid wskazuje na linię tuż przed nią, czyli wiadomość użytkownika albo wynik narzędzia, na który model odpowiadał. Jej znacznik czasu to moment wysłania żądania.
• requestId grupuje bloki jednego wywołania API. Tura, która pisze trochę tekstu, a potem wywołuje narzędzie, tworzy dwie linie asystenta z tym samym requestId i tym samym usage, więc tokeny trzeba liczyć raz na żądanie, a nie raz na linię.
• usage.output_tokens to całe wyjście żądania, łącznie z rozumowaniem; output_tokens_details.thinking_tokens mówi, ile z tego było rozumowaniem.

Nic w pliku nie podaje czasu do pierwszego tokena. Zmierzyć da się całą turę: od wysłania żądania z twojego komputera do przyjścia ostatniego tokena. To też jedyna liczba, którą odczuwasz, czekając, więc to ją zostawiliśmy.

Metoda

Dla każdego requestId: weź pierwszą i ostatnią linię asystenta, które go mają, odczytaj zużycie z pierwszej, znajdź rodzica pierwszej linii i podziel tokeny wyjściowe przez liczbę sekund między znacznikiem czasu rodzica a znacznikiem ostatniej linii. Potem patrz na rozkład dla każdego modelu, nigdy na pojedynczą średnią, bo tura trwająca 40 sekund i tura trwająca 2 sekundy to nie ten sam obiekt.

Odrzuciliśmy tury bez tokenów wyjściowych, tury o czasie trwania zerowym lub ujemnym (wznowiona sesja może mieć rodzica z datą późniejszą niż jego dziecko) oraz tury dłuższe niż piętnaście minut, które są raczej przerwanymi sesjami niż długimi odpowiedziami. Nic więcej nie było filtrowane.

Skrypt to 40 linii Pythona bez żadnych zależności. Uruchom go z dowolnego miejsca; czyta wszystkie projekty na komputerze.

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

Kolumna weighted to łączna liczba tokenów podzielona przez łączną liczbę sekund. Tego doświadcza długie autonomiczne uruchomienie; mediana to to, czego doświadcza pojedyncza interaktywna tura.

Liczby

Jeden Mac we Francji, 319 transkryptów, 20 408 tur między 27 sierpnia a 25 września 2026, 12,0 miliona tokenów wyjściowych wygenerowanych w ciągu 45 godzin generowania. Standardowa szybkość w każdej turze (zobacz tryb Fast niżej). W transkryptach pojawia się pięć modeli, pod nazwami, które zapisuje Claude Code.

Dwa wnioski przed wszystkim innym. Po pierwsze, Opus 5.5 nie jest odrobinę szybszy od Opus 5: w medianie jest o połowę szybszy, a w wartości ważonej o 57%, przy dużo większym udziale długich tur. Po drugie, rozrzut wewnątrz jednego modelu jest większy niż różnica między modelami: tura Opus 5 na 25. percentylu generuje 51 tokenów na sekundę, a tura na 75. percentylu 72. Przyczyną jest rozmiar tury i zasługuje ona na osobną sekcję.

Krótka odpowiedź jest zawsze wolniejsza

Oto znowu Opus 5, podzielony według liczby tokenów wyjściowych w turze:

Ten sam model, ten sam miesiąc, ten sam komputer, a tempo podwaja się między odpowiedzią na jedną linię a długą odpowiedzią. Model nie strumieniuje szybciej w długich turach. Każda tura płaci stały narzut czasowy, zanim pojawi się pierwszy token: żądanie wychodzi, prompt jest przetwarzany, strumień startuje. W turze z 80 tokenami ten narzut to jedna trzecia upływającego czasu; w turze z 3 000 tokenów ginie w szumie.

Regresja liniowa czasu trwania względem tokenów wyjściowych rozdziela jedno od drugiego. Nachylenie daje szybkość strumieniowania, wyraz wolny daje stały narzut:

Więc kiedy sesja pełna wywołań narzędzi wydaje się wolna, rzadko chodzi o przepustowość modelu. Chodzi o liczbę tur. Agent, który czyta dwanaście plików po kolei, płaci dwanaście stałych narzutów; ten sam agent czytający je w jednym zbiorczym wywołaniu płaci jeden. To ta sama lekcja co przy obniżaniu kosztów tokenów: mniej tur, ale większych, a nie szybszy model.

Najdłuższa pojedyncza tura w korpusie to 21 332 tokeny wyjściowe w ciągu 236 sekund na Opus 5, czyli 90 tokenów na sekundę od początku do końca: po amortyzacji stałego narzutu to sufit, który zaobserwowaliśmy na tym modelu przy standardowej szybkości.

Tokeny rozumowania to tokeny wyjściowe

output_tokens obejmuje rozumowanie, które model wykonuje przed odpowiedzią, a output_tokens_details.thinking_tokens mówi ci, ile go było. W naszym korpusie rozumowanie stanowi 30% wszystkiego, co wygenerował Opus 5, 18% w przypadku Opus 5.5, 36% w przypadku Fable 5.1 i 54% w przypadku Sonnet 5, którego uruchamialiśmy głównie na wyższym poziomie wysiłku przy zadaniach przeglądu kodu.

To ważne, gdy odczytujesz wolną turę. Tura, która rozumuje przez osiem sekund i wypisuje dwie linie, to nie wolny model, tylko tura, która wygenerowała 600 tokenów, których nigdy nie zobaczyłeś. Tury z rozumowaniem są, w przeliczeniu na token, nieco szybsze od tur bez niego: 67 wobec 57 tokenów na sekundę na Opus 5, bo są dłuższe i lepiej amortyzują stały narzut. Jeśli sesja wydaje się ociężała, a nie potrzebujesz rozumowania, dźwignią jest poziom wysiłku, a nie model.

Odczyty z pamięci podręcznej zmieniają rachunek, nie tempo

Prawie każda tura w Claude Code trafia w pamięć podręczną promptów: tylko 130 z 16 680 tur Opus 5 miało cache_read_input_tokens równe zero, i są to pierwsze tury sesji. Na turach od 100 do 500 tokenów wyjściowych tury z pamięci podręcznej mają medianę 60,6 tokena na sekundę i trwają 3,4 sekundy; tury bez niej mają 58,0 i trwają 3,7 sekundy. Różnica jest prawdziwa, ale mała, i siedzi w stałym narzucie, a nie w szybkości strumieniowania. Pamięć podręczna dotyczy ceny kontekstu, który ze sobą niesiesz, i dlatego licznik tokenów w terminalu AgentsRoom pokazuje odczyty i zapisy pamięci podręcznej jako osobne wartości.

Stabilnie przez cały miesiąc

Liczba skumulowana może ukrywać dryf, więc sprawdziliśmy też tygodniową medianę Opus 5 na turach od 100 do 500 tokenów, najczęstszym rodzaju: 63,6, 64,1, 60,9, 61,7, 56,9 tokena na sekundę tydzień po tygodniu, a potem 68,7 w niepełnym ostatnim tygodniu. Między 57 a 69, bez trendu. Jeśli twoje sesje wydają się wolniejsze któregoś popołudnia, warto uruchomić skrypt tylko dla tego dnia, zanim zrzucisz winę na model.

Co zmienia tryb Fast i czego nie mogliśmy zmierzyć

Każdy blok usage ma pole speed, a we wszystkich 20 408 naszych jest standard. Anthropic opisuje tryb Fast dla Claude Opus, włączany poleceniem /fast w CLI albo przez "fastMode": true w ustawieniach użytkownika, który przyspiesza model do 2,5 raza przy wyższej cenie za token: 8 dolarów za milion tokenów wejściowych i 40 za milion tokenów wyjściowych na Opus 5.5, 10 i 50 na Opus 5 i Opus 4.8. W planach Pro i Max jest rozliczany z kredytów użycia, poza oknami subskrypcji; Sonnet i Haiku go nie obsługują, a jego włączenie przełącza cię na Opus. Ikona błyskawicy obok promptu informuje, że jest aktywny.

Nie płaciliśmy za niego, więc nie mamy zmierzonej wartości, którą moglibyśmy postawić obok udokumentowanych 2,5 raza. Jeśli go używasz, ten sam skrypt powie ci, co dostałeś: przefiltruj tury po usage["speed"] == "fast" i porównaj mediany. Przyślij nam wyniki.

Co to zmienia w tym, jak uruchamiamy agentów

Trzy rzeczy i żadna nie polega na wyborze szybszego modelu.

Pierwsza dotyczy oczekiwań. Jeśli nocne uruchomienie siedmiu agentów generuje dwa miliony tokenów wyjściowych, to osiem godzin generowania przy 70 tokenach na sekundę, rozłożonych na agentów działających równolegle. Znajomość tempa pozwala powiedzieć, czy zaplanowane zadanie zdąży się skończyć, zanim wystartuje następne.

Druga dotyczy tur. Stała sekunda na turę jest taka sama przy potwierdzeniu z 30 tokenów i przy diffie z 3 000 tokenów. Agenci, którzy pytają przed każdym małym krokiem albo czytają pliki po jednym, spędzają czas właśnie w tej sekundzie. Dlatego w promptach agentów działających bez nadzoru piszemy „grupuj niezależne odczyty”.

Trzecia dotyczy tego, co powinien pokazywać licznik. Monitor sesji w AgentsRoom pokazuje tokeny i pamięć podręczną oraz robi się czerwony, gdy sesja robi się ciężka; nie pokazuje tempa i po tym pomiarze nie jesteśmy pewni, czy powinien. Tempo to cecha modelu i rozmiaru tury, a nie sesji, a liczba, której potrzebuje programista, jest w tabelach powyżej. Dlatego to jest artykuł, a nie widżet.

Najczęściej zadawane pytania

Ile tokenów na sekundę generuje Claude Code?

Na naszych 20 408 turach zarejestrowanych między 27 sierpnia a 25 września 2026: mediana Opus 5 wynosi 63 tokeny wyjściowe na sekundę (69, jeśli podzielisz wszystkie tokeny przez wszystkie sekundy), Opus 5.5 95 (109), Sonnet 5 77 (87), Fable 5.1 75 (80), a Opus 4.8 61 (64). Te liczby obejmują całą turę, od chwili, gdy żądanie opuszcza twój komputer, do ostatniego przesłanego tokena, więc to dokładnie ten czas, na który naprawdę czekasz.

Czy /usage albo /cost pokazują tokeny na sekundę?

Nie. /usage pokazuje limit twojego planu, okno pięciogodzinne i tygodniowe oraz zajętą część okna kontekstu; /cost to alias /usage. Żadne z nich nie wypisuje tempa. Jedyne miejsce, w którym ta szybkość istnieje, to transkrypt sesji w ~/.claude/projects/, gdzie każda wiadomość asystenta ma znacznik czasu i swoją liczbę tokenów wyjściowych. Właśnie to czyta skrypt z tego artykułu.

Dlaczego krótka odpowiedź wydaje się wolniejsza od długiej?

Bo każda tura płaci stały narzut czasowy, zanim dotrze pierwszy token: wysłanie żądania, przetworzenie promptu, start strumienia. W naszych danych ten narzut to około sekundy na Opus 5 i Opus 5.5 oraz pół sekundy na Sonnet 5. Przy odpowiedzi z 80 tokenami jedna sekunda to jedna trzecia tury, więc zmierzone tempo spada do 40 tokenów na sekundę; przy odpowiedzi z 3 000 tokenów ta sama sekunda znika, a tempo rośnie do 80 lub więcej. Sama szybkość strumieniowania się nie zmienia.

Czy tokeny rozumowania liczą się do szybkości?

Tak. Blok usage każdej wiadomości podaje output_tokens z rozbiciem output_tokens_details.thinking_tokens, a tokeny rozumowania są częścią output_tokens. W naszym korpusie stanowią 30% wszystkiego, co wygenerował Opus 5, 18% w przypadku Opus 5.5 i 54% w przypadku Sonnet 5, który działał głównie na wyższym poziomie wysiłku. Tura, która długo rozumuje, nie jest wolna: generuje tokeny, których nie widzisz.

Czy pamięć podręczna promptów przyspiesza Claude Code?

Nie tempo generowania. Na turach od 100 do 500 tokenów mediana Opus 5 to 60,6 tokena na sekundę, gdy żądanie trafia w pamięć podręczną promptów, i 58,0, gdy nie trafia, a cała tura trwa 3,4 sekundy wobec 3,7. Pamięć podręczna wpływa na to, ile płacisz za kontekst, a nie na to, jak szybko wychodzi odpowiedź.

Czym jest tryb Fast w Claude Code i o ile jest szybszy?

To konfiguracja Claude Opus, którą Anthropic opisuje jako do 2,5 raza szybszą, przy wyższej cenie za token: 8 dolarów za milion tokenów wejściowych i 40 za milion tokenów wyjściowych na Opus 5.5, 10 i 50 na Opus 5 i Opus 4.8, rozliczane z kredytów użycia, a nie z okien subskrypcji. Przełączasz go poleceniem /fast, a obok promptu pojawia się mała ikona błyskawicy. Żadna z 20 408 zmierzonych tur nie działała w trybie Fast (każdy transkrypt mówi speed: standard), więc nie mamy dla niego zmierzonej wartości; liczby w tym artykule dotyczą standardowej szybkości.