Claude Code: расход по сессиям — как узнать, какая сессия съедает ваш тариф

Запустите несколько сессий Claude Code параллельно, и недельный лимит начнёт таять быстрее, чем вы ожидаете. Хочется понять, какая сессия его съедает, но /usage этого не скажет.

Коротко: по состоянию на сентябрь 2026 года нет ни одного официального экрана, который показывал бы, какую долю расхода взяла каждая сессия. /usage выдаёт цифры текущей сессии, а также расход по всему тарифу в процентах по навыкам, субагентам, плагинам и серверам MCP. Если нужна разбивка по сессиям, придётся самим подсчитать логи диалогов, которые хранятся на вашем компьютере.

Только считать эти логи в лоб нельзя: получится неверно. Когда я замерил логи за последние 7 дней на своём компьютере, простое сложение строк дало итог в 2,06 раза больше правильного. Хуже того, даже среди 12 самых тяжёлых сессий множитель этой ошибки колебался от 1,30 до 3,02, поэтому менялся и порядок мест. В статье разобрано, что показывают официальные экраны, как считать правильно, скрипт подсчёта примерно на 50 строк и что показали мои замеры.

1. Что показывают официальные экраны, а что нет

Вот основные официальные места, где отображается расход (по состоянию на сентябрь 2026 года). Ни одно из них не показывает долю каждой сессии. Ближе всего разбивка по тарифу в /usage, но её ось — на какую функцию ушёл расход, а не какая сессия его израсходовала.

Источник: официальная документация Claude Code, «Manage costs effectively» (/usage, /insights, дашборды для организаций), официальная документация Claude Code, «Desktop» (кольцо расхода), Справочный центр Claude, «Usage limit best practices» (страница расхода в настройках), официальная документация Claude Code, «Monitoring» (OpenTelemetry)

О разбивке по тарифу в /usage документация говорит ещё одну важную вещь: «Цифры приблизительные и вычисляются по локальной истории сессий на этом компьютере, поэтому расход с других устройств или claude.ai не учитывается». Иначе говоря, даже официальная разбивка в конечном счёте берётся из ваших локальных логов. Прочитайте те же логи сами, и вы сможете подсчитать их по оси, которую официальные экраны не показывают: по сессиям. Если вы уже упёрлись в лимит и хотите проверить остаток, загляните в статью Claude Code «usage limit reached»: причины и решения.

2. Ответ лежит в локальных логах диалогов

Claude Code сохраняет полную запись каждого диалога в формате JSONL (один JSON-объект на строку), по одному файлу на сессию. Где они лежат, сказано в документации.

Источник: официальная документация Claude Code, «Explore the .claude directory»

На моём компьютере имя папки <проект> было абсолютным путём рабочей папки, в котором символы заменены на - (D:\work\site-a превращается в D--work-site-a). Сессии, запущенные на вкладке Code десктопного приложения, записывались туда же, и в каждой строке стояло "entrypoint":"claude-desktop".

Подсчитывать нужно поле usage в строках, где записаны ответы Claude ("type":"assistant"). Вот одна реальная строка, сокращённая до полей, которые нужны для подсчёта (идентификаторы скрыты).

{"type":"assistant","requestId":"req_…","timestamp":"2026-07-25T00:16:37.822Z",
 "message":{"id":"msg_…","model":"claude-opus-5",
  "content":[{"type":"text","text":"…"}],
  "usage":{"input_tokens":2,"output_tokens":255,
           "cache_read_input_tokens":33775,"cache_creation_input_tokens":17265,
           "cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":17265}}}}

Четыре числа в usage (ввод, вывод, чтение кэша, запись в кэш) — официальные поля ответа Claude API. А вот формат самого файла лога, то есть что пишется в каждой строке, официально не описан. Способ подсчёта из этой статьи проверен на моих логах версий от v2.1.197 до v2.1.260 и может перестать работать в будущих версиях.

Документация прямо называет ещё одну предосторожность: «Транскрипты и история не шифруются при хранении. Единственная защита — права доступа к файлам в ОС». Если инструмент прочитает файл .env, его содержимое тоже окажется в логе. Делиться итогами подсчёта с другими можно, но будьте осторожны, когда передаёте сами логи или даёте их читать инструменту, который плохо знаете.

3. Простая сумма выходит почти вдвое больше: четыре ловушки

Найти строки с usage и сложить их все: самый очевидный подход, но в моих логах итог получился примерно вдвое больше правильного. Причин четыре.

