Google Antigravity запускает Orchestrator для динамического переключения моделей

12 ноября 2026 года Google сообщила, что Orchestrator — вариант в раскрывающемся списке моделей, который постепенно становится доступен подписчикам Google AI Ultra, — почти достиг уровня Carbon по успешности выполнения задач в Terminal-Bench 4.1. При этом средний расход квоты оказался на 24% ниже, а задачи выполнялись на 19% быстрее благодаря динамическому переключению между Gemini 4 Carbon и Gemini 4 Hydrogen в рамках одного сеанса.

В Antigravity отдельно становится доступна новая модель Hydrogen для платных подписчиков Google AI Pro и Ultra, а корпоративные клиенты могут пользоваться обеими моделями через Gemini для бизнеса. Google сообщает, что в будущем Orchestrator будет поддерживать дополнительные модели и тарифные планы, и описывает Hydrogen как модель для быстрого выполнения задач, дополняющую Carbon и Argon с их более глубоким рассуждением на длительном горизонте.

Динамическое переключение моделей в рамках одного сеанса

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

По мере развития задачи Orchestrator может переключаться между двумя моделями в обоих направлениях. В примере Google Carbon начинает с изучения зависимостей без внесения изменений, устраняет неоднозначности и составляет план с чётко обозначенными условиями, при которых потребуется его пересмотреть. Затем Hydrogen вносит изменения, обновляет пакеты и запускает тесты. Если Hydrogen сталкивается с трудностями, Carbon снова берёт управление на себя, изучает текущее состояние, корректирует план и продолжает выполнение. Таким образом, в рамках одного сеанса можно задействовать более глубокие рассуждения для планирования или восстановления после затруднений, не поручая каждый этап реализации одной и той же модели.

Явное распределение ролей между моделями через SDK

Разработчики, которым нужны явные назначения моделей вместо автоматического переключения, могут связать Hydrogen и Carbon через Antigravity SDK. Это позволяет программно определять, какая модель будет выполнять каждую роль в рабочем процессе с несколькими агентами.

В демонстрации Google с открытым исходным кодом по сортировке и обработке поступающих сообщений о проблемах агенты Hydrogen разбирают входящие запросы и пишут код, ищут информацию в кодовой базе, задают уточняющие вопросы и дорабатывают изменения пользовательского интерфейса на основе комментариев к запросам на слияние. Агенту Carbon поручают более масштабный рефакторинг, разработку новых функций и проверки безопасности. Демонстрация использует тот же общий принцип разделения быстрого выполнения и глубоких рассуждений, но границы между задачами определяет разработчик, а не Orchestrator.

Чем Orchestrator отличается от /Swarm

Orchestrator появился после предварительной презентации Gemini 4 Carbon и /swarm 10 ноября 2026 года, ориентированной на инженерные задачи, охватывающие множество файлов и наборов тестов. Согласно документации /swarm, координатор может распределить задачу между назначенными исполнителями, работающими с отдельными файлами, пакетами или вопросами, а проверяющие — изучать различия в коде и запускать тесты; исполнителям также можно предоставить изолированные рабочие копии репозитория. Orchestrator предназначен для другой схемы работы: он меняет используемую модель в ходе одного развивающегося сеанса, а не создаёт команду для параллельной работы над независимыми частями задачи.

В совокупности эти функции позволяют организовывать работу ИИ-агентов двумя разными способами: распределять её между агентами, когда проект можно разделить на отдельные части, или между моделями, когда в рамках одного диалога происходит переход от планирования к выполнению и исправлению ошибок. На практике выбор модели больше не обязательно должен быть единственным решением, принимаемым при составлении запроса: он может стать частью архитектуры рабочего процесса — адаптивной в Orchestrator или задаваемой явно через SDK.