Наскільки швидкий 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), тому виміряної цифри для нього в нас немає; цифри в цій статті наведено для стандартної швидкості.