Ловушка 1: один ответ записывается в несколько строк

Один ответ Claude (один запрос к API) не обязательно занимает одну строку лога. На моём компьютере каждый блок содержимого (размышление, текст или вызов инструмента) записывался отдельной строкой (более 99,9% строк содержали ровно один блок), и в каждой из этих строк было usage. Ответ определяется парой message.id и requestId.

Из 142 345 ответов, записанных в две строки и больше, у 76% во всех строках было в точности одно и то же usage. В остальных 24% число выходных токенов различалось от строки к строке. Поэтому для каждого ответа оставляйте только одну строку, ту, где выходных токенов больше всего. Кроме того, 1 903 ответа встречались ещё и в другом файле (0,95% всех токенов). Причину я не выяснял, но если схлопывать всё по одному и тому же ключу, двойного счёта не будет и здесь.

Ловушка 2: записи субагентов лежат в отдельных файлах

Если читать только основные файлы .jsonl, субагенты выпадают целиком. Вот какая доля правильных итогов пришлась в моих логах на субагентов.

• Ввод (без кэша): 42,9%
• Вывод: 23,2%
• Запись в кэш: 10,8%
• Чтение кэша: 6,9%

По отдельным сессиям разброс ещё шире: за последние 7 дней с учётом цен он составил от 0% у одних сессий до 54% у другой. Чем больше сессия поручает субагентам, тем меньше она выглядит, если считать только основной файл.

Ловушка 3: две ошибки частично гасят друг друга, но в каждой сессии по-разному

Если сложить строки основных файлов как есть, ловушка 1 раздувает счёт, а ловушка 2 его уменьшает. За последние 7 дней итог вышел в 2,06 раза больше правильного значения. Если бы каждая сессия ошибалась в одно и то же число раз, доли остались бы верными. На практике этого не произошло.

Источник: мои собственные замеры (последние 7 дней на 15 сентября 2026 года. Для удобства сравнения только в этой таблице, включая долю субагентов, используются числа токенов без взвешивания. Буквы сессий совпадают с диаграммой в начале статьи)

2-е и 3-е места поменялись, 4-е и 5-е тоже, а G, на самом деле девятая, поднялась на 6-е место. То, что D выглядит маленькой из-за опоры на субагентов, это ровно ловушка 2, но E с той же долей субагентов, что и у D, 39%, ушла в обратную сторону: 2,60×. Влияет и то, на сколько строк распадается каждый ответ (сколько в нём размышлений и вызовов инструментов), поэтому множитель заранее не предскажешь. «Просто разделить на два» не выйдет.

Ловушка 4: 97% токенов приходится на чтение кэша

Даже при правильном подсчёте сравнение сырых чисел токенов искажает представление о том, насколько тяжела каждая сессия. Вот из чего состояли последние 7 дней.

Однако цены за единицу далеко не одинаковы. На официальной странице цен Anthropic чтение кэша стоит 0,1× базовой цены ввода (0,025× у Claude Fable 5.1 и Claude Mythos 5.1), запись в 5-минутный кэш стоит 1,25×, в часовой — 2×, а вывод на всех актуальных моделях в 5 раз дороже ввода. Сессия C, на которую приходилось 12,7% токенов, с учётом этих цен дала 10,4%.

Сам масштаб чисел тоже о многом говорит. Из 12 самых тяжёлых сессий десять (все, кроме D и E) читали в среднем примерно от 410 до 480 тысяч токенов контекста на каждый ответ (у D и E, которые опираются на субагентов, в среднем около 240 и 310 тысяч). «Claude Code отправляет весь диалог с каждым запросом», поэтому чем дольше сессия остаётся открытой, тем тяжелее каждый запрос. Как это устроено, подробно разобрано в статье Claude Code: что на самом деле съедает ваш контекст?

4. Скрипт подсчёта

Этот скрипт учитывает все четыре ловушки. Ему хватает стандартной библиотеки Python 3 (я проверял на 3.11). Он только читает логи и ничего не изменяет и не отправляет. Если вы перенесли каталог конфигурации через переменную окружения CLAUDE_CONFIG_DIR, скрипт будет читать оттуда.

import json, os, sys
from collections import defaultdict
from datetime import datetime, timedelta, timezone
from pathlib import Path

