Почему суб-агенты могут сжечь недельную квоту за 30 минут
Каждый вызов инструмента заново отправляет всю историю
Запустите 5 суб-агентов параллельно на 30 минут, и расход квоты может оказаться в десятки раз быстрее, чем в одиночном диалоге — потому что каждый раунд вызова инструмента заново отправляет всю накопленную историю разговора.
Четыре ключевых факта
Заново отправляет всю историю
Большинство многораундовых/инструментальных API не хранят состояние — каждый запрос должен заново отправлять системный промпт, все предыдущие сообщения и все результаты предыдущих вызовов инструментов как вход.
Накопленный расход растёт примерно квадратично от числа раундов
Если задаче требуется N раундов вызовов инструментов, и средний объём истории на раунд растёт линейно с числом раундов, суммарный расход токенов растёт примерно как N в квадрате.
Несколько суб-агентов одновременно усиливают эффект
Каждый параллельно работающий суб-агент независимо хранит и заново отправляет собственную историю — M параллельных суб-агентов примерно умножают расход одного диалога на M.
Кэширование промптов экономит деньги, но не обязательно квоту
Кэширование промптов у некоторых поставщиков снижает стоимость повторяющихся префиксов, но лимиты квоты/скорости обычно всё равно считаются по фактически обработанным токенам — не считайте кэширование универсальным решением проблем с квотой.
Что на самом деле стоит за повторной отправкой токенов
Большинство основных диалоговых/агентных API «не хранят состояние» — каждый запрос должен нести полный контекст (системный промпт, все сообщения на данный момент, входы и выходы всех вызовов инструментов), сама модель не помнит предыдущий запрос. Это значит, что для задачи, требующей N раундов вызовов инструментов, первый раунд отправляет только исходный контекст, второй должен включить результаты первого, а N-й — все N-1 предыдущих раундов целиком; суммарно отправленные токены растут примерно квадратично от числа раундов, а не линейно. Это и есть коренная причина, почему длинные задачи и многораундовые агентные циклы так «прожорливы» по квоте.
Почему параллельные суб-агенты делают это гораздо заметнее
Когда вы запускаете несколько суб-агентов параллельно для разных подзадач, каждый из них независимо проделывает то же самое «повторное отправление истории», обычно одновременно с остальными — расход токенов, накапливающийся за короткое время, легко достигает от нескольких до десятков раз больше, чем в одиночном диалоге. Это и есть техническая первопричина частой жалобы: «запустил несколько параллельных агентов и за 30 минут сжёг недельную квоту».
Хронология
Дизайн, при котором API без состояния заново отправляет всю историю на каждом раунде, — давняя общая архитектура основных диалоговых/агентных API.
Распространение параллельных суб-агентов и многоагентных workflow делает расход от этой изначальной особенности гораздо более заметным для пользователей напрямую.
Такие технологии, как кэширование промптов, снижают стоимость биллинга, но расчёт лимитов квоты/скорости обычно соответственно не смягчается.
Подтверждено vs частое заблуждение
Подтверждено
Отсутствие состояния у основных многораундовых/агентных API и примерно квадратичный накопленный расход из-за повторной отправки полной истории на каждом раунде — публично задокументированное, общее поведение такой архитектуры API, последовательно описанное в официальной документации и обсуждениях разработчиков.
Частое заблуждение
Многие считают, что «если использовать кэширование промптов, лимит квоты не наступит быстро» — кэширование в основном влияет на стоимость биллинга; лимиты квоты/скорости обычно всё равно считаются по фактически обработанным токенам или характеристикам запроса, так что нельзя полностью полагаться на кэширование для контроля расхода квоты.
Как оценивать и сокращать расход
Как оценивать
Оцените ожидаемое число раундов вызовов инструментов и средний объём истории на раунд, и прикиньте общий расход по квадратичной, а не по простой линейной формуле «расход за раунд × число раундов».
Как сокращать
Регулярная суммаризация/сжатие истории, сохранение только тех результатов вызовов инструментов, которые действительно нужны задаче, а не всего подряд, ограничение числа параллельных суб-агентов и максимального числа раундов на суб-агента — всё это распространённые тактики сокращения.
Что делать конкретно
Во-первых, ограничьте максимальное число раундов вызовов инструментов на задачу — при превышении порога запускайте суммаризацию/сжатие истории вместо бесконечного накопления. Во-вторых, сохраняйте в результатах вызовов инструментов только то, что реально нужно задаче, а не запихивайте в контекст целиком сырые логи/вывод. В-третьих, ограничьте число одновременно работающих параллельных суб-агентов, либо назначьте некритичным суб-агентам более дешёвую модель с более коротким контекстом. В-четвёртых, учитывайте расход квоты как отдельное измерение при планировании задачи — заранее прикидывайте, сколько квоты потребует сложная задача, а не обнаруживайте приближение к лимиту уже во время выполнения.
Что делать в QCode
Параллельные суб-агенты легко заполняют квоту одной модели за короткое время; направляя разных суб-агентов через один ключ QCode на разные семейства моделей, вы распределяете нагрузку по квоте, и достижение лимита одной моделью не останавливает всю многоагентную задачу.
Частые вопросы
Почему суб-агенты расходуют квоту настолько быстрее одиночного диалога?
Каждый суб-агент независимо хранит и заново отправляет собственную историю диалога, поэтому M параллельных суб-агентов примерно умножают расход одного диалога на M; вдобавок накопленный расход внутри одного суб-агента уже растёт примерно квадратично от числа раундов — вместе эти два эффекта существенно усиливают расход за короткое время.
Решает ли эту проблему кэширование промптов?
Оно снижает стоимость биллинга за повторяющиеся префиксы, но лимиты квоты/скорости обычно всё равно считаются по фактически обработанным токенам или характеристикам запроса — нельзя полностью полагаться на кэширование, чтобы избежать лимита.
Как примерно оценить, сколько квоты потребует задача?
Оцените ожидаемое число раундов вызовов инструментов и средний объём истории на раунд, и прикиньте это скорее по квадратичной, чем по простой линейной формуле «расход за раунд × число раундов».
Не повредит ли ограничение числа параллельных суб-агентов эффективности задачи?
Здесь есть компромисс — чем больше параллелизм, тем быстрее завершается задача, но тем выше и нагрузка на квоту за короткое время; нужно соотносить это с остатком вашей квоты и срочностью задачи.
Есть ли эта проблема у всех агентных фреймворков?
В принципе, любой агентный фреймворк, построенный на основных API без сохранения состояния, обладает этой особенностью; чем лучше в фреймворке реализовано сжатие/суммаризация истории, тем ниже ощущаемый расход, но архитектурная первопричина общая.
Что происходит с работающей многоагентной задачей при достижении лимита квоты?
Модель/аккаунт, достигшие лимита, отклоняют новые запросы, и задача обычно останавливается или завершается с ошибкой; заблаговременное перенаправление части суб-агентов на другие модели — распространённый способ не дать всей задаче застрять на лимите одной модели.
Источники
Архитектурный факт, что API без сохранения состояния в диалоговых/агентных сценариях заново отправляют полную историю на каждом раунде, публично задокументирован и последовательно описан в документации основных поставщиков моделей и сообществах разработчиков; эта страница не содержит утверждений о приватной реализации какого-либо конкретного поставщика. Составлено 27.08.2026.
Не давайте многоагентной задаче застрять на одной квоте
Один ключ QCode направляет разных суб-агентов на разные модели, распределяя нагрузку на квоту.
Читайте также
5-Часовое Скользящее Окно Claude: Объяснение
Уровень лимитов, который чаще всего задевают короткие всплески интенсивного использования.
Подписка vs API: съест ли 24/7-агент ваш тариф
Экономика долгих автоматизированных задач.
Как ротировать лимиты между несколькими инструментами
Разумное сочетание лимитов нескольких моделей/инструментов.
Эта страница — общее техническое объяснение для разных поставщиков и не содержит утверждений о приватной реализации какого-либо конкретного из них. Фактическое поведение зависит от используемой модели и документации клиента.