Google Antigravity lansează Orchestrator pentru transferuri dinamice între modele

Google Antigravity a anunțat pe 12 noiembrie 2026 că Orchestrator, o opțiune din meniul de selectare a modelelor, lansată treptat pentru abonații Google AI Ultra, a atins o rată de succes a sarcinilor apropiată de cea a Carbon pe Terminal-Bench 4.1, folosind în medie cu 24% mai puțină cotă și finalizând sarcinile cu 19% mai repede prin comutarea dinamică între Gemini 4 Carbon și Gemini 4 Hydrogen în cadrul aceleiași sesiuni.

Noul model Hydrogen este lansat separat în Antigravity pentru abonații plătitori Google AI Pro și Ultra, iar companiile pot accesa ambele modele prin Gemini for business. Google afirmă că, în viitor, Orchestrator va accepta modele și planuri de abonament suplimentare și îl descrie pe Hydrogen drept contraponderea lui Carbon și a raționamentului mai aprofundat, desfășurat pe orizonturi mai lungi, oferit de Argon.

Transferuri dinamice între modele într-o singură sesiune

Orchestrator este conceput pentru dezvoltarea obișnuită de funcționalități și depanare, situații în care folosirea unui model de raționament de ultimă generație și a mai multor agenți care lucrează în paralel pe parcursul întregii sesiuni poate încetini iterațiile și poate consuma din cota pentru modelele de ultimă generație. În schimb, un router static obișnuit estimează dificultatea pe baza mesajului inițial, apoi atribuie întreaga sarcină celui mai ieftin model pe care îl consideră suficient. Potrivit Google, această alocare unică nu se potrivește agenților care rulează perioade îndelungate, deoarece cerințele unei sarcini se pot schimba și devin clare abia în timpul execuției.

Pe măsură ce sarcina evoluează, Orchestrator poate comuta în ambele sensuri între cele două modele. În exemplul Google, Carbon începe prin a investiga dependențele fără a le modifica, clarifică ambiguitățile și elaborează un plan care include condiții explicite ce ar declanșa replanificarea. Hydrogen implementează apoi modificările, actualizează pachetele și rulează teste. Dacă Hydrogen întâmpină dificultăți, Carbon preia din nou controlul pentru a inspecta starea curentă, a corecta planul și a continua execuția. Astfel, într-o sesiune se poate apela la un raționament mai aprofundat pentru planificare sau recuperare, fără a atribui aceluiași model fiecare etapă de implementare.

Roluri explicite pentru modele prin SDK

Dezvoltatorii care doresc atribuiri explicite, în locul comutării automate, pot conecta Hydrogen și Carbon prin SDK-ul Antigravity. Astfel, pot controla programatic ce model îndeplinește fiecare rol într-un flux de lucru cu mai mulți agenți.

În demonstrația Google cu cod-sursă deschis pentru trierea problemelor, agenții Hydrogen gestionează volumul de probleme primite: le triază și scriu cod, caută în baza de cod, adresează întrebări de clarificare și iterează asupra modificărilor interfeței de utilizator pe baza comentariilor la cererile de integrare. Unui agent Carbon îi sunt atribuite refactorizările ample, funcționalitățile noi și verificările de securitate. Demonstrația folosește aceeași împărțire generală între execuția rapidă și raționamentul mai aprofundat, dar limitele sunt definite de dezvoltator, nu lăsate în seama Orchestrator.

Prin ce se deosebește Orchestrator de /Swarm

Orchestrator vine după previzualizarea din 10 noiembrie 2026 a Gemini 4 Carbon și /swarm, destinată activităților de inginerie desfășurate în numeroase fișiere și suite de teste. Potrivit documentației /swarm, un coordonator poate împărți o sarcină între lucrători desemnați, care se ocupă de fișiere, pachete sau întrebări distincte, în timp ce verificatorii analizează diferențele și rulează teste; lucrătorii pot primi și copii de lucru izolate ale unui depozit de cod. Orchestrator răspunde unei nevoi diferite: schimbă modelul folosit în cadrul unei singure sesiuni aflate în evoluție, în loc să formeze o echipă care să lucreze în paralel la componente independente.

Împreună, aceste funcționalități permit organizarea muncii agenților în două moduri diferite: între agenți, atunci când un proiect poate fi împărțit, și între modele, atunci când o singură conversație trece de la planificare la execuție și remediere. Schimbarea practică este că alegerea modelului nu mai trebuie să fie o decizie unică, luată la trimiterea mesajului inițial; ea poate deveni parte a arhitecturii fluxului de lucru, fie prin adaptarea automată oferită de Orchestrator, fie prin atribuirea explicită a rolurilor prin SDK.