Насколько быстр Claude Code? Токены в секунду, измеренные на 20 000 ходов

Claude Code многое рассказывает о токенах. /usage показывает, какую часть сессии и недели ты уже израсходовал, монитор сессий в AgentsRoom считает входные и выходные токены, чтение и запись кэша ход за ходом, а строка состояния может выводить занятую долю контекстного окна. Ни один из них не показывает то единственное число, которое люди продолжают искать: сколько токенов в секунду модель на самом деле производит, пока ты ждёшь.

Это число не спрятано, его просто никто не считает. Каждое сообщение каждой сессии попадает в JSONL-транскрипт в ~/.claude/projects/, и каждое сообщение ассистента несёт временную метку и расход токенов. Так что мы посчитали его сами, на своей машине, за последние четыре недели. Вот метод, скрипт и то, что получилось.

Откуда берутся данные

Claude Code пишет по одному файлу на сессию в ~/.claude/projects/<project slug>/<session id>.jsonl. Одна строка на событие. Здесь важны строки с сообщениями ассистента, и каждая выглядит так, если оставить только полезные поля:

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

Измерение возможно благодаря четырём вещам:

• timestamp записывается в момент добавления блока контента, поэтому последний блок хода датирован концом потоковой выдачи.
• parentUuid указывает на строку прямо перед ним: сообщение пользователя или результат инструмента, на который отвечала модель. Её временная метка это момент, когда ушёл запрос.
• requestId группирует блоки одного вызова API. Ход, который пишет немного текста, а затем вызывает инструмент, создаёт две строки ассистента с одинаковым requestId и одинаковым usage, поэтому токены нужно считать один раз на запрос, а не один раз на строку.
• usage.output_tokens это весь вывод запроса, включая рассуждение; output_tokens_details.thinking_tokens показывает, какая его часть пришлась на рассуждение.

Ничто в файле не даёт время до первого токена. Измерить можно весь ход: от ухода запроса с твоей машины до прихода последнего токена. Это ещё и единственное число, которое ты ощущаешь, пока ждёшь, поэтому мы оставили именно его.

Метод

Для каждого requestId: взять первую и последнюю строки ассистента с этим идентификатором, прочитать usage из первой, найти родителя первой строки и разделить выходные токены на число секунд между временной меткой родителя и временной меткой последней строки. Затем смотреть на распределение по каждой модели, а не на одно среднее, потому что ход в 40 секунд и ход в 2 секунды это разные вещи.

Мы отбросили ходы без выходных токенов, ходы с неположительной длительностью (у возобновлённой сессии родитель может быть датирован позже потомка) и ходы длиннее пятнадцати минут: это прерванные сессии, а не длинные ответы. Больше ничего не фильтровалось.

Скрипт занимает 40 строк на Python без зависимостей. Запускай его откуда угодно: он читает все проекты на машине.

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

Колонка weighted это сумма токенов, делённая на сумму секунд. Так скорость ощущает длинный автономный прогон; медиана показывает, как её ощущает отдельный интерактивный ход.

Цифры

Один Mac во Франции, 319 транскриптов, 20 408 ходов с 27 августа по 25 сентября 2026 года, 12,0 миллиона выходных токенов за 45 часов генерации. Стандартная скорость на каждом ходе (про быстрый режим ниже). В транскриптах встречаются пять моделей, под теми названиями, которые пишет Claude Code.

Сначала два наблюдения. Во-первых, Opus 5.5 не чуть-чуть быстрее Opus 5: по медиане он быстрее в полтора раза, а по взвешенной скорости на 57%, притом что длинных ходов у него гораздо больше. Во-вторых, разброс внутри одной модели шире, чем разрыв между моделями: ход Opus 5 на 25-м перцентиле выдаёт 51 токен в секунду, а на 75-м 72. Причина в размере хода, и она заслуживает отдельного раздела.

Короткий ответ всегда медленнее

Снова Opus 5, теперь в разбивке по числу выходных токенов в ходе:

Та же модель, тот же месяц, та же машина, а скорость между однострочным ответом и длинным удваивается. На длинных ходах модель не выдаёт поток быстрее. Каждый ход несёт фиксированные затраты времени, прежде чем появится первый токен: запрос уходит, промпт обрабатывается, потоковая выдача стартует. На ходе в 80 токенов эти затраты составляют треть прошедшего времени; на ходе в 3 000 токенов они теряются в шуме.

