5,75 миллиардов токенов: как математика контекста сожгла бюджет разработчика и как с ней бороться

# Экономика бесконечной сессии: как 5,75 млрд токенов убедили меня разбить контекст

История разработки пет-проекта по D&D 5e, где один веб-лист вырос в 44 модуля с кодом на 70 000 строк, стала катализатором для глубокого аудита взаимодействия с языковой моделью. Практически весь код создавался с помощью Claude Code, но к середине процесса лимиты подписки регулярно истощались в середине рабочего дня. Интуитивное ощущение «слишком много прочитано» оказалось недиагностичным. Реальное понимание ситуации требовало парсинга транскриптов сессий и анализа метрик фактического биллинга.

Квадратичная ловушка контекста

Основная проблема кроется в механике работы с контекстными окнами. Каждый запрос модели требует отправки в нейросеть полного текущего состояния: системных инструкций, содержимого файлов, истории команд и всего переписанного диалога. Даже если используется кэширование запросов (prompt caching), стоимость чтения данных остается неизменной на каждом шаге. Более того, контекст сессии не сжимается со временем, а непрерывно растет.

Математическая модель стоимости сессии описывается формулой площади под прямой, где базовый размер контекста $S$ умножается на количество запросов $N$, а добавляемые токены $d$ приводят к квадратичному росту из-за суммы арифметической прогрессии: $$\text{Стоимость} \approx N \cdot S + \frac{d \cdot N^2}{2}$$

Этот квадратичный рост означает, что сессия из 800 запросов может стоить в четыре раза дороже четырех коротких сессий по 200 запросов каждая при выполнении одинакового объема работы. В случае рассматриваемого проекта анализ показал, что 22 сессии, превысившие порог в 300 запросов, на долю 28 649 запросов сбили 67% всего расхода токенов. Самая длинная сессия достигла 886 запросов.

Структура потребления

Разбивка ресурсов по источникам выявила парадоксальные утечки: * Стартовый контекст: 39% затрат. Умножение начального объема данных на количество запросов. * Результаты инструментов: 32% затрат. В эту категорию входят повторные чтения файлов (включая стили и данные), выполнение команд оболочки и анализ изображений. * Собственно переписка: 28% затрат. Текстовая история диалога.

Особую тревогу вызвало частое повторное чтение одних и тех же файлов, например, style.css (647 КБ), который модели прочитывали до 266 раз в рамках одной сессии. Каждый повторный доступ оплачивается заново, несмотря на то, что данные уже находятся в активном контексте.

Техническая детализация для разработчиков

Для понимания масштаба проблемы полезно рассмотреть конкретные технические детали, приводящие к перерасходу.

Повторное чтение файлов: Языковые модели часто ведут себя пассивно-агрессивно, возвращаясь к ранее изученным файлам, чтобы «убедиться» в их актуальности. Хотя это может повысить качество ответа, с экономической точки зрения это катастрофично. Если файл уже был загружен в контекст на первом шаге, его повторная загрузка на N-м шаге добавляет N-1 дополнительных расходов на чтение. В рассматриваемом случае это составляло значительную долю бюджета.

Визуализация и скриншоты: Проверка верстки через превью в браузере внутри основного чата генерировала 459 скриншотов. Каждый из них — это десятки тысяч токенов. Оставаясь в контексте до конца сессии, они увеличивают нагрузку на каждый следующий запрос, создавая кумулятивный эффект, который легко упускать из виду при просмотре только итогового биллинга.

Механика сабагентов: Решением стало вынос тяжелых операций в сабагентов (sidechain agents). В отличие от основного треда, где накапливается вся история, сабагенты работают в изолированном контексте, возвращая в главный диалог только краткий вывод. Это позволило удалить миллионы токенов из активного контекста.

Стратегия оптимизации: от интуиции к коду

Для управления квадратичным ростом стоимости были внедрены жесткие алгоритмические ограничения и автоматизация.

1. Жесткие лимиты сессий и стоп-хуки Метод «на глазок» признан неэффективным. Внедрен скрипт-хук, который отслеживает количество запросов и размер контекста в реальном времени. Если лимит (например, 150 запросов или 200k токенов) достигнут, система отправляет предупреждение через стандартный канал сообщений (Stop-hook), требуя немедленного закрытия текущей сессии и создания новой. Это предотвращает случайное «растолковывание» модели и неконтролируемое расширение контекста.

2. Ручная передача смены (/carry → /clear) Вместо автоматического сжатия контекста, которое оплачивает весь путь до момента сжатия, используется протокол ручного контроля. Команда /carry заставляет модель сгенерировать краткое резюме (около 5 строк), описывающее состояние файлов и план действий. За этим следует /clear, который обнуляет контекст. Новый запрос начинается с этого краткого резюме, сохраняя информацию, но полностью устраняя исторический шум.

3. Карта кода вместо разведки Классический сценарий «найти ошибку» часто приводит к множественным grep запросам и чтению огромных блоков кода не по делу. Вместо этого был создан генератор карты проекта (map.md), содержащий индексы секций файлов (например, диапазоны строк в style.css). Редактор теперь работает с этой картой: сначала просматривается оглавление, затем нужный диапазон. Это сокращает количество токенов на разведку с тысяч до десятков.

4. Детерминированные проверки через хуки Любая проверка, которую может выполнить программа, должна выполняться программой, а не нейросетью. Внедрены хуки (PostToolUse), которые мгновенно проверяют изменения файлов (синтаксис, наличие обновлений версий, соответствие чейнджлогам) и блокируют сессию при ошибке. Это позволяет избежать цикла «запросить проверку — прочитать код — найти ошибку — исправить», каждый виток которого стоил бы целого контекстного окна.

5. Делегирование рутинных задач Для механических операций (выпуск версий, написание анонсов, сбор статистики) назначены более дешевые модели (Haiku/Sonnet) в виде сабагентов. Они выполняют предписанные алгоритмы, не требуя интеллектуальных ресурсов старшей модели и не увеличивая контекст главного треда.

Заключение

После внедрения этих изменений средняя нагрузка на контекст снижается до 150k токенов, а количество «марафонских» сессий стремится к нулю. Ключевой вывод заключается в том, что использование кодового агента — это не просто делегирование задач, а управление ограниченным ресурсом. Понимание того, как именно формируется стоимость каждого байта в контексте, позволяет превратить хаотичное взаимодействие с ИИ в структурированный и экономически эффективный процесс разработки.

Эффективность достигается не за счет сокращения длинны ответов модели на 0,5%, а за счет кардинального изменения архитектуры диалога и внедрения программных сдержек.