DAYS = float(sys.argv[1]) if len(sys.argv) > 1 else 7
ROOT = Path(os.environ.get("CLAUDE_CONFIG_DIR") or Path.home() / ".claude") / "projects"
SINCE = datetime.now(timezone.utc) - timedelta(days=DAYS)
# USD per 1M input tokens (output = 5x). First match wins.
PRICES = [("sonnet-5", 2), ("sonnet", 3), ("haiku", 1), ("opus-4-1", 15),
          ("opus-4-2025", 15), ("opus", 5), ("fable", 10), ("mythos", 10)]

best = {}  # one API response = one (message.id, requestId)
for path in ROOT.rglob("*.jsonl"):  # also reads <session>/subagents/*.jsonl
    project = path.relative_to(ROOT).parts[0]
    with path.open(encoding="utf-8", errors="replace") as f:
        for line in f:
            if '"usage"' not in line:
                continue
            try:
                row = json.loads(line)
            except ValueError:
                continue
            msg = row.get("message") or {}
            usage = msg.get("usage")
            ts = row.get("timestamp")
            if row.get("type") != "assistant" or not usage or not ts:
                continue
            if datetime.fromisoformat(ts.replace("Z", "+00:00")) < SINCE:
                continue
            key = (msg.get("id"), row.get("requestId"))
            old = best.get(key)
            if old is None or usage.get("output_tokens", 0) >= old[2].get("output_tokens", 0):
                best[key] = (project, msg.get("model") or "", usage)

totals = defaultdict(lambda: [0, 0.0])  # [tokens, weight]
for project, model, u in best.values():
    p = next((v for name, v in PRICES if name in model), 5)
    read_rate = 0.025 if "5-1" in model and ("fable" in model or "mythos" in model) else 0.1
    inp, out = u.get("input_tokens", 0), u.get("output_tokens", 0)
    read, write = u.get("cache_read_input_tokens", 0), u.get("cache_creation_input_tokens", 0)
    write_1h = (u.get("cache_creation") or {}).get("ephemeral_1h_input_tokens", 0)
    totals[project][0] += inp + out + read + write
    totals[project][1] += p * (inp + out * 5 + read * read_rate
                               + (write - write_1h) * 1.25 + write_1h * 2)

all_tokens = sum(t for t, _ in totals.values()) or 1
all_weight = sum(w for _, w in totals.values()) or 1
print(f"last {DAYS:g} days: {len(best):,} responses")
print(f"{'weight':>7} {'tokens':>7}  project")
for project, (t, w) in sorted(totals.items(), key=lambda kv: -kv[1][1]):
    print(f"{w / all_weight:7.1%} {t / all_tokens:7.1%}  {project}")

Сохраните его под именем вроде usage_by_session.py и передайте число дней аргументом. Без аргумента берутся последние 7 дней.

python usage_by_session.py        # последние 7 дней
python usage_by_session.py 1      # последние 24 часа
python usage_by_session.py 30     # последние 30 дней

Вывод выглядит так (имена папок скрыты). weight — доля с учётом цен, tokens — доля по сырому числу токенов.

last 7 days: 19,991 responses
 weight  tokens  project
  32.3%   31.7%  D--work-project-a
  11.1%   11.4%  D--work-project-b
  10.4%   12.7%  D--work-project-c
   7.7%    8.6%  D--work-project-d
   6.4%    5.4%  D--work-project-e

5. Замеры: одна сессия из 29 израсходовала почти треть

За последние 7 дней на моём компьютере были активны 29 сессий. Как видно на диаграмме в начале статьи, расход сосредоточился всего в нескольких из них.

Когда я разложил цифры рядом, стали видны три вещи.

Первое: сессии в верхней части списка тяжелы на каждом отдельном запросе. Топ-3 читали в среднем примерно от 410 до 480 тысяч токенов на ответ. Дело не только в том, что запросов было больше: они весь день оставались открытыми, а контекст всё рос. Документация тоже указывает, что в сессии, которая долго остаётся открытой, даже вопрос в одну строку расходует объём всего диалога.

Второе: сессии, опирающиеся на субагентов, выглядят маленькими со стороны основного диалога. У D и E на субагентов пришлось соответственно 44% и 54% расхода с учётом цен. Глядя на основной диалог на боковой панели, эту часть вы никогда не увидите.

Третье: больше половины сессий почти ничего не израсходовали. Лимит тает быстрее не оттого, что у вас открыто много сессий; его съедают несколько тяжёлых. Если принимать меры, достаточно начать с них. Что урезать первым, разобрано в статье Советы по экономии токенов в Claude Code и лимиты тарифов.

