Google Antigravity lancia Orchestrator per passare dinamicamente da un modello all’altro

Il 12 novembre 2026, Google Antigravity ha dichiarato che Orchestrator, un’opzione del menu dei modelli in fase di distribuzione per gli abbonati a Google AI Ultra, ha raggiunto un tasso di successo nelle attività quasi pari a quello di Carbon su Terminal-Bench 4.1, riducendo in media del 24% il consumo della quota e del 19% i tempi di completamento grazie al passaggio dinamico, nel corso di una singola sessione, da Gemini 4 Carbon a Gemini 4 Hydrogen e viceversa.

Il nuovo modello Hydrogen viene distribuito separatamente in Antigravity agli abbonati paganti a Google AI Pro e Ultra; le aziende possono invece accedere a entrambi i modelli tramite Gemini per le aziende. Google afferma che in futuro Orchestrator supporterà altri modelli e piani di abbonamento e descrive Hydrogen come il modello complementare a esecuzione rapida rispetto al ragionamento più approfondito e a lungo termine di Carbon e Argon.

Passaggio dinamico da un modello all’altro in un’unica sessione

Orchestrator è pensato per lo sviluppo di funzionalità ordinarie e il debug, attività per le quali affidarsi per tutta la sessione a un modello di ragionamento all’avanguardia e a più agenti paralleli può rallentare le iterazioni e consumare la quota destinata ai modelli all’avanguardia. Un router statico tradizionale stima invece la difficoltà a partire dal prompt iniziale e poi assegna l’intera attività al modello meno costoso che ritiene adeguato. Secondo Google, questa assegnazione una tantum si adatta male agli agenti che operano a lungo, perché le esigenze di un’attività possono cambiare e diventare chiare solo durante l’esecuzione.

Man mano che il lavoro procede, Orchestrator può passare da un modello all’altro in entrambe le direzioni. Nell’esempio di Google, Carbon inizia esaminando le dipendenze in sola lettura, chiarisce le ambiguità e prepara un piano con condizioni esplicite che comporterebbero una nuova pianificazione. Hydrogen apporta quindi le modifiche, aggiorna i pacchetti ed esegue i test. Se Hydrogen incontra difficoltà, Carbon riprende il controllo per esaminare lo stato corrente, correggere il piano e proseguire l’esecuzione. Una sessione può così ricorrere a un ragionamento più approfondito per pianificare o recuperare da un problema, senza assegnare ogni fase dell’implementazione allo stesso modello.

Assegnazione esplicita dei ruoli ai modelli tramite SDK

Gli sviluppatori che preferiscono assegnare i ruoli esplicitamente anziché affidarsi al passaggio automatico possono collegare Hydrogen e Carbon tramite l’SDK di Antigravity. In questo modo possono controllare a livello di codice quale modello svolge ciascun ruolo in un flusso di lavoro multi-agente.

Nella dimostrazione open source di Google per la gestione delle segnalazioni, gli agenti Hydrogen si occupano del flusso di segnalazioni in arrivo: le smistano e scrivono codice, esplorano la base di codice, pongono domande di chiarimento e iterano sulle modifiche all’interfaccia utente a partire dai commenti nelle richieste di pull. A un agente Carbon vengono assegnati interventi di refactoring più ampi, nuove funzionalità e controlli di sicurezza. La dimostrazione adotta la stessa ripartizione generale tra esecuzione rapida e ragionamento più approfondito, ma i confini vengono definiti dallo sviluppatore, anziché essere delegati a Orchestrator.

In che cosa Orchestrator differisce da /Swarm

Orchestrator arriva dopo l’anteprima del 10 novembre 2026 di Gemini 4 Carbon e /swarm, pensata per attività di ingegneria distribuite su numerosi file e suite di test. Secondo la documentazione di /swarm, un coordinatore può suddividere un’attività tra collaboratori designati, incaricati di gestire file, pacchetti o quesiti distinti, mentre i verificatori esaminano le differenze e svolgono i test; ai collaboratori possono anche essere fornite copie isolate del repository su cui lavorare. Orchestrator risponde a una struttura diversa: cambia il modello utilizzato nel corso di un’unica sessione in evoluzione, anziché creare un gruppo che lavori in parallelo su parti indipendenti.

Nel loro insieme, queste funzionalità ripartiscono il lavoro degli agenti in due modi diversi: tra più agenti, quando un progetto può essere suddiviso, e tra più modelli, quando un’unica conversazione passa dalla pianificazione all’esecuzione e alla correzione. In pratica, non è più necessario scegliere il modello una sola volta, al momento di formulare il prompt: la scelta può entrare a far parte dell’architettura del flusso di lavoro, adattandosi automaticamente con Orchestrator oppure venendo assegnata esplicitamente tramite l’SDK.