Линейная регрессия длительности по выходным токенам методом наименьших квадратов разделяет эти две составляющие. Наклон даёт скорость потоковой выдачи, свободный член даёт фиксированные затраты:

Поэтому, когда сессия с кучей вызовов инструментов кажется медленной, дело редко в пропускной способности модели. Дело в числе ходов. Агент, который читает двенадцать файлов по одному, двенадцать раз платит фиксированные затраты; тот же агент, читающий их одним пакетным вызовом, платит один раз. Это тот же урок, что и в статье о том, как сократить расходы на токены: меньше ходов, но крупнее, а не более быстрая модель.

Самый длинный ход корпуса: 21 332 выходных токена за 236 секунд на Opus 5, то есть 90 токенов в секунду от начала до конца. Когда фиксированные затраты амортизированы, это потолок, который мы наблюдали на этой модели при стандартной скорости.

Токены рассуждения тоже выходные токены

output_tokens включает рассуждение, которое модель проводит перед ответом, а output_tokens_details.thinking_tokens показывает его объём. В нашем корпусе рассуждение составляет 30% всего, что выдал Opus 5, 18% у Opus 5.5, 36% у Fable 5.1 и 54% у Sonnet 5, который мы в основном запускали на более высоком уровне усилий для задач ревью.

Это важно, когда разбираешь медленный ход. Ход, который рассуждает восемь секунд и выводит две строки, это не медленная модель, а ход, который произвёл 600 токенов, которых ты так и не увидел. Ходы с рассуждением в пересчёте на токен даже немного быстрее ходов без него: 67 против 57 токенов в секунду на Opus 5, потому что они длиннее и лучше амортизируют фиксированные затраты. Если сессия кажется вялой, а рассуждение тебе не нужно, рычаг здесь уровень усилий, а не модель.

Чтение кэша меняет счёт, а не скорость

Почти каждый ход в Claude Code попадает в кэш промптов: только у 130 из 16 680 ходов Opus 5 значение cache_read_input_tokens было равно нулю, и это первые ходы сессий. На ходах от 100 до 500 выходных токенов кэшированные выдают в медиане 60,6 токена в секунду и занимают 3,4 секунды; некэшированные выдают 58,0 и занимают 3,7 секунды. Разница реальна, но мала, и она сидит в фиксированных затратах, а не в скорости потоковой выдачи. Кэширование касается цены контекста, который ты несёшь с собой, и именно поэтому счётчик токенов в терминале AgentsRoom показывает чтение и запись кэша отдельными цифрами.

Стабильно в течение месяца

Накопленное число может скрыть дрейф, поэтому мы посмотрели и на недельную медиану Opus 5 на ходах от 100 до 500 токенов, самых частых: 63,6, 64,1, 60,9, 61,7, 56,9 токена в секунду неделя за неделей, затем 68,7 за последнюю, неполную неделю. Между 57 и 69, без тренда. Если однажды днём твои сессии кажутся медленнее, стоит прогнать скрипт только по этому дню, прежде чем винить модель.

Что меняет быстрый режим и что мы не смогли измерить

Каждый блок usage содержит поле speed, и во всех наших 20 408 там стоит standard. Anthropic описывает быстрый режим для Claude Opus, который включается командой /fast в CLI или "fastMode": true в пользовательских настройках и делает модель до 2,5 раза быстрее при более высокой цене за токен: 8 долларов за миллион входных токенов и 40 за миллион выходных на Opus 5.5, 10 и 50 на Opus 5 и Opus 4.8. На тарифах Pro и Max он списывается с кредитов использования, вне окон подписки; Sonnet и Haiku его не поддерживают, а его включение переключает тебя на Opus. Иконка молнии рядом с полем промпта показывает, что он включён.

Мы за него не платили, поэтому измеренной цифры, которую можно поставить рядом с заявленными 2,5 раза, у нас нет. Если ты им пользуешься, тот же скрипт покажет, что ты получил: отфильтруй ходы по usage["speed"] == "fast" и сравни медианы. Пришли нам цифры.

Что это меняет в том, как мы запускаем агентов

