Google lança o Orchestrator para alternância dinâmica entre modelos

O Google anunciou em 12 de novembro de 2026 que o Orchestrator, uma opção no menu suspenso de modelos que está sendo disponibilizada aos assinantes do Google AI Ultra, alcançou uma taxa de sucesso em tarefas próxima à do Carbon no Terminal-Bench 4.1, com consumo médio de cota 24% menor e conclusão 19% mais rápida, alternando dinamicamente entre Gemini 4 Carbon e Gemini 4 Hydrogen durante uma única sessão.

O novo modelo Hydrogen está sendo disponibilizado separadamente no Antigravity para assinantes pagantes do Google AI Pro e do Ultra, enquanto empresas podem acessar os dois modelos pelo Gemini para empresas. O Google afirma que, no futuro, o Orchestrator oferecerá suporte a modelos e planos de assinatura adicionais e descreve o Hydrogen como a contraparte de execução rápida do Carbon e do raciocínio mais profundo e de longo prazo do Argon.

Alternância dinâmica entre modelos em uma única sessão

O Orchestrator é voltado ao desenvolvimento de recursos rotineiros e à depuração, situações em que depender de um modelo de raciocínio de ponta e de vários agentes paralelos durante toda a sessão pode tornar a iteração mais lenta e consumir a cota de modelos de ponta. Um roteador estático convencional, por outro lado, estima a dificuldade com base no prompt inicial e, em seguida, atribui a tarefa inteira ao modelo mais barato que considera suficiente. Segundo o Google, essa alocação feita uma única vez não funciona bem para agentes de longa duração, pois as exigências de uma tarefa podem mudar e só ficam claras durante a execução.

O Orchestrator pode alternar entre os dois modelos em qualquer direção à medida que a execução avança. No exemplo do Google, o Carbon começa investigando dependências em modo somente leitura, esclarece ambiguidades e produz um plano com condições explícitas que levariam a um novo planejamento. Em seguida, o Hydrogen implementa alterações, atualiza pacotes e executa testes. Se o Hydrogen encontrar obstáculos, o Carbon retoma o controle para inspecionar o estado atual, corrigir o plano e dar continuidade à execução. Assim, uma sessão pode recorrer a um raciocínio mais profundo para planejar ou se recuperar de problemas, sem atribuir todas as etapas de implementação ao mesmo modelo.

Atribuição explícita de funções aos modelos pelo SDK

Desenvolvedores que preferem atribuições explícitas à alternância automática podem conectar o Hydrogen e o Carbon pelo SDK do Antigravity. Isso lhes dá controle programático sobre qual modelo desempenha cada função em um fluxo de trabalho com vários agentes.

Na demonstração de triagem de issues de código aberto do Google, agentes Hydrogen lidam com o volume de issues recebidas: fazem a triagem e programam, pesquisam a base de código, formulam perguntas para esclarecer dúvidas e iteram nas alterações da interface do usuário com base em comentários nos pull requests. Um agente Carbon fica encarregado de refatorações maiores, novos recursos e verificações de segurança. A demonstração adota a mesma divisão geral entre execução rápida e raciocínio mais profundo, mas é o desenvolvedor que define os limites, em vez de delegá-los ao Orchestrator.

Como o Orchestrator difere do /Swarm

O Orchestrator vem na sequência da prévia do Gemini 4 Carbon e do /swarm, em 10 de novembro de 2026, que tinha como foco trabalhos de engenharia distribuídos por muitos arquivos e conjuntos de testes. De acordo com a documentação do /swarm, um coordenador pode dividir uma tarefa entre trabalhadores identificados pelo nome, encarregados de arquivos, pacotes ou perguntas diferentes, enquanto verificadores analisam as diferenças e executam testes; os trabalhadores também podem receber cópias isoladas de um repositório para trabalhar. O Orchestrator atende a uma estrutura diferente: ele muda o modelo usado durante uma única sessão em evolução, em vez de formar uma equipe para trabalhar em partes independentes em paralelo.

Em conjunto, os recursos dividem o trabalho com agentes de duas formas distintas: entre agentes, quando um projeto pode ser particionado, e entre modelos, quando uma mesma conversa passa por planejamento, execução e correção. Na prática, a escolha do modelo deixa de precisar ser uma decisão única, tomada no prompt, e pode passar a fazer parte da arquitetura do fluxo de trabalho — de forma adaptativa com o Orchestrator ou por atribuição explícita pelo SDK.