6. Как читать цифры и где их пределы

7. Чтобы следить и дальше, используйте OpenTelemetry

Сильная сторона подсчёта по логам в том, что последние 30 дней видны сразу. Если же вы хотите следить за расходом и дальше, начиная с этого момента, лучше подходит OpenTelemetry, официальная функция мониторинга.

Когда она включена, Claude Code экспортирует метрику токенов claude_code.token.usage (с типами input, output, cacheRead и cacheCreation) и метрику стоимости claude_code.cost.usage. Обе по умолчанию содержат session.id (OTEL_METRICS_INCLUDE_SESSION_ID, по умолчанию true). Файлы логов при этом не читаются, так что дублирующиеся строки из ловушки 1 сюда не попадают, а расход субагентов записывается отдельно в атрибуте query_source (main, subagent, auxiliary).

Чтобы сначала попробовать локально, запустите Claude Code с экспортёром, который выводит данные в терминал, как показано в документации.

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000
claude

Для постоянного подсчёта задайте OTEL_METRICS_EXPORTER=otlp и отправляйте данные туда, где вы собираете их сами (в бэкенд мониторинга, который принимает OTLP). Это место назначения придётся настроить самим, а всё, что было до включения, не запишется: в этом и состоят отличия от подсчёта по логам.

Источник: официальная документация Claude Code, «Monitoring» (имена метрик, атрибуты, переменные окружения)

FAQ

Q1. Разве разбивки по тарифу в /usage недостаточно?
Она меряет по другой оси. Разбивка по тарифу показывает в процентах, на какие навыки, субагенты, плагины и серверы MCP ушёл расход, и не показывает, какая сессия его израсходовала. Искать, что съедает лимит, со стороны функций помогает /usage, а со стороны сессий — подсчёт из этой статьи.

Q2. Можно ли взять готовый инструмент подсчёта?
Можно. Например, неофициальный инструмент ccusage умеет строить отчёты по сессиям из тех же логов. Перед использованием проверьте две вещи. Первое: остаётся ли вся обработка на вашем компьютере, ведь в логах лежат результаты инструментов в незашифрованном виде. Второе: как он считает. Чтобы убедиться, что дублирующиеся строки и субагенты учитываются так же, один раз сравните его вывод с результатом скрипта из этой статьи.

Q3. Хочу учесть расход с других компьютеров и с claude.ai.
Логи хранятся только на каждом компьютере отдельно, поэтому подсчитайте на каждом компьютере и сложите результаты. Чаты на claude.ai в логи Claude Code не записываются. Сколько осталось по тарифу в целом, надёжнее всего смотреть по индикаторам в Settings > Usage на claude.ai.

Q4. Хочу сохранять логи, чтобы подсчитывать и более старый расход.
Для сессий из терминала увеличьте cleanupPeriodDays в settings.json, и они будут храниться дольше. Сессии, которые вы начали или последними продолжили в десктопном приложении (или в Cowork), с v2.1.248 и так хранятся независимо от возраста (чтобы задать срок, используйте desktopSessionCleanupPeriodDays). Учтите, однако, что документация называет уменьшение этих значений одним из способов снизить риск раскрытия логов. Чем дольше вы их храните, тем дольше незашифрованные записи лежат на вашем компьютере, и об этом стоит помнить.

Источники

• Claude Code Docs — Manage costs effectively (блок Session и разбивка по тарифу в /usage, оговорка о том, что цифры считаются по истории этого компьютера, /insights, дашборды для организаций, почему расход растёт в длинных сессиях)
• Claude Code Docs — Explore the .claude directory (где хранятся логи, subagents/, 30 дней по умолчанию для cleanupPeriodDays и порядок хранения сессий десктопного приложения, отсутствие шифрования)
• Claude Code Docs — Desktop (кольцо расхода)
• Claude Help Center — Usage limit best practices (что показывает Settings > Usage)
• Claude Code Docs — Monitoring (имена метрик OpenTelemetry, session.id, переменные окружения)
• Claude Platform Docs — Pricing (цены по моделям, множители для кэша)

Похожие статьи

• Claude Code: что на самом деле съедает ваш контекст? — почему каждый ответ становится тяжёлым
• Claude Code «usage limit reached»: причины и решения — если вы упёрлись в лимит
• Советы по экономии токенов в Claude Code и лимиты тарифов — что урезать первым
• Недельный лимит Claude Code: правда о раннем сбросе — как устроен недельный лимит