Стоимость контекста AI-агента: как измерить повторные инструкции и tool calls

При разработке AI-агентов (Claude Code, Cline, Roo Code или собственных multi-step пайплайнов) расход API может расти по мере накопления контекста. Конкретный состав каждого запроса зависит от клиента: в него могут входить системный prompt, схемы доступных инструментов, история сообщений и результаты вызовов функций.

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

Анатомия контекста AI-агента: за что списываются токены на каждом шаге

Для измерения удобно разделить отправляемый контекст на четыре наблюдаемых компонента:

1. Системные инструкции и правила (System Prompt): Базовые требования к стилю, ограничения безопасности и контекст репозитория.
2. Схемы инструментов (Tool Schemas): JSON-описания подключенных функций, параметров и типов данных, если клиент включает их в запрос.
3. История сообщений (Message History): Предыдущие реплики пользователя и ответы агента, накапливающиеся по мере выполнения задачи.
4. Результаты работы инструментов (Tool Outputs): Содержимое прочитанных файлов, логи выполнения терминальных команд и дампы API.

Не умножайте размер первого запроса на число шагов вслепую. Экспортируйте usage каждого вызова: история может расти, клиент может обрезать данные, а провайдер — отдельно учитывать cached Token.

Сравнительная таблица источников контекста и их оптимизации

Компонент контекста	Что измерить	Основной риск перерасхода	Изменение для отдельного теста
Tool Schemas	Размер фактически переданного списка	Неиспользуемые инструменты в общем наборе	Оставить только необходимые для задачи tools
Tool Outputs	Размер каждого результата	Чтение файлов целиком вместо точечных срезов	Ограничить диапазон строк и объём логов
История шагов	Рост input от вызова к вызову	Накопление уже не нужных результатов	Проверить поддерживаемое клиентом сокращение истории
System Prompt	Размер и стабильность префикса	Повторяющиеся инструкции	Удалить дубли, сохранив обязательные правила

Пошаговое руководство: как измерить baseline и сократить расходы

Сначала зафиксируйте актуальные ставки модели. Для расчёта baseline используйте текущие цены BetterToken, а не значения из старых примеров. Открыть актуальные цены BetterToken

Для объективной оптимизации используйте методику замера по одной переменной:

Шаг 1. Зафиксировать тестовую контрольную задачу

Выберите воспроизводимый инженерный сценарий (например: «найти функцию валидации в репозитории, добавить обработку крайнего случая и запустить unit-тесты»). Задача должна иметь четкий критерий завершения (код возврата 0 в pytest или bun test).

Шаг 2. Замерить Baseline (Input, Output, Cache)

Запустите задачу в стандартной конфигурации агента. Зафиксируйте в логах или в панели мониторинга:

• Количество выполненных шагов;
• Суммарный объём input Token;
• Суммарный объём output Token;
• Объем кэшированных токенов (cached tokens);
• Финансовые затраты по актуальным тарифам.

Текущие ставки выбранной модели сверяйте на странице цен BetterToken. В Workspace для принятого запроса можно проверить модель, время и статус, input/output Token, cached Token при поддержке модели и стоимость вызова. Если один шаг агента создаёт несколько запросов, не выдавайте request-level запись за готовую разбивку по шагам: сопоставляйте их по времени и данным собственного клиента.

Шаг 3. Изменить одну переменную контекста

Проведите изолированные тесты, меняя строго один параметр за итерацию:

• Эксперимент A (Tool Filtering): Оставьте только инструменты, необходимые для контрольной задачи, и измерьте разницу input Token.
• Эксперимент B (Output Truncation): Ограничьте размер вывода терминала первыми 50 строками ошибки вместо полного 2000-строчного дампа.
• Эксперимент C (Prefix Stability): Если модель и endpoint поддерживают prompt caching, зафиксируйте неизменяемый порядок системного prompt и схем инструментов, затем проверьте фактические cached Token.

Шаг 4. Оценить экономику и качество решения

Сравните итоговые метрики с исходным baseline. Изменение можно зафиксировать, только если контрольная задача по-прежнему проходит тот же критерий качества, а измеренные время или расход улучшились на вашем наборе запусков.

Шаг 5. Проверить короткий handoff в новой сессии

Создайте handoff только из подтверждённого состояния: цель, текущая ревизия, изменённые файлы, ограничения, пройденные проверки и следующий шаг. Не копируйте весь transcript или полный terminal output. В новой сессии повторите ту же задачу и запишите input/output/cache Token и итог тех же acceptance checks.

Если новая сессия прочитала меньше истории, но пропустила ограничение или не смогла воспроизвести тест, это не экономия. Практический шаблон A/B-замера приведён в диагностике контекста Claude Code, а влияние стабильного prefix нужно проверять отдельно по эксперименту Prompt Cache.

Рекомендации по настройке агентных окружений

1. Сужайте набор инструментов по роли: Агенту для чтения не нужны функции записи; проверяйте, уменьшает ли это фактический input без потери результата.
2. Сохраняйте стабильный префикс: Если caching поддерживается, не меняйте порядок общих правил без необходимости и проверяйте cached Token, а не предполагаемую скидку.
3. Ограничивайте цикл: Задайте конечное число попыток и явное условие остановки, подходящие для конкретной задачи.

Граничные случаи и частые ошибки

• Ошибка: Отключение критических схем валидации. Если урезать описание схемы инструмента слишком сильно, модель начнет передавать невалидный JSON, что вызовет череду повторных запросов.
• Ошибка: Слепое доверие заявлениям об экономии из соцсетей. Эффект оптимизации контекста зависит от структуры вашего репозитория и среднего размера файлов.
• Ошибка: Отсутствие прозрачной телеметрии. Если endpoint не возвращает раздельную статистику input/cache Token, не оценивайте кэш по предположению; пометьте значение как неизвестное.