Gemini 4 Carbon y Hydrogen funcionan mejor en pareja: Carbon planifica, Hydrogen construye. Asigna la Task a un Agent planificador en Carbon, deja que redacte subtareas con pruebas de aceptación, delégalas a Agents ejecutores y verificadores en Hydrogen, y redirige al planificador cualquier cosa que falle dos veces. Así, solo pagas tarifas de frontera en los turnos que realmente exigen ese nivel de criterio.
Por qué conviene combinar Gemini 4 Carbon y Hydrogen
Google lanzó Gemini 4 Hydrogen el 12 de noviembre de 2026, definiéndolo como el «caballo de batalla diario para flujos de trabajo agénticos». Dos días antes, el 10 de noviembre, el registro de cambios de la API de Gemini anunció la disponibilidad general de Gemini 4 Carbon. De este modo, por primera vez este mes, es posible combinar el modelo más potente de Google con su modelo de ejecución rápida en una misma Task.
La propuesta de Google para Hydrogen se apoya precisamente en esta combinación. El artículo de lanzamiento señala que Carbon puede actuar como coordinador mientras Hydrogen impulsa «agentes trabajadores y verificadores para compilar y probar cambios en paralelo a través de espacios de trabajo aislados». La guía de la API de Gemini lo expresa con mayor claridad: haz que Carbon planifique interfaces o resuelva bloqueos complejos y luego delega en Hydrogen las ediciones de código, las tareas paralelas de subagentes y la ejecución de pruebas.
Se trata de un patrón de orquestación, no de una función propia del modelo, y puedes implementarlo en tu propio tablero hoy mismo. Si prefieres que el tablero centralice este patrón en lugar de depender de un script en un portátil local, Sharkly es el lugar donde residen las Tasks, los Agents y las revisiones.
Qué hace Orchestrator de Google, en un solo párrafo
Orchestrator es una opción de modelo dentro de Google Antigravity que alterna entre un planificador (Carbon o Argon) e Hydrogen dentro de una misma conversación. Según la documentación de Antigravity, el planificador comienza con una fase de solo lectura, redacta un plan con activadores explícitos de replanificación y transfiere la ejecución a Hydrogen. Hydrogen devuelve el control cuando encuentra fricción.
La documentación menciona tres señales de fricción que merece la pena adoptar:
- Un paso de verificación que falla dos veces.
- Una interfaz cuyo comportamiento difiere de lo previsto en el plan.
- Una decisión de diseño que el plan no llegó a definir.
Google informa que en Terminal-Bench, Orchestrator alcanzó una tasa de éxito casi idéntica a la de Carbon consumiendo un 24% menos de cuota y completando las tareas un 19% más rápido en promedio. Las dos publicaciones de Google discrepan sobre la versión del benchmark (el artículo de lanzamiento menciona la 4.0 y el de Antigravity la 4.1), por lo que conviene citarlo simplemente como Terminal-Bench hasta que Google lo aclare.
Orchestrator mantiene un único agente en tu conversación, ejecuta una configuración fija sin control sobre el nivel de razonamiento (thinking level) y, en su versión con Carbon, solo está disponible para Google AI Ultra. Un tablero de equipo reparte esta misma división entre varios Agents, manteniendo el plan y las transferencias de tareas a la vista de todos.
La cuestión del coste: comparativa de precios entre Gemini 4 Hydrogen y Carbon
Precios por token tomados de la página de precios de la API de Gemini con fecha del 13 de noviembre de 2026:
| Modelo | ID de modelo de API | Entrada / 1M | Salida / 1M | Capa gratuita |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
2,00 $ hasta el 30 de nov., luego 4,00 $ | 10,00 $ hasta el 30 de nov., luego 20,00 $ | No |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
1,50 $ | 7,50 $ | Sí, con límite de frecuencia |
Ten en cuenta las fechas antes de elaborar un presupuesto con estos datos. Hasta el 30 de noviembre, Hydrogen es solo un 25% más económico por token que Carbon. A partir del 1 de diciembre, la diferencia es del 62,5%. Ambas cifras proceden de nuestros propios cálculos sobre los precios de lista de Google.
Veamos qué supone esto en una sola ejecución, recurriendo también a nuestros cálculos. Tomemos un turno de trabajo que lea 200 000 tokens y genere 40 000 (el output incluye los tokens de razonamiento). En Carbon, a partir del 1 de diciembre, esto costaría 0,80 $ + 0,80 $ = 1,60 $. En Hydrogen, supondría 0,30 $ + 0,30 $ = 0,60 $. Multiplica esto por 30 veces al día a lo largo de un Sprint y la diferencia dejará de ser una simple anécdota.
El precio por token por sí solo subestima la diferencia real. Google señala que Carbon «dedica más tokens de razonamiento por turno para contrastar hipótesis y verificar casos límite», y la tarifa de salida incluye el razonamiento. Por tanto, es probable que la misma edición en Carbon facture más tokens de salida, además de tener una tarifa unitaria más alta. Google no publica cifras de coste por tarea para ambos modelos, de modo que conviene medirlo en tu propio repositorio antes de dar por sentado un determinado ahorro.
La velocidad es la otra cara de la moneda: Google indica que Hydrogen completa tareas 2,5 veces más rápido que Gemini 3.8 Flash en su nivel predeterminado high.
Distribuye el trabajo en tu equipo de agentes: roles asignados a modelos
La división entre planificador y ejecutor es una organización del trabajo por escrito: un Agent asume el plan y las decisiones difíciles, Agents más económicos se encargan de la ejecución y un verificador revisa el resultado antes de que llegue a manos humanas. Cada rol cuenta con el modelo cuyo coste y profundidad encajan mejor con la tarea.
| Rol | Modelo | Nivel de razonamiento | Responsabilidades |
|---|---|---|---|
| Planificador | gemini-4-carbon |
predeterminado medium, high para Tasks complejas |
Lectura del código base, redacción de subtareas con pruebas de aceptación, replanificación |
| Ejecutor (1 a n) | gemini-4-hydrogen |
high (predeterminado) |
Ediciones, actualización de paquetes, pruebas; una subtarea cada uno |
| Verificador | gemini-4-hydrogen |
high, xhigh para diffs de riesgo |
Ejecución de validaciones según los criterios de aceptación del planificador |
| Persona | n/a | n/a | Aprobación del plan en Tasks grandes, aceptación del resultado |
Dos detalles de la documentación de Google fundamentan esta tabla: Carbon y Argon vienen predeterminados en medium con un tope en high, mientras que Hydrogen viene por defecto en high e incorpora xhigh. Además, Google advierte que xhigh incrementa la latencia y el consumo de tokens, y «puede provocar un exceso de razonamiento en prompts sencillos». Reserva xhigh para el verificador en diffs que involucren autenticación, pagos o migraciones de datos.
¿Qué debe redactar el planificador?
El resultado del planificador constituye el contrato para todos los pasos posteriores. Un buen plan incluye una subtarea por cada cambio independiente, el alcance de archivos de cada una, el comando que valida su funcionamiento y la condición para devolverla al planificador. Si un ejecutor no tiene claro cuándo ha terminado, significa que el plan aún no está listo.
¿Cuándo se devuelve el trabajo al planificador?
Replica la lista de activadores de Google y hazla explícita. Un ejecutor devuelve una subtarea cuando su validación falla dos veces, cuando una interfaz no coincide con el plan o cuando requiere una decisión de diseño. La devuelve acompañada del registro, el diff acumulado hasta el momento y la duda concreta. Nunca debe reintentar en silencio con un modelo superior, ya que eso ocultaría el coste de la capa económica dentro de la factura del modelo más caro.
Configuración en Sharkly
En Sharkly, un Agent es un compañero de equipo de IA que opera mediante un Runtime en un Computer conectado, y un Crew es un grupo de Agents y personas coordinados por un Agent líder. Esto encaja de forma directa con el esquema planificador/ejecutor sin necesidad de código de integración adicional. El planificador asume el rol de líder del Crew, mientras que los ejecutores y el verificador son los miembros del equipo.
Cada Agent cuenta con su propio Runtime y modelo predeterminado (Default model), como se aprecia en el panel anterior (donde se ejecuta Claude Code). Para esta configuración, asigna a cada Agent un Runtime con acceso a la API de Gemini, como Gemini CLI, y define el modelo individualmente: Carbon para el planificador e Hydrogen para el resto. Si la lista de modelos aún no muestra los nuevos identificadores, define el modelo directamente en la configuración del propio Runtime. Gemini CLI también admite una variable de entorno GEMINI_MODEL, tal como indica su referencia de configuración, y los Agents admiten variables de entorno a nivel individual.
Luego, redacta las reglas de coordinación dentro de las instrucciones del Crew:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Asigna la Task al Crew. La ejecución prioriza al líder, conforme a la documentación de Crews: el líder analiza la Task y las instrucciones del Crew, menciona a los miembros para contribuciones específicas y los resultados se registran en la misma Task. Emplea directorios de trabajo temporales para que cada ejecutor cuente con su propio árbol de trabajo (worktree). Activa el directorio de Task compartido del Crew únicamente cuando las subtareas deban encadenarse secuencialmente sobre los cambios locales de las anteriores.
El trabajo bloqueado no pasa desapercibido: las ejecuciones fallidas o bloqueadas van directas a la bandeja de entrada (Inbox), y cualquier Agent a la espera de intervención humana se destaca en los Task Chats de la barra lateral. Hacia allí apunta la flecha discontinua cuando el planificador no logra corregir el plan por sí mismo.
Técnicas avanzadas
Aprovecha el cambio de modelo de la API en Tasks extensas. La documentación de Google explica que es posible enrutar turnos de planificación hacia gemini-4-carbon y turnos de ejecución hacia gemini-4-hydrogen en una única sesión multiturno usando previous_interaction_id, sin alterar los esquemas. Esto traslada la técnica de Orchestrator a tu propio código, algo muy útil dentro de la ejecución de un solo Agent.
Presta atención al límite de tokens por llamada (hop sizes). Hydrogen genera hasta 65 536 tokens por salto sin streaming, mientras que Carbon y Argon entregan hasta 32 768 por salto REST sin streaming. Conviene dejar las generaciones extensas, como suites de pruebas y especificaciones de migración, del lado del ejecutor.
Prescinde del almacenamiento en caché explícito en Hydrogen. Hydrogen no admite el almacenamiento en caché de contexto explícito. La caché implícita se activa con prompts de al menos 4096 tokens y descuenta un 95% del coste de entrada almacenado en caché; por ello, coloca el contexto compartido del repositorio al principio de cada prompt del ejecutor.
Alternativas al esquema planificador/ejecutor
- Hydrogen en solitario. La documentación de Google lo recomienda para actualizaciones de paquetes, deduplicación, scaffolding, pruebas unitarias de funciones bien delimitadas y documentación. No requiere planificador.
- Carbon en solitario. Ideal para diseño de sistemas distribuidos, condiciones de carrera o migraciones multirrepositorio, donde cada paso exige máxima profundidad.
- Orchestrator en Antigravity. Una sola persona, una conversación y transferencias automatizadas, disponible en los planes que lo incorporan.
- Un enrutador estático. Consiste en clasificar la Task de antemano y enviarla a un solo modelo. Google sostiene que este enfoque falla en ejecuciones largas, donde la complejidad varía a mitad de la Task. Abordamos esta variante preliminar en nuestro artículo sobre cómo enrutar Tasks de agentes con la API Gemini Decisions.
Casos de uso reales
Clasificación masiva de incidencias. La propia demo del SDK de Antigravity de Google asocia agentes Hydrogen para triaje y programación con un agente Carbon para refactorizaciones, desarrollo de nuevas funciones y revisiones de seguridad. En un tablero, esto se traduce en un Agent Hydrogen gestionando la cola de entrada y un líder Carbon supervisando todo lo etiquetado como refactorización o seguridad.
División de una funcionalidad en subtareas paralelas. El planificador descompone un cambio de API en actualizaciones de esquema, controladores (handlers) y cliente; tres ejecutores las llevan a cabo en ramas de trabajo (worktrees) independientes; y el verificador ejecuta las pruebas de contrato.
Conclusión
Carbon planifica, Hydrogen construye y una persona da el visto bueno. La estructura de precios hace que esta división merezca la pena a partir del 1 de diciembre, los activadores de fricción evitan que los errores económicos se conviertan en costosos reintentos y el tablero registra cada transferencia dentro de la Task a la vista de todo el equipo. Para profundizar en este patrón general, consulta qué es la orquestación de agentes de IA y nuestra regla de enrutamiento de modelos para Crews.
El siguiente paso: conecta un Computer a Sharkly, crea un Agent planificador en Carbon y un ejecutor en Hydrogen, agrúpalos en un Crew con las instrucciones anteriores y asígnales una Task que habitualmente confiarías a una persona durante toda una tarde. Sharkly dispone de un plan gratuito (Free), por lo que el único coste de la prueba serán los tokens de Gemini.
Preguntas frecuentes
¿Cuál es la diferencia entre Gemini 4 Carbon y Hydrogen?
Carbon es el modelo de frontera más avanzado de Google, diseñado para razonamiento de largo alcance y tareas complejas de arquitectura, depuración y seguridad. Hydrogen es el modelo ágil y eficiente de Gemini 4 para programación cotidiana y ejecución de agentes. Carbon utiliza por defecto un nivel de razonamiento medium con límite en high; Hydrogen utiliza high por defecto y añade la opción xhigh.
¿Es Gemini 4 Hydrogen más económico que Carbon?
Sí. Hydrogen cuesta 1,50 $ por cada millón de tokens de entrada y 7,50 $ por cada millón de salida. Carbon cuesta 2 $ y 10 $ hasta el 30 de noviembre de 2026, y pasará a costar 4 $ y 20 $ a partir del 1 de diciembre. Además, Hydrogen cuenta con un nivel gratuito sujeto a límites de frecuencia en la API de Gemini; Carbon no.
¿Debería el verificador ejecutarse en Carbon en lugar de Hydrogen?
No por defecto. Google orienta Hydrogen al funcionamiento en paralelo de agentes ejecutores y verificadores. Utiliza xhigh en el verificador para diffs críticos o de alto riesgo, y escala la Task al planificador Carbon únicamente cuando una comprobación falle dos veces.
¿Sharkly selecciona el modelo para cada Task?
No. El modelo se define para cada Agent a través de su Runtime, y las instrucciones del Crew determinan qué Agent asume cada parte de la Task. Sharkly gestiona la Task, las ejecuciones, las transferencias de trabajo y la revisión.
