Платформа Claude для управляемых ассистентов получила обновление: теперь при обработке больших массивов данных нейросеть способна не просто по очереди отвечать в диалоге, а сама пишет программный сценарий и передаёт его серверу для параллельного выполнения. Если вам требуется разобрать сотни договоров или сверить выписки из десятка источников, модель формирует отдельный рабочий прогон и делит задачу на последовательные фазы. Однако за внешней автономностью кроется техническая ловушка: итоговая системная отметка «завершено» подтверждает лишь то, что программа дошла до финальной строки, но совершенно не гарантирует, что рабочие ветки внутри роя не упали с ошибкой посреди обработки.
Вместо бесконечной переписки — отдельная программа на сервере
До этого обновления у разработчиков на платформе был привычный путь разделения труда — обычные субагенты. В такой схеме основной помощник остаётся на связи, лично раздаёт поручения вспомогательным процессам, ждёт ответов и позволяет человеку в любой момент отправить уточнение прямо в текущую ветку. Это удобно для вдумчивого исследования, но превращается в узкое горлышко, когда требуется одновременно перелопатить сотни типовых файлов.
С 9 октября 2026 года в бете управляемых ассистентов появился второй механизм — динамические сценарии. Модель больше не тратит время на ручное сопровождение каждого шага: она генерирует код программы, которая самостоятельно запускает множество рабочих веток, координирует их по фазам и собирает результаты. Сервер платформы забирает эту программу и выполняет её целиком в фоновом режиме. Вы при этом не видите исходный код сценария в интерфейсе во время исполнения, а дописать сообщение или дать совет отдельной рабочей нити посреди прогона уже невозможно — по завершении работы сервер автоматически отправляет все дочерние ветки в архив.
Сам код написанной программы не исчезает бесследно. Когда фоновый прогон завершится и сессия вернётся в режим ожидания, вы можете прямым вопросом попросить ассистента вывести созданный скрипт дословно, чтобы проверить, какую именно логику обхода файлов он заложил.
Почему статус «завершено» скрывает ошибки в отдельных ветках
Главная неожиданность новой архитектуры заключается в трактовке результатов. Когда сервер рапортует об окончании сценария со статусом completed, человек инстинктивно ожидает, что вся пачка документов проверена без сбоев. В действительности этот статус означает ровно одно: управляющая программа отработала свой код от начала до конца. Если часть параллельных веток столкнулась с ошибками инструментов, упала из-за таймаута или вовсе не смогла запуститься, общий прогон всё равно получит статус завершённого.
Реальные сбои фиксируются не в главном статусе, а в потоке событий конкретных нитей. Если не запросить у модели детальный отчёт по каждому элементу массива или не разобрать журнал событий, можно легко принять аварийно оборванный прогон за качественную работу.
Ещё одна частая иллюзия связана с кнопкой прерывания в интерфейсе. Если нажать привычную кнопку остановки диалога, вы прервёте только текущую реплику собеседника, тогда как сервер продолжит крутить запущенный рой в фоновом режиме. Чтобы действительно остановить выполнение, требуется отправить ассистенту отдельное текстовое требование прекратить прогон и дождаться финального события со статусом stopped.
Следить за практическими тонкостями автоматизации и разбираться в скрытых нюансах запуска агентских систем гораздо проще вместе с коллегами: свежий опыт и проверенные разборы мы регулярно публикуем в нашем сообществе.
Лимиты на 64 ветки и таймер, который тикает даже на паузе
Масштабирование фонового роя упирается в чёткие системные границы, которые разработчики зафиксировали в документации. Внутри одного прогона платформа позволяет одновременно держать до 64 рабочих веток, хотя само это число сервис оставляет за собой право динамически корректировать в зависимости от нагрузки. За всё время жизни одного сценария разрешено запустить суммарно не более 1000 агентов с учётом повторных попыток при падениях — превышение этого потолка немедленно обрывает исполнение с системной ошибкой.
Время жизни каждого прогона ограничено 24 часами, если только сама программа не установит более короткий срок. При этом действует неочевидное правило: постановка сессии на паузу не останавливает общий таймер жизни прогона. Если сценарий провисит в подвешенном состоянии сутки, он закроется по таймауту точно так же, как если бы всё это время непрерывно считал данные. Одновременно в одной сессии допускается держать не более 10 открытых прогонов, включая те, что просто простаивают в ожидании.
Финансовая сторона работы с роем тоже требует аккуратности. Отдельной платы за сам запуск динамического сценария нет: токены списываются по базовым тарифам задействованных моделей в общий баланс сессии. За время работы сессии платформа начисляет 8 центов за каждый час в активном статусе running, причём ожидание подтверждений инструментов или простой плату не генерируют. Параллельные ветки не перемножают стоимость часов: система суммирует только секунды, когда была активна хотя бы одна нить.
Как защитить сессию от скрытого перерасхода
Самое строгое финансовое ограничение связано с бюджетом. Потолок расходов на сессию разрешено задать исключительно в момент её первоначального создания. Если сессия стартовала без лимита, добавить ограничение задним числом уже не выйдет — его можно лишь скорректировать или снять, если бюджет был предусмотрен заранее. Когда лимит исчерпан, все открытые сценарии немедленно замирают, хотя единичный запрос, отправленный до срабатывания отсечки, может немного превысить заданную сумму.
Отдельной кнопки в API для ручного старта роя не предусмотрено — решение о запуске сценария модель принимает самостоятельно после получения сообщения от пользователя. Поэтому единственный способ управлять этим поведением — чётко прописать правила в системных инструкциях. Там стоит прямо указать, при каком объёме входящих данных ассистент обязан переходить к программному прогону (например, если файлов больше пяти), как распределять нагрузку по веткам и какой жёсткий тайм-аут ставить на выполнение.
Когда вы поручаете нейросети пакетную рутину, не полагайтесь на внешнюю бодрость интерфейса. Проверяйте код созданного сценария после остановки, требуйте персональный статус по каждому обработанному документу и закладывайте финансовый потолок ещё до того, как первая задача уйдёт на сервер.
