# Как установить жесткий лимит расходов для задачи программирующего агента? > Жесткий лимит должен применяться до каждого вызова модели или платного инструмента шлюзом, который владеет бюджетом задачи. Резервируйте максимальную стоимость, сверяйте фактическое использование, отклоняйте вызовы, которые не помещаются в остаток, и завершайте работу полезной контрольной точкой. # Как установить жесткий лимит расходов для задачи программирующего агента? Жесткий бюджет является контролем допуска. До любого платного вызова надежный шлюз должен подтвердить, что максимальная разрешенная стоимость помещается в остаток. Предупреждение после использования не остановит уже возникший перерасход. Учитывайте вход, максимальный выход, повторы, fallback, подагентов, embeddings, поиск, sandbox и каждый платный инструмент. ## Отделить жесткий лимит от мягкой цели Используйте три значения: | Контроль | Назначение | Поведение | |---|---|---| | Цель | Ожидаемая стоимость | Предупредить или выбрать более дешевый план | | Мягкий лимит | Порог эскалации | Запросить одобрение или снизить качество | | Жесткий лимит | Максимально разрешенный расход | Отклонить до следующего вызова | Например, цель $0.60, одобрение при $0.90 и остановка при $1.00. Жесткий лимит должен быть на сервере, а не только в промпте. ## Проводить каждое платное действие через один шлюз Выдайте агенту короткоживущие учетные данные, которые вызывают только ваш шлюз. Он добавляет `task_id`, проверяет бюджет, оценивает действие и резервирует или отклоняет. Не раскрывайте ключ провайдера, позволяющий обойти учет. Применяйте то же правило к поиску, sandbox, выполнению кода и платному извлечению. ## Резервировать до вызова и сверять после Оцените верхнюю границу по известным входным token и максимальному выходу. Атомарно зарезервируйте сумму, выполните вызов и замените резерв фактическим использованием. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` Атомарный резерв не позволяет двум подагентам потратить один остаток. ## Использовать версионируемый тариф Сохраняйте примененную цену с каждой оценкой. Цены меняются, поэтому прошлое использование нельзя пересчитывать по сегодняшнему тарифу. Если провайдер возвращает окончательную стоимость, храните и оценку, и сумму. Если он возвращает только token, используйте версию тарифа, выбранную до вызова. Добавляйте запас для неизвестных расходов или отклоняйте вызов без ограничиваемого максимума. ## Сделать потоковые ответы безопасными До открытия потока резервируйте всю разрешенную стоимость выхода. Сверяйте использование, но не предполагайте, что закрытие клиента мгновенно остановит оплату. Отмена является оптимизацией, а не границей контроля. Задайте лимит выхода и timeout для вызова. Лимит задачи охватывает все потоки, повторы и fallback. ## Включить повторы и подагентов Каждая попытка списывается с одного родительского ledger. Новый бюджет при повторе отменяет ограничение. Используйте иерархию: | Ledger | Лимит | Правило | |---|---:|---| | Родительская задача | $1.00 | Абсолютный потолок | | Подагент реализации | $0.55 | Не больше остатка родителя | | Анализ тестов | $0.25 | Возвращает неиспользованный резерв | | Финальная проверка | $0.20 | Запускается только при остатке | Дочерние лимиты являются распределением, а не дополнительными деньгами. ## Остановиться с полезной контрольной точкой Если действие не помещается, верните типизированную ошибку и не повторяйте отклоненный вызов. Сформируйте из имеющегося контекста контрольную точку: * завершенные изменения и тесты; * оставшаяся работа и заблокированное действие; * текущее состояние репозитория; * оценка дополнительного бюджета; * resume token или ID задачи. Так остановка становится контролируемой передачей. ## Использовать контроль провайдера как резерв Лимиты аккаунта уменьшают ущерб, но редко точны для задачи. Они могут объединять репозитории, обновляться с задержкой или не учитывать инструменты. Даже с мультимодельным шлюзом вроде Atlas Cloud держите основной ledger в своей оркестрации и записывайте ID использования для сверки. Лимит сохраняется при смене модели. ## Тестировать лимит как финансовый контроль Проверьте параллельность, длинные потоки, timeout, отсутствие usage, повторы, fallback и отказ ledger. При недоступности бюджетного сервиса отклоняйте по умолчанию. Подтвержденные расходы плюс резервы никогда не превышают потолок. ## Итог Настоящий жесткий лимит применяется до расхода через атомарные резервы и единый ledger для каждого платного действия. Если система предупреждает лишь после использования, это мониторинг, а не жесткий предел. ## FAQ ### Является ли max_tokens жестким денежным лимитом? Нет. Он ограничивает длину одного ответа, но не общую стоимость, входные token, повторы, смену модели и инструменты. Для денежного лимита нужен ledger для каждого платного действия. ### Где следует применять бюджет агента? На серверном шлюзе или в слое оркестрации, через который проходят все вызовы моделей и платных инструментов. Клиентские счетчики можно обойти, а при параллельности возможны гонки. ### Как учитывать потоковые ответы? До открытия потока зарезервируйте максимально разрешенную стоимость вывода, а после закрытия сверяйте фактическое использование. Отменяйте запрос у провайдера, если это поддерживается, но не полагайтесь только на отмену. ### Должны ли повторы использовать исходный бюджет? Да. Повторы, fallback, подагенты и оценочные вызовы списываются с одного ledger, если пользователь явно не одобрил отдельный бюджет. ### Что делать, если остатка недостаточно? Отклоните следующий платный вызов и попросите агента сформировать контрольную точку из имеющегося контекста: выполненная работа, нерешенные пункты и необходимый дополнительный бюджет. ### Можно ли заменить лимит задачи лимитом аккаунта провайдера? Обычно нет. Лимит аккаунта защищает весь аккаунт и может обновляться асинхронно. Шлюз задачи дает мгновенную изоляцию, а лимит аккаунта остается дополнительной защитой.