Три вещи, и ни одна не про выбор более быстрой модели.

Первая касается ожиданий. Если ночной прогон семи агентов производит два миллиона выходных токенов, это восемь часов генерации при 70 токенах в секунду, распределённых между агентами, которые работают параллельно. Зная скорость, можно сказать, успеет ли запланированная задача закончиться до старта следующей.

Вторая касается ходов. Фиксированная секунда на ход одинакова и для подтверждения в 30 токенов, и для диффа в 3 000 токенов. Агенты, которые спрашивают перед каждым мелким шагом или читают файлы по одному, проводят своё время в этой секунде. Поэтому мы пишем «группируй независимые чтения» в промпты агентов, которые работают без присмотра.

Третья касается того, что должен показывать счётчик. Монитор сессий в AgentsRoom показывает токены и кэш и краснеет, когда сессия становится тяжёлой; скорость он не показывает, и после этого измерения мы не уверены, что должен. Скорость это свойство модели и размера хода, а не сессии, и число, которое нужно разработчику, есть в таблицах выше. Поэтому это статья, а не виджет.

Частые вопросы

Сколько токенов в секунду генерирует Claude Code?

На наших 20 408 ходах, записанных с 27 августа по 25 сентября 2026 года: у Opus 5 медиана 63 выходных токена в секунду (69, если разделить все токены на все секунды), у Opus 5.5 95 (109), у Sonnet 5 77 (87), у Fable 5.1 75 (80) и у Opus 4.8 61 (64). Эти цифры охватывают весь ход, от момента, когда запрос уходит с твоей машины, до последнего полученного токена, так что это ровно то время, которое ты реально ждёшь.

Показывают ли /usage или /cost токены в секунду?

Нет. /usage показывает квоту твоего тарифа, 5-часовое и недельное окна и занятую долю контекстного окна; /cost это псевдоним /usage. Ни одна из команд не выводит скорость. Единственное место, где скорость существует, это транскрипт сессии в ~/.claude/projects/, где каждое сообщение ассистента несёт временную метку и число выходных токенов. Именно его читает скрипт из этой статьи.

Почему короткий ответ кажется медленнее длинного?

Потому что каждый ход несёт фиксированные затраты времени до прихода первого токена: отправка запроса, обработка промпта, запуск потоковой выдачи. В наших данных эти накладные расходы составляют около секунды на Opus 5 и Opus 5.5 и полсекунды на Sonnet 5. На ответе в 80 токенов одна секунда это треть хода, поэтому измеренная скорость падает до 40 токенов в секунду; на ответе в 3 000 токенов та же секунда растворяется, и скорость поднимается до 80 и выше. Сама скорость потоковой выдачи постоянна.

Учитываются ли токены рассуждения в скорости?

Да. Блок usage каждого сообщения сообщает output_tokens с разбивкой output_tokens_details.thinking_tokens, и токены рассуждения входят в output_tokens. В нашем корпусе они составляют 30% всего, что выдал Opus 5, 18% у Opus 5.5 и 54% у Sonnet 5, который в основном работал на более высоком уровне усилий. Ход, который долго рассуждает, не медленный: он производит токены, которых ты не видишь.

Делает ли кэширование промптов Claude Code быстрее?

Скорость вывода нет. На ходах от 100 до 500 токенов Opus 5 выдаёт в медиане 60,6 токена в секунду, когда запрос попадает в кэш промптов, и 58,0, когда не попадает, а весь ход занимает 3,4 секунды против 3,7. Кэширование влияет на то, сколько ты платишь за контекст, а не на то, как быстро выходит ответ.

Что такое быстрый режим Claude Code и насколько он быстрее?

Это конфигурация Claude Opus, которую Anthropic описывает как работающую до 2,5 раза быстрее, по более высокой цене за токен: 8 долларов за миллион входных токенов и 40 за миллион выходных на Opus 5.5, 10 и 50 на Opus 5 и Opus 4.8, со списанием с кредитов использования, а не с окон подписки. Он включается командой /fast, и рядом с полем промпта появляется маленькая иконка молнии. Ни один из 20 408 измеренных нами ходов не шёл в быстром режиме (каждый транскрипт пишет speed: standard), поэтому измеренной цифры для него у нас нет; цифры в этой статье даны для стандартной скорости.