Экономика контекста и prompt caching

Из чего складывается расход токенов

Любая LLM - это просто набор статичных весов, она ничего не “помнит” между запросами, поэтому каждое новое сообщение в сессии Claude Code отправляет заново весь текущий контекст на сервера Anthropic. И просто старт новой сессии и отправка первого сообщения часто уже съедает несколько процентов контекста:

• Системный промпт - зависит от харнесса и модели, обычно от нескольких тысяч до нескольких десятков тысяч токенов
• Описания инструментов - JSON-схемы всех доступных системных инструментов, в Claude Code это около 10 тысяч токенов
• Скиллы, агенты, память - легко может съедать ещё 20-30 тысяч токенов. Описания MCP-инструментов сейчас грузятся только по требованию
• First-message scaffolding - сообщение “дарова” в чистой сессии у меня съело 18 тысяч токенов

Исследование Systima (июль 2026) показало, что этот базовый минимум может сильно отличаться у разных обвязок - например, у OpenCode он ниже в 4-5 раз, чем у Claude Code. В общем, нужен баланс - лучше не раздувать сессии до миллиона токенов, но и создавать новую на каждый чих тоже довольно расточительно.

По ходу работы сессия, само собой, может быстро раздуваться, и не только за счёт сообщений:

• Подгружаются описания MCP-тулзов
• Запускаются субагенты, каждый из которых получает свой системный промпт, контекст и описания тулзов
• Некоторые тулзы могут возвращать очень длинные ответы

Как работает кэш

Официальная документация про кэширование

Prefix caching позволяет переиспользовать уже обработанный контекст и пересчитывать только ту часть, что добавилась. Соответственно, он сработает только, если первая часть (“префикс”) идеально совпадает с ранее обработанной. Поэтому любой харнесс кладёт постоянные штуки типа системного промпта, описания тулзов, контекста проекта в самое начало каждого запроса.

Для экономии стоит избегать всех вещей, которые ломают кэш:

• Смена модели
• Смена уровня effort
• Включение fast mode
• Некоторые изменения настроек
• Обновление версии Claude Code
• Уйти на обед больше, чем на час - на подписках TTL кэша составляет 60 минут

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

Сколько это стоит

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

Рассмотрим неизменный префикс размером P токенов, который используется в N последовательных запросах. Если за это время кэш не истёк и не был инвалидирован, его стоимость составит:

без кэша:  N × P
с кэшем:   1.25 × P  +  0.1 × P × (N − 1)   ≈  P × (1.25 + 0.1·(N−1))

Пример. Префикс P = 40k токенов, Opus 4.8 (~$5 за 1M input), сессия из 10 ходов:

• без кэша: 10 × 40k × $5/1M = $2.00
• с кэшем: запись 40k×1.25 + чтения 9×40k×0.1 = (50k + 36k) × $5/1M ≈ $0.43

Диагностика

• /context в пустой сессии — видим, кто ест контекст по умолчанию
• В каждом ответе API есть cache_creation_input_tokens (запись, дорого) и cache_read_input_tokens (чтение, ~10% от input). Высокий read/create — хорошо. Через OpenTelemetry-экспорт эти токены видны по пользователям и сессиям на уровне организации
• Скрипт анализа токенов — скормить отчёт Claude Code и попросить найти плохие паттерны