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 for business. Google повідомляє, що в майбутньому Orchestrator підтримуватиме й інші моделі та плани підписки, і характеризує Hydrogen як модель для швидкого виконання завдань, що доповнює Carbon і Argon із їхніми глибшими міркуваннями на довгому горизонті.

Динамічне перемикання між моделями в межах одного сеансу

Orchestrator призначений для повсякденної розробки функцій і налагодження, де використання передової моделі для логічних міркувань і кількох паралельних агентів протягом усього сеансу може сповільнити ітерації та збільшити витрати квоти передової моделі. Звичайний статичний маршрутизатор натомість оцінює складність за початковим запитом, а потім доручає все завдання найдешевшій моделі, яку вважає достатньо потужною. За словами Google, такий одноразовий розподіл погано підходить для тривалих сеансів роботи агентів, адже потреби завдання можуть змінюватися, а їх стає зрозуміло лише під час виконання.

У міру розвитку робочого процесу Orchestrator може перемикатися між двома моделями в обох напрямках. У прикладі Google Carbon спочатку досліджує залежності, не вносячи змін, усуває неоднозначності й готує план із чітко визначеними умовами, за яких потрібно буде його переглянути. Потім Hydrogen вносить зміни, оновлює пакети й запускає тести. Якщо Hydrogen стикається з труднощами, Carbon знову перебирає керування, щоб перевірити поточний стан, скоригувати план і продовжити виконання. Отже, у межах одного сеансу можна залучити глибші міркування для планування чи відновлення роботи, не доручаючи кожен крок реалізації тій самій моделі.

Як призначати ролі моделям через SDK

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

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

Чим Orchestrator відрізняється від /Swarm

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

Разом ці функції дають змогу організувати роботу агентів двома різними способами: розподіляти її між агентами, якщо проєкт можна поділити на частини, або між моделями, якщо в межах однієї розмови відбувається перехід від планування до виконання й виправлення помилок. Практична зміна полягає в тому, що вибір моделі більше не має бути одноразовим рішенням на початку роботи: він може стати частиною архітектури робочого процесу — адаптивної в Orchestrator або заданої явно через SDK.