Агенты жгут токены: как держать rate limit и счёт под контролем

Один вопрос в чат-боте — это один запрос к модели. Один и тот же вопрос, заданный агенту, который сам ходит по инструментам, читает файлы и перепроверяет себя, — это десятки запросов в цикле, и каждый тащит за собой весь предыдущий контекст. Отсюда две боли, которые всплывают ровно в тот момент, когда прототип агента выкатывают в прод: упор в rate limit провайдера и счёт за токены, который растёт нелинейно. Ниже — что именно происходит под капотом и какие механизмы у OpenAI, Anthropic и Google реально снижают цену вопроса.

Почему агент тратит токены не так, как чат

В обычном диалоге история растёт медленно: пользователь пишет реплику, модель отвечает. В агентском цикле* каждый шаг — это новый вызов модели, и на вход снова уходит всё, что накопилось: системный промпт, описание инструментов, история предыдущих действий, результаты вызовов. Если агент сделал 15 итераций, чтобы решить задачу, то системный промпт и описания инструментов улетели в биллинг 15 раз.

Считать нужно две вещи по отдельности, потому что тарифицируются они по-разному:

• Входные токены (input) — весь контекст, который вы отправляете. У агентов именно они раздуваются: история и результаты инструментов копятся.
• Выходные токены (output) — то, что генерирует модель. Обычно в разы дороже входных, но у агента их меньше по объёму.

Порядок цен на конец 2025 года у флагманских моделей — единицы долларов за миллион входных токенов и десятки за миллион выходных, у «мини»-версий на порядок дешевле. Точные цифры меняются каждые несколько месяцев, поэтому сверяйтесь с прайсом провайдера, а не с числом из чужого поста полугодовой давности.

Rate limiting: RPM, TPM и почему запросы отбивает

Провайдеры ограничивают не только деньги, но и скорость. Ключевые метрики:

• RPM — запросов в минуту.
• TPM — токенов в минуту (и входных, и выходных вместе, в зависимости от провайдера).
• RPD / TPD — суточные потолки на некоторых тарифах.

Лимиты привязаны к уровню аккаунта (usage tier): чем больше вы уже потратили и чем дольше платите, тем выше потолки. Новый аккаунт легко ловит ошибку 429 Too Many Requests уже на десятке параллельных агентов, потому что каждый агент — это пачка запросов, а не один.

Коварство в том, что TPM считает и вход тоже. Агент с большим контекстным окном*, забитым историей, съедает TPM за несколько итераций, даже если запросов формально немного.

Что делать с 429

1. Ставьте экспоненциальный backoff с джиттером — не долбите API сразу, а увеличивайте паузу между повторами.
2. Разносите нагрузку: очередь задач вместо запуска всех агентов одновременно.
3. Держите отдельные ключи или проекты под фоновые задачи и под интерактивные — чтобы батч-обработка не выедала лимит у пользователей, которые ждут ответ сейчас.
4. Запросите повышение лимита в консоли, если упираетесь стабильно, а не разово.

Механизмы снижения стоимости

За последний год провайдеры выкатили несколько инструментов, которые бьют ровно по агентской проблеме — повторяющемуся контексту.

Точные проценты скидок по кэшированию и батчам указаны в документации провайдеров и меняются — не переносите цифру из этого текста в свой финансовый расчёт, откройте актуальный прайс.

Самая дешёвая оптимизация агента — не сгенерировать токен вообще. Прежде чем спорить о скидке на кэш, посмотрите, сколько лишних итераций делает ваш агент и не отправляете ли вы весь лог инструментов туда, где хватило бы двух последних шагов.

Порядок структуры промпта под кэш

Кэширование работает по префиксу: провайдер переиспользует начало промпта, пока оно совпадает. Поэтому статичное держите сверху, изменчивое — снизу:

1. Системный промпт и правила — всегда первыми, они не меняются.
2. Описания инструментов — следом, тоже стабильны.
3. История диалога и результаты вызовов — в конце, где идёт постоянное изменение.

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

Кому это пригодится, а кому нет

Пригодится:

• Командам, у которых агент крутится в цикле по 5-20 итераций на задачу — здесь prompt caching и обрезка истории дают самый заметный эффект.
• Сервисам с фоновой обработкой (разметка, извлечение данных из документов пачками) — им прямая дорога в Batch API.
• Продуктам с пользовательской нагрузкой, где важно не ловить 429 в пиковые часы: очереди и разделение ключей окупаются нервами саппорта.

Не стоит заморачиваться:

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

С чего начать измерение

Оптимизировать вслепую бессмысленно. Минимальный набор:

1. Логируйте на каждый вызов: input-токены, output-токены, был ли кэш-хит, номер итерации.
2. Считайте стоимость на одну решённую задачу, а не на один запрос — агент делает много запросов ради одного результата.
3. Найдите топ-3 по расходу шага в цикле и бейте по ним, а не размазывайте усилия.

Термины. Агентский цикл — схема, где модель не отвечает разом, а по шагам решает, какой инструмент вызвать, получает результат и решает снова, пока не выполнит задачу. Контекстное окно — максимальный объём токенов, который модель принимает за один вызов (вход плюс выход). Prompt caching — переиспользование провайдером неизменной части промпта: повторное чтение кэша тарифицируется дешевле обычного входа.