Technical Context
Я внимательно посмотрел на то, как описывают проблему пользователи ClaudeCode: у людей «съедало» 102–148% лимита по extra usage, а сервис продолжал работать «после лимита». Самая ценная деталь в их переписке — упоминание кейса с «кучей субагентов, шуршащих параллельно». Это почти всегда указывает не на «неправильные цифры в кабинете», а на архитектурный сбой в применении жёсткого капа в условиях конкуренции.
Как архитектор, я разделяю два механизма провайдера: учёт (metering) и принуждение (enforcement). В идеальном мире счётчик атомарный и общий для всех API-нод, а блокировка наступает строго в момент превышения. В реальном мире metering часто живёт в асинхронных логах, а enforcement делается «периодическими проверками» или через распределённые компоненты, которые не всегда синхронизированы. Тогда возникает окно, где запросы ещё принимаются, а лимит уже формально исчерпан.
В multi-agent сценариях я регулярно вижу три типовых причины перерасхода:
- Race condition в распределённом лимитере: несколько API-серверов одновременно принимают запросы и инкрементят лимит неатомарно, поэтому кап пробивается пачкой.
- Задержка оценки usage: лимит пересчитывается раз в N минут; пока система «догоняет» фактический расход, агенты успевают сделать ещё десятки/сотни вызовов.
- Смешение лимитов: есть лимит на запросы/минуту и отдельный лимит по стоимости/токенам; в некоторых реализациях блокируют по RPM, но не блокируют по cost cap (или наоборот).
Технически это проявляется так: вы запускаете параллельных субагентов (планирование, поиск, валидация, генерация, рефлексия), каждый держит собственный цикл «вызов → инструмент → повтор», и общая скорость расхода становится выше, чем ожидает ваша финансовая модель. Если провайдер не возвращает жёсткое 429/402 в момент исчерпания бюджета, вы получаете перерасход «за несколько минут», особенно на пиковых пачках.
Business & Automation Impact
Для бизнеса эта история неприятна тем, что ломает базовую опору управления рисками: «я выставил лимит — значит, выше не уйдёт». Когда лимит не является жёстким стоп-краном, ответственность за финансовый контроль фактически переезжает на клиента. И в проектах автоматизации с помощью ИИ это означает одно: без клиентского rate limiting и бюджетного контроллера multi-agent нельзя выпускать в продакшн, даже если провайдер обещает caps.
Кто выигрывает? Команды, у которых уже есть дисциплина SRE-подхода к ИИ: бюджеты, алерты, троттлинг, деградация функционала. Кто проигрывает? Те, кто запускает «агентов для всего» на корпоративном ключе без ограничений параллелизма и без наблюдаемости, надеясь на провайдера.
В своей практике в Nahornyi AI Lab я закладываю финансовую управляемость как часть AI-архитектуры, а не как настройку в кабинете. Конкретно для multi-agent систем я почти всегда добавляю:
- Клиентский лимитер конкуренции: фиксированный max parallelism на уровне оркестратора (очередь + worker pool). Не «сколько потоков у машины», а «сколько запросов выдерживает бюджет».
- Бюджетный предохранитель: локальный счётчик стоимости (оценка по токенам/модели) и правило “stop / degrade / ask approval”, если прогноз на конец часа/дня выходит за границы.
- Алерты не по факту, а по тренду: если slope расхода резко вырос (типичный симптом runaway-агента), я хочу знать об этом через 2–3 минуты, а не на утреннем отчёте.
Отдельный эффект — юридико-финансовый. В enterprise-контрактах часто есть требование «предсказуемости расходов». Если ваша система может пробивать cap из‑за параллельных агентов, вам нужно либо менять контрактную модель, либо внедрять внутренние контроллеры и журналировать решения (почему агент продолжал работать после достижения порога).
Strategic Vision & Deep Dive
Мой неочевидный вывод: проблема не столько в баге конкретного продукта, сколько в том, что рынок массово переходит от одиночных чатов к агентным конвейерам, а старые механизмы биллинга проектировались под «последовательные» нагрузки. Multi-agent — это не «чуть больше запросов», это качественно другой профиль: всплески, волны, параллельные ветки, ретраи, инструменты, долгие цепочки рассуждений. Если провайдерские caps реализованы как «проверка раз в окно» или как неатомарный счётчик, они будут ломаться снова и снова.
В проектах Nahornyi AI Lab я видел одну и ту же ловушку: команда оптимизирует промпты и выбор модели, но забывает про оркестрацию. А именно оркестрация определяет, будет ли ваш агент «стоить 20$ в день» или «съест бюджет отдела за час». Поэтому при внедрении искусственного интеллекта в процессы я заставляю архитектуру отвечать на три вопроса ещё до первой интеграции: (1) что считается единицей работы (job), (2) сколько job может идти параллельно, (3) что система делает при приближении к бюджету — замедляется, упрощает план, отключает дорогие инструменты или просит подтверждение.
Практический паттерн, который я считаю обязательным в 2026 году: «policy-driven execution». Агент не просто выполняет план, он исполняет его под политиками: лимит стоимости на job, лимит стоимости на пользователя, лимит на сутки, максимальная глубина ветвления, максимальное число ретраев, запрет на бесконечные уточнения. Тогда даже если внешний cap сломан или запаздывает, внутренние политики удерживают систему в коридоре.
Хайп вокруг агентов закончится там, где начнётся бухгалтерия. Полезность останется у тех, кто проектирует не демо, а управляемый производственный контур — с предохранителями, наблюдаемостью и чёткими режимами деградации.
Если вы строите multi-agent ИИ автоматизацию и хотите защититься от внезапных счетов, я приглашaю вас обсудить архитектуру лимитов, оркестрацию и бюджетные политики вместе с Nahornyi AI Lab. Напишите мне — Vadym Nahornyi — и я предложу конкретный план, как сделать расходы предсказуемыми без убийства скорости разработки.