Google Antigravity incorpora Orchestrator para cambiar dinámicamente de modelo

Google anunció el 12 de noviembre de 2026 que Orchestrator, una opción del menú desplegable de modelos que se está implementando para los suscriptores de Google AI Ultra, alcanzó una tasa de éxito en tareas casi igual a la de Carbon en Terminal-Bench 4.1, con un uso medio de la cuota un 24 % menor y una finalización un 19 % más rápida gracias al cambio dinámico entre Gemini 4 Carbon y Gemini 4 Hydrogen en una misma sesión.

El nuevo modelo Hydrogen se está implementando por separado en Antigravity para los suscriptores de pago de Google AI Pro y Ultra, mientras que las empresas pueden acceder a ambos modelos a través de Gemini for business. Google afirma que, en el futuro, Orchestrator admitirá modelos y planes de suscripción adicionales, y describe Hydrogen como el modelo de ejecución rápida que complementa el razonamiento más profundo y a largo plazo de Carbon y Argon.

Cambio dinámico entre modelos en una misma sesión

Orchestrator está pensado para el desarrollo de funciones rutinarias y la depuración, tareas en las que depender de un modelo de razonamiento de última generación y de varios agentes en paralelo durante toda una sesión puede ralentizar las iteraciones y consumir cuota de modelos de última generación. En cambio, un enrutador estático convencional estima la dificultad a partir del mensaje inicial y asigna toda la tarea al modelo más barato que considera suficiente. Según Google, esta asignación única no se adapta bien a los agentes de larga duración, porque las exigencias de una tarea pueden cambiar y solo quedan claras durante su ejecución.

Orchestrator puede alternar entre los dos modelos en ambas direcciones a medida que avanza el proceso. En el ejemplo de Google, Carbon comienza investigando las dependencias en modo de solo lectura, resuelve ambigüedades y elabora un plan con condiciones explícitas que activarían una nueva planificación. A continuación, Hydrogen implementa los cambios, actualiza los paquetes y ejecuta pruebas. Si Hydrogen encuentra dificultades, Carbon retoma el control para inspeccionar el estado actual, corregir el plan y continuar la ejecución. Así, una sesión puede recurrir a un razonamiento más profundo para planificar o recuperarse de un problema, sin asignar todos los pasos de implementación al mismo modelo.

Asignación explícita de roles a los modelos mediante el SDK

Los desarrolladores que prefieran asignar los roles explícitamente en lugar de alternar los modelos de forma automática pueden conectar Hydrogen y Carbon mediante el SDK de Antigravity. Esto les da control programático sobre qué modelo se encarga de cada rol en un flujo de trabajo multiagente.

En la demostración de Google de clasificación de incidencias de código abierto, los agentes Hydrogen gestionan el volumen de incidencias entrantes: las clasifican y programan, buscan en la base de código, plantean preguntas para aclarar dudas e iteran sobre cambios en la interfaz de usuario a partir de comentarios en solicitudes de cambios. A un agente Carbon se le asignan refactorizaciones más grandes, nuevas funciones y comprobaciones de seguridad. La demostración aplica la misma división general entre ejecución rápida y razonamiento más profundo, pero es el desarrollador quien define los límites, en lugar de delegar esa tarea en Orchestrator.

En qué se diferencia Orchestrator de /Swarm

Orchestrator llega después de la vista previa de Gemini 4 Carbon y /swarm del 10 de noviembre de 2026, destinada a tareas de ingeniería distribuidas entre muchos archivos y conjuntos de pruebas. Según la documentación de /swarm, un coordinador puede dividir una tarea entre trabajadores identificados por nombre, encargados de archivos, paquetes o preguntas diferentes, mientras que los verificadores revisan las diferencias y ejecutan pruebas; los trabajadores también pueden recibir copias de trabajo aisladas de un repositorio. Orchestrator aborda una estructura distinta: cambia el modelo utilizado durante una misma sesión en desarrollo, en lugar de crear un equipo que trabaje en paralelo en partes independientes.

En conjunto, estas funciones dividen el trabajo con agentes de dos maneras distintas: entre agentes, cuando un proyecto se puede desglosar, y entre modelos, cuando una conversación pasa de la planificación a la ejecución y la corrección. En la práctica, ya no es necesario elegir un modelo una sola vez al enviar la solicitud: esa elección puede formar parte de la arquitectura del flujo de trabajo, ya sea de manera adaptativa con Orchestrator o mediante una asignación explícita a través del SDK.