El modelo de IA de Google orientado a la ejecución plantea una pregunta de arquitectura: ¿debe una aplicación usar un solo modelo capaz en todo un flujo de trabajo o repartir el trabajo entre modelos con distintas fortalezas?
Imagina que le pides a un asistente de programación con IA que incorpore control de acceso basado en roles a una aplicación existente. Tiene que localizar el código de autenticación, entender qué servicios aplican permisos, planificar el cambio, escribir el código y comprobar que los usuarios normales no pueden realizar acciones administrativas.
Un solo modelo capaz podría intentar hacerlo todo. Pero entender un límite de seguridad es distinto de aplicar un cambio de código bien definido o de ejecutar una prueba existente. ¿Necesita cada paso la misma capacidad de razonamiento y debería tener el mismo precio?
El anuncio de Gemini 4 Hydrogen que Google publicó el 12 de noviembre de 2026 pone esta pregunta en primer plano. Google presenta Hydrogen como un modelo para programación rápida y ejecución con agentes, mientras que sus modelos Gemini 4 Carbon y Argon se centran en el razonamiento exigente. Su Orchestrator de Antigravity puede cambiar de modelo durante un flujo de trabajo. El anuncio de Google describe el enfoque, pero una demostración de producto no es una prueba de que sea la mejor arquitectura para todas las aplicaciones.
La pregunta práctica es ¿cuándo ayuda un modelo adicional lo suficiente como para justificar otro límite, otra llamada y otra forma de que el sistema falle?
Por qué un solo modelo de IA puede no bastar
Un equipo de desarrollo suele elegir un modelo de IA evaluando el razonamiento, la capacidad de programar, el tiempo de respuesta, el tamaño del contexto y el precio. Después usa ese modelo para toda la aplicación. Es una opción predeterminada razonable: la integración es más sencilla, hay menos piezas que supervisar y el modelo puede mantener un contexto de trabajo coherente.
Sin embargo, los flujos de trabajo reales contienen tipos de trabajo distintos. Nuestro asistente de programación debe interpretar un requisito, descubrir los archivos relevantes, determinar dónde corresponde la autorización, editar componentes e interpretar los fallos de las pruebas. La decisión de arquitectura no equivale a buscar un archivo. Un modelo muy bueno en razonamiento difícil puede costar más de lo necesario para una ejecución rutinaria, mientras que un modelo más barato puede ser rápido pero pasar por alto una dependencia que importa.
Esto abre la posibilidad de la asignación de modelos por tarea: asignar un modelo más capaz a las decisiones difíciles y otro modelo distinto a la ejecución acotada. No exige ejecutar varios modelos en paralelo. Puede consistir en cambiar de modelo solo cuando una tarea supera un umbral definido de complejidad o incertidumbre.
El ahorro aparente conlleva una obligación: la aplicación debe seguir entregando un resultado correcto, y no solo respuestas individuales más baratas.
Qué presentó Google con Gemini 4 Hydrogen
Google describe Hydrogen como un modelo orientado a la ejecución para programación iterativa, depuración, uso de herramientas y trabajo del conocimiento multimodal. Su ficha del modelo indica que está adaptado de Gemini 4 Carbon. Acepta texto, imágenes, audio y video, con una ventana de contexto combinada de hasta un millón de tokens. La salida síncrona predeterminada está limitada a 64 000 tokens, mientras que la opción de decodificación larga en segundo plano de Google llega hasta un millón. No son afirmaciones intercambiables sobre la salida habitual de la API.
Hydrogen ofrece cuatro niveles de razonamiento (low, medium, high y xhigh), y Google indica tarifas estándar de la API de US$1.50 por millón de tokens de entrada y US$7.50 por millón de tokens de salida. Google dice que se distribuye a través de la Gemini API, AI Studio, Antigravity y otros productos de Google. El acceso real, las cuotas y las condiciones comerciales aplicables deben comprobarse para el producto y la cuenta que se utilicen.
En Antigravity, Google dice que Orchestrator puede cambiar entre modelos como Carbon y Hydrogen en una misma sesión de desarrollo. Carbon puede encargarse de la planificación difícil mientras Hydrogen realiza los pasos de implementación o verificación. Google informa de un éxito de tareas cercano al de Carbon en Terminal-Bench 4.0 con 24 % menos de cuota consumida y una finalización 19 % más rápida de media. Google no indica qué nivel de razonamiento o configuración usó, ni cuántas tareas. Son resultados de Google, y la cifra de cuota no equivale automáticamente a una reducción del 24 % en la factura de una organización. Orchestrator forma parte de Google Antigravity, que Google ofrece a los suscriptores de pago de Google AI Pro y Ultra. Anuncio de lanzamiento.
El enrutamiento de modelos y los agentes especializados ya eran patrones de diseño establecidos. Hydrogen es una opción nueva dentro de esa arquitectura, no la invención de la IA multimodelo.
Un modelo frente a varios: un ejemplo práctico
Volvamos a la función de control de acceso basado en roles. Se pide que los administradores puedan gestionar roles sin que los usuarios normales puedan invocar los endpoints administrativos.
Flujo con un solo modelo. Un asistente de programación lee el repositorio, identifica las funciones afectadas, propone y aplica los cambios, ejecuta las pruebas e investiga los fallos. Su ventaja es la continuidad: un solo modelo y un solo historial principal de ejecución. Su desventaja puede ser el uso de un razonamiento costoso en subtareas simples. Ese costo importa solo si la carga de trabajo es lo bastante frecuente y costosa como para justificar una optimización.
Flujo con planificador y ejecutor. Un modelo más potente identifica las reglas de autorización, los controladores de API afectados, los procesos en segundo plano y las dependencias de datos. Pasa una tarea acotada (con los archivos permitidos, los invariantes de seguridad y las expectativas de las pruebas) a un modelo de ejecución. El ejecutor implementa el cambio. Un verificador revisa el resultado, y las dudas de diseño inesperadas vuelven al planificador en lugar de que el ejecutor las resuelva en silencio.
Alternativa textual accesible para esta figura
Un solo modelo: Leer el repositorio, Planificar el cambio, Editar el código, Ejecutar pruebas de acceso, Aprobar si pasan.
Planificador, ejecutor y verificador: El planificador fija las reglas, El ejecutor edita el código, El verificador revisa el resultado, Ejecutar pruebas de acceso, Aprobar si pasan.
Ambos diseños terminan con pruebas deterministas de control de acceso. Los tres roles no son necesariamente tres modelos distintos.
Ese segundo flujo puede ser eficiente, pero introduce un modo de fallo peligroso. Supongamos que el planificador olvida que un trabajo en segundo plano también aplica permisos. Un ejecutor podría implementar a la perfección la tarea escrita y dejar ese trabajo expuesto. Un verificador que use el mismo encargo incompleto podría aprobarlo.
La solución no es simplemente otro revisor de IA. La aplicación necesita requisitos de referencia y pruebas deterministas de control de acceso, incluidas pruebas negativas que demuestren que se deniega el acceso a los usuarios no autorizados. La IA puede ayudar a proponer y examinar cambios, pero la aplicación de los permisos corresponde al software y a sus controles de despliegue.
Cómo funciona la orquestación multimodelo
Un orquestador asigna tareas, proporciona el contexto relevante, coordina las llamadas a herramientas, recoge los resultados y decide cuándo reintentar, escalar o detenerse. Un patrón habitual tiene tres roles:
- Planificador: interpreta la solicitud, examina las dependencias y establece los límites de la implementación.
- Ejecutor: realiza actividades acotadas, como editar código, recuperar evidencia o investigar un fallo de una prueba.
- Verificador: comprueba el resultado frente a la tarea e informa de la evidencia que falta o de los defectos.
Son roles, no necesariamente tres modelos distintos. Un mismo modelo puede cumplir varios roles, y las pruebas o los motores de políticas pueden realizar verificaciones importantes sin un modelo de IA.
Hay variantes útiles. En el enrutamiento secuencial, una etapa pasa el trabajo a la siguiente. En la ejecución en paralelo, ejecutores independientes actúan en espacios de trabajo aislados y los resultados se integran después. En el enrutamiento por escalado, un modelo de menor costo atiende las solicitudes rutinarias pero deriva los casos inciertos a un modelo más potente.
Una alternativa aún más sencilla es mantener un solo modelo y variar su esfuerzo de razonamiento. Los cuatro niveles de Hydrogen convierten eso en una elección explícita. Antes de construir un orquestador, comprueba si un nivel de razonamiento bajo puede encargarse del trabajo rutinario mientras el nivel high resuelve los casos difíciles.
Este artículo trata la orquestación a nivel de tarea. Para cuestiones más amplias sobre credenciales centralizadas, elegibilidad de modelos, cuotas y políticas de los proveedores, el artículo de TechiesJournal API Gateway vs AI Gateway explica un límite de arquitectura distinto. Una puerta de enlace puede controlar qué modelos puede llamar una aplicación. No determina por sí sola cómo deben planificarse o verificarse las tareas de la aplicación.
¿Usar varios modelos ahorra dinero de verdad?
El precio de una sola solicitud no es el costo de completar un flujo de trabajo. Un diseño con planificador y ejecutor puede enviar menos solicitudes costosas, pero también transfiere contexto, consume tokens adicionales en la coordinación, reintenta los fallos y realiza la verificación.
Considera una carga de trabajo ficticia en la que el enfoque de un solo modelo cuesta $0.40 por tarea completada con éxito. Una segunda arquitectura parece costar $0.25 en llamadas de planificación y ejecución, pero la sobrecarga de reintentos y revisión eleva el costo final a $0.38. Su ahorro aparente del 37.5 % baja al 5 %. Estos números son ilustrativos, no mediciones de Hydrogen.
La latencia funciona de forma parecida. Las tareas independientes en paralelo pueden terminar antes. Los traspasos secuenciales pueden hacer más lenta una tarea. Las medidas útiles son el costo por tarea correcta completada, el tiempo total transcurrido, la tasa de fallos y la intervención humana. Contar solo los precios de tokens de entrada y salida puede ocultar un costoso trabajo repetido.
El esfuerzo de razonamiento también cambia la economía. Las mediciones independientes de Artificial Analysis indican lo siguiente para Hydrogen, tal como figuran el 13 de noviembre de 2026 (las páginas no indican la fecha de la medición):
| Nivel de razonamiento | Intelligence Index | Costo por tarea evaluada | Tiempo por tarea evaluada |
|---|---|---|---|
| High | 51 | US$1.87 | 7.9 minutos |
| Xhigh | 54 | US$3.16 | 13.7 minutos |
Estos tiempos y costos se refieren a tareas del Artificial Analysis Intelligence Index, no a solicitudes de programación habituales. Xhigh mejora el índice en tres puntos y aumenta el costo medido en aproximadamente un 69 % y el tiempo en aproximadamente un 73 %. La elección correcta depende de si el razonamiento adicional mejora realmente el resultado para la aplicación. Medición de high · Medición de xhigh.
Cómo se compara Hydrogen con los modelos de otros proveedores
Google no es el único que ofrece modelos distintos para tareas distintas. Entre las opciones hay otros modelos capaces de programar y opciones más pequeñas adecuadas para el enrutamiento, la extracción y las operaciones repetidas de bajo riesgo. La tabla siguiente muestra las tarifas estándar publicadas de la API en dólares estadounidenses por millón de tokens de entrada y salida, según la revisión del 13 de noviembre de 2026. Las condiciones propias de cada proveedor, el almacenamiento en caché, los cargos por herramientas, la tokenización y los niveles de servicio pueden afectar a los costos reales.
| Modelo y proveedor | Entrada / salida | Uso relevante o rasgo distintivo |
|---|---|---|
| Gemini 4 Hydrogen (Google) | $1.50 / $7.50 | Programación y agentes orientados a la ejecución, razonamiento configurable |
| GPT-6.1 Sol (OpenAI) | $2.00 / $10.00 | Rendimiento cercano a Astra para trabajo complejo a menor costo, según OpenAI |
| Claude Sonnet 5.5 (Anthropic) | $2.00 / $10.00 | Equilibrio entre velocidad e inteligencia, según Anthropic |
| Mistral Small 4 (Mistral) | $0.15 / $0.60 | Razonamiento híbrido y programación, licencia Apache 2.0, pesos abiertos |
| DeepSeek V4.1 Flash 1017 (alojado por Mistral) | $0.30 / $1.20 | Modelo de programación de contexto largo alojado por un tercero, versión preliminar pública |
Tarifas y roles: Google, OpenAI, Anthropic, Mistral Small 4, DeepSeek alojado por Mistral. La fila de DeepSeek es el precio del alojamiento de Mistral, no un precio verificado de la API directa de DeepSeek. Las filas no implican un rendimiento idéntico en las pruebas de referencia ni condiciones de servicio equivalentes.
OpenAI ofrece GPT-6 Astra para trabajo exigente, GPT-6.1 Sol para un equilibrio entre costo y capacidad y GPT-6 Luna para trabajo específico de gran volumen. Este último figura a $0.10 de entrada y $0.50 de salida por millón de tokens, pero un precio bajo no demuestra que pueda sustituir a un agente de programación más potente. El desarrollador debe comparar las tasas reales de éxito de las tareas. Catálogo de modelos de OpenAI.
Anthropic distingue de forma similar Sonnet 5.5 de Haiku 5.5, que Anthropic posiciona para tareas de gran volumen y sensibles a la latencia, como la clasificación, la extracción y el enrutamiento. Anthropic lista Haiku desde $0.10 de entrada y $0.50 de salida por millón de tokens. Los distintos tokenizadores y ajustes de esfuerzo complican las comparaciones basadas solo en el precio de lista. Modelos de Anthropic.
Mistral Small 4 aporta una dimensión distinta: pesos abiertos y flexibilidad de despliegue. Las organizaciones pueden evaluar el autoalojamiento, pero los servidores, la utilización, la supervisión y el mantenimiento son costos reales. Un precio bajo de la API y una licencia abierta no son lo mismo que una garantía de bajo costo total. Documentación de Mistral.
DeepSeek V4.1 Flash 1017 es la versión actualizada del 17 de octubre que se sirve con el nombre deepseek-flash en la API de DeepSeek, según su registro de cambios. Mistral también lo ofrece como modelo de terceros en versión preliminar pública, sin modificaciones de Mistral. Esas ofertas pueden tener precios y condiciones operativas distintos. No debemos tratar un resultado de Terminal-Bench 4.0 informado por DeepSeek como directamente comparable con la puntuación de Terminal-Bench 4.1 de otro proveedor.
La decisión no consiste en qué proveedor gana una clasificación general. Consiste en si un modelo concreto desempeña de forma fiable el rol elegido con las herramientas y los límites de seguridad previstos. A veces el mejor diseño usa un solo proveedor y varios niveles. A veces un proveedor distinto aporta valor. Operar con varios proveedores también añade complejidad de API, privacidad, disponibilidad y resolución de problemas.
Dónde puede fallar la orquestación multimodelo
Un segundo modelo introduce una segunda interpretación de la tarea. Los requisitos pueden perderse cuando el planificador reduce el problema original a un encargo. Los ejecutores pueden producir código de apariencia compatible que viole una restricción omitida. Los agentes en paralelo pueden editar interfaces en conflicto, y los revisores pueden compartir la misma premisa equivocada que el autor del código.
Por eso el orquestador necesita un contrato de tarea explícito, permisos acotados, evidencia de cada acción con herramientas, reglas de escalado y una forma fiable de identificar los cambios exactos que se están probando. No debería permitirse que un modelo apruebe su propio despliegue en producción solo porque la explicación que genera suene convincente.
La ficha del modelo de Google también documenta riesgos que persisten de alucinaciones, lentitud, tiempos de espera agotados y un mayor uso de tokens. En las evaluaciones internas automatizadas de seguridad, en comparación con Gemini 3.8 Flash, Google informa de un aumento de 5.57 puntos porcentuales en las negativas injustificadas. Google dice que la revisión manual posterior concluyó que la mayoría de las pérdidas señaladas eran falsos positivos o no eran graves. Ambas partes importan: la regresión automatizada es real tal como se informa, pero no es evidencia de un daño equivalente en el mundo real.
Para un debate más amplio sobre por qué los agentes capaces siguen necesitando una rendición de cuentas independiente, consulta el artículo de TechiesJournal La IA hace cada vez mejor el trabajo. Pero ¿está lista para hacerse cargo del resultado?. La pregunta de este artículo es más acotada: qué modelo debe hacer cada parte de la tarea, y no quién responde en última instancia de los resultados en producción.
Qué establecen y qué no establecen las pruebas de referencia
La ficha del modelo de Google informa de 57.0 % para Hydrogen en Terminal-Bench 4.1 ajustado por trampas, frente a 63.9 % para Claude Sonnet 5.5. Hydrogen obtiene mejores resultados en otras evaluaciones informadas. En Agents’ Last Exam v1.1, la ficha lista 71.6 % para Hydrogen frente a 60.4 % para Claude Sonnet 5.5, y Hydrogen también lidera en tareas multimodales seleccionadas. Un modelo puede liderar en una carga de trabajo y quedar por detrás en otra sin contradicción. Ficha del modelo de Google.
El informe de metodología identifica distintos entornos de evaluación y configuraciones. Por ejemplo, el resultado de Google en Terminal-Bench 4.1 usa cinco intentos por tarea promediados con un entorno especificado, mientras que varios resultados de la competencia proceden de clasificaciones públicas o de informes de los proveedores. Esto importa cuando se presenta una cifra destacada sin las condiciones de la prueba.
Artificial Analysis mide de forma independiente algunas características de inteligencia, velocidad y costo de Hydrogen, pero esas mediciones también representan una prueba de referencia definida, no una garantía sobre el repositorio privado de una aplicación.
La evidencia respalda una conclusión más acotada: Hydrogen es una opción creíble para los flujos de trabajo orientados a la ejecución, y el experimento de orquestación de Google sugiere un posible beneficio de eficiencia. No demuestra que el enrutamiento de modelos sea universalmente más barato, más fiable o más seguro. Las aplicaciones siguen necesitando su propia evaluación con tareas representativas.
Cómo elegir una arquitectura
Empieza con un solo modelo y un conjunto pequeño de tareas representativas. Para nuestro escenario de control de acceso basado en roles, incluye un caso de implementación normal, uno con una dependencia oculta y otro que deba rechazarse porque la operación solicitada excede los permisos. Usa el mismo código base, las mismas herramientas, los mismos requisitos y los mismos criterios de éxito en cada comparación.
Registra si el asistente encontró los límites afectados, si las pruebas de autorización pasaron, el tiempo total transcurrido, los cargos reales del proveedor, los reintentos y cualquier corrección humana. Después prueba un ajuste de razonamiento más bajo o un modelo más barato en una etapa acotada. Solo si los resultados lo justifican, añade un traspaso entre planificador y ejecutor.
| Situación | Enfoque inicial razonable |
|---|---|
| Tarea pequeña o poco frecuente | Un solo modelo capaz |
| Extracción o clasificación de gran volumen | Modelo de menor costo probado en cuanto a precisión |
| Planificación compleja con implementación predecible | Evaluar la separación entre planificador y ejecutor |
| Tareas independientes con interfaces controladas | Considerar ejecutores en paralelo |
| Acciones sensibles para la seguridad o que modifican producción | Comprobaciones deterministas y autorización obligatoria, sea cual sea el número de modelos |
| Requisitos inciertos o capacidad de ingeniería limitada | Mantener la arquitectura más sencilla hasta que la evidencia favorezca el cambio |
Si se introduce el enrutamiento, registra qué modelo atendió cada tarea, por qué se seleccionó y qué evidencia justificó su aceptación. De lo contrario, los problemas de costo y fiabilidad resultan difíciles de diagnosticar.
Qué deberían hacer ahora los desarrolladores
Hydrogen refleja una dirección real en los sistemas de IA: los desarrolladores pueden seleccionar modelos y ajustes de razonamiento para distintos tipos de trabajo en lugar de tratar todas las solicitudes por igual. Google ha hecho más explícita esa división con un modelo orientado a la ejecución y el Orchestrator de Antigravity.
Pero tener más opciones no elimina la responsabilidad del ingeniero de elegir bien. Un diseño multimodelo que ahorra tokens pero pierde requisitos críticos no es una mejora. Un solo modelo que completa la carga de trabajo de forma fiable a un costo aceptable puede ser la mejor arquitectura.
Empieza por la tarea de negocio o de ingeniería. Establece una línea base medible, examina dónde es útil el esfuerzo de razonamiento y prueba el cambio más pequeño que podría mejorar el resultado. Añade orquestación solo si la evidencia muestra que los límites adicionales valen la pena.
El objetivo no es usar más modelos de IA. Es aplicar la capacidad adecuada al trabajo adecuado y hacer que cada capa añadida se gane su lugar.
Referencias y lecturas adicionales
- Google: Introducing Gemini 4 Hydrogen (12 November 2026): posicionamiento, precios y afirmaciones sobre Orchestrator.
- Google DeepMind: Gemini 4 Hydrogen model card (12 November 2026): arquitectura, contexto, resultados de las pruebas de referencia, limitaciones y datos de seguridad.
- Google DeepMind: Hydrogen evaluation methodology (November 2026): entornos de evaluación, métodos de puntuación y límites de la comparación.
- Artificial Analysis: Hydrogen high y Hydrogen xhigh: mediciones independientes de inteligencia, costo y duración.
- OpenAI: API model catalog: posicionamiento oficial de los modelos y precios de tokens listados.
- Anthropic: Model overview: niveles de Claude, cargas de trabajo y precios.
- Mistral: Small 4 specifications: capacidades del modelo, licencia y precios.
- DeepSeek: API change log y Mistral: hosted DeepSeek V4.1 Flash: detalles de versión y específicos del alojamiento.
Las fuentes se leyeron el 13 de noviembre de 2026. Los precios de los proveedores, las condiciones de los modelos y la disponibilidad pueden cambiar.