Google Antigravity wprowadza Orchestrator do dynamicznego przełączania modeli

Google Antigravity poinformowało 12 listopada 2026 r., że Orchestrator — opcja w rozwijanym menu modeli wdrażana dla subskrybentów Google AI Ultra — osiągnął skuteczność w wykonywaniu zadań zbliżoną do modelu Carbon w teście Terminal-Bench 4.1, zużywając średnio o 24% mniej limitu i kończąc zadania o 19% szybciej dzięki dynamicznemu przełączaniu między Gemini 4 Carbon i Gemini 4 Hydrogen w trakcie jednej sesji.

Nowy model Hydrogen jest udostępniany oddzielnie w Antigravity płatnym subskrybentom Google AI Pro i Ultra, a przedsiębiorstwa mogą korzystać z obu modeli za pośrednictwem Gemini for business. Google informuje, że w przyszłości Orchestrator będzie obsługiwać kolejne modele i plany subskrypcji. Opisuje też Hydrogen jako model do szybkiego wykonywania zadań, uzupełniający Carbon i Argon, które lepiej sprawdzają się w głębszym rozumowaniu obejmującym dłuższy horyzont.

Dynamiczne przełączanie modeli w jednej sesji

Orchestrator jest przeznaczony do rutynowego tworzenia funkcji i debugowania — zadań, w których poleganie przez całą sesję na czołowym modelu rozumującym i wielu równoległych agentach może spowalniać iteracje i zwiększać zużycie limitu dla zaawansowanych modeli. Tradycyjny, statyczny router szacuje natomiast poziom trudności na podstawie początkowego polecenia, a następnie przypisuje całe zadanie do najtańszego modelu, który uzna za wystarczający. Zdaniem Google taki jednorazowy przydział nie sprawdza się w przypadku długo działających agentów, ponieważ wymagania zadania mogą się zmieniać i stają się jasne dopiero w trakcie jego realizacji.

W miarę postępów Orchestrator może przełączać się między dwoma modelami w obu kierunkach. W przykładzie Google Carbon rozpoczyna od analizy zależności bez wprowadzania zmian, usuwa niejasności i przygotowuje plan zawierający jasno określone warunki, których spełnienie skutkuje ponownym opracowaniem planu. Następnie Hydrogen wprowadza zmiany, aktualizuje pakiety i uruchamia testy. Jeśli Hydrogen napotka trudności, Carbon ponownie przejmuje kontrolę, aby sprawdzić bieżący stan, poprawić plan i kontynuować pracę. Dzięki temu w ramach jednej sesji można skorzystać z głębszego rozumowania przy planowaniu lub rozwiązywaniu problemów, nie przypisując każdego etapu wdrożenia do tego samego modelu.

Jawne przypisywanie ról modelom za pomocą SDK

Programiści, którzy wolą jawnie przypisywać zadania zamiast korzystać z automatycznego przełączania, mogą połączyć Hydrogen i Carbon za pomocą Antigravity SDK. Daje im to programową kontrolę nad tym, który model pełni daną rolę w wieloagentowym przepływie pracy.

W demonstracji Google dotyczącej sortowania zgłoszeń, opartej na otwartym kodzie źródłowym, agenci Hydrogen obsługują napływające zgłoszenia: sortują je i piszą kod, przeszukują bazę kodu, zadają pytania doprecyzowujące oraz wprowadzają kolejne zmiany w interfejsie użytkownika na podstawie komentarzy do żądań ściągnięcia. Agent Carbon otrzymuje większe zadania związane z refaktoryzacją, tworzeniem nowych funkcji i kontrolą bezpieczeństwa. Demonstracja opiera się na tym samym ogólnym podziale między szybkim wykonywaniem zadań a głębszym rozumowaniem, ale to programista wyznacza granice zamiast powierzać to zadanie Orchestratorowi.

Czym Orchestrator różni się od /Swarm

Orchestrator pojawia się po zapowiedzi Gemini 4 Carbon i /swarm z 10 listopada 2026 r., skierowanych do prac inżynieryjnych obejmujących wiele plików i zestawów testów. Zgodnie z dokumentacją /swarm koordynator może podzielić zadanie między nazwanych pracowników, z których każdy zajmuje się osobnymi plikami, pakietami lub pytaniami, podczas gdy weryfikatorzy sprawdzają różnice w kodzie i uruchamiają testy. Pracownicy mogą też otrzymać odizolowane kopie robocze repozytorium. Orchestrator obsługuje inny model pracy: zmienia model wykorzystywany w trakcie jednej rozwijającej się sesji zamiast tworzyć zespół pracujący równolegle nad niezależnymi częściami zadania.

Łącznie funkcje te dzielą pracę agentów na dwa różne sposoby: między agentów, gdy projekt można podzielić na części, oraz między modele, gdy jedna rozmowa przechodzi od planowania przez realizację po naprawianie problemów. W praktyce oznacza to, że wybór modelu nie musi już być jednorazową decyzją podejmowaną przy wpisywaniu polecenia — może stać się elementem architektury przepływu pracy, dostosowywanym automatycznie przez Orchestrator albo określanym jawnie za pomocą SDK.