Лимиты трат для ИИ-агентов: как не отдать бюджет автономии

Почему это стало проблемой именно сейчас

Пока ИИ отвечал на разовые запросы в чате, вопрос лимитов сводился к цене подписки. Автономные агенты изменили расклад: агент сам решает, сколько раз обратиться к модели, какие инструменты вызвать и когда остановиться. Один зациклившийся агент, который бесконечно перечитывает свой лог и переспрашивает модель, способен за несколько часов потратить больше, чем команда за месяц ручной работы.

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

Что вообще тратит деньги у агента

Стоимость складывается не только из токенов языковой модели. Типичный набор статей расхода:

• Токены модели — вход и выход тарифицируются отдельно, выход обычно дороже. Агент с большим контекстным окном¹ платит за весь контекст на каждом шаге.
• Вызовы инструментов — поиск в интернете, парсинг, генерация изображений, обращения к сторонним API со своими прайсами.
• Векторное хранилище и RAG — эмбеддинги при индексации и запросах.
• Инфраструктура — если агент крутится на вашем сервере, а не в облаке провайдера.

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

Три уровня, где ставить лимиты

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

Уровень 1. Биллинг и лимиты провайдера

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

• OpenAI — в разделе биллинга задаются usage limits: мягкий порог с уведомлением и жёсткий порог, при котором API перестаёт отвечать. Проверяйте актуальные названия полей в консоли, интерфейс меняется.
• Anthropic — аналогичные месячные лимиты и оповещения в Console.
• Облачные развёртывания (Azure OpenAI, Amazon Bedrock, Google Vertex) — лимиты выставляются средствами самого облака: бюджеты, алерты, квоты на регион и модель.

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

Уровень 2. Прокси и шлюз перед моделью

Между агентом и API ставится прослойка, которая считает токены и деньги в реальном времени и режет запросы по своим правилам. Для этого используют open-source-шлюзы (например, LiteLLM) или собственный прокси.

Что даёт шлюз:

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

Уровень 3. Лимиты в самом агенте

Самый точный контроль — внутри логики агента. Здесь вы ограничиваете не деньги напрямую, а то, что их порождает:

• Максимум шагов (итераций) цикла рассуждение-действие. Классическая защита от зацикливания.
• Бюджет токенов на задачу — счётчик, который агент не имеет права превысить, иначе завершает работу с отчётом.
• Лимит вызовов конкретного инструмента — например, не больше пяти поисков на одну задачу.
• Тайм-аут по времени — жёсткая отсечка, если агент работает дольше ожидаемого.

Лимит по числу шагов защищает от зацикливания, но не от дорогих шагов. Лимит по деньгам защищает от дорогих шагов, но не ловит логическую ошибку. Ставьте оба.

Сравнение подходов

Кому что подойдёт

Одиночный разработчик, который экспериментирует. Хватит жёсткого лимита в биллинге плюс ограничения на число шагов в коде. Прокси избыточен.

Команда с общим API-ключом. Нужен шлюз: без него один коллега с зациклившимся агентом расходует общий бюджет, и вы не поймёте, кто именно. Лимит на пользователя решает и вопрос контроля, и вопрос справедливости.

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

Кому лимиты в коде избыточны. Если агент запускается вручную, делает одно короткое действие и завершается — счётчик итераций и тайм-аут ничего не добавят к биллингу. Не усложняйте там, где риск зацикливания отсутствует по конструкции.

Практический порядок настройки

1. Выставьте жёсткий месячный лимит в биллинге провайдера — это страховка на случай, когда всё остальное отказало.
2. Включите уведомления на мягком пороге (например, 50 и 80 процентов бюджета), чтобы узнать о проблеме до отсечки.
3. В коде агента задайте максимум шагов и бюджет токенов на одну задачу.
4. Ограничьте число вызовов дорогих инструментов на задачу.
5. Если ключ общий — поставьте шлюз с лимитом на пользователя.
6. Логируйте фактические траты по задачам и раз в неделю смотрите, где расход выше ожидаемого.

¹ Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один запрос: сюда входят и инструкция, и вся история диалога, и приложенные данные. Чем больше окна вы используете на каждом шаге, тем дороже шаг.