La Pelican Demo de Gemini 4 Carbon, desglosada: dos agentes, un pipeline de Blender y un bucle de revisión que realmente cierra

Lo más útil que Google lanzó el 10 de noviembre de 2026 no fue una tabla de benchmarks. Fue un pájaro en bicicleta. En la misma publicación en la que puso Gemini 4 Carbon a disponibilidad general, Google describió una ejecución en la que agentes de Carbon construyeron un juego 3D de mundo abierto —exploras el campus de Mountain View de Google como un pelícano que monta una GBike— modelando recursos en Blender y luego construyendo el juego de navegador en Three.js con shaders WebGL, con efectos procedurales de Web Audio contrapuestos a música de Lyria. El clip que circuló con él dura unos 77 segundos. La parte que merece tu atención no es el pelícano. Es que el bucle se cerró: algo en ese pipeline observó lo que había renderizado y decidió si era suficientemente bueno.

Eso es una afirmación distinta de «el modelo es inteligente». Las demos se eligen, y esta la eligió el proveedor. Pero una demo con un revisor dentro es comprobable de un modo en que una puntuación de benchmark no lo es: puedes leer la estructura, contar los roles y preguntarte si esa misma forma sobreviviría en tu propio trabajo. Así que esto es un desmontaje y no una pieza de lanzamiento: qué se construyó, cómo se repartieron los agentes, qué demuestra y qué no demuestra la ejecución, y cuánto cuesta apuntar ese mismo patrón a algo que de verdad te importe.

Lo que realmente se construyó, en el orden en que se construyó

La descripción de Google es inusualmente específica sobre la cadena de herramientas, y eso es lo que hace que valga la pena leerla como una nota de ingeniería. La ejecución constaba de tres tramos de medios, y no son intercambiables:

• Recursos — los subagentes modelaron objetos 3D en Blender, trabajando a partir de referencias generadas por Omni y Nano Banana. Ese es un paso de modelado, no un paso de código: de ahí salen la geometría, los materiales y la escala, y todo lo que viene después hereda cualquier error que tengan.

• El juego — creado en Three.js con shaders de WebGL, así que el entregable es una escena que se puede renderizar en el navegador en lugar de un vídeo renderizado. Que un shader compile es una señal sólida y verificable por máquina, de un modo en que «se ve bien» no lo es.

• Sonido — efectos procedurales de Web Audio combinados con música de Lyria. Esta es la pata menos conectada al bucle de revisión y la que más probabilidades tiene de ser ajustada a mano por una persona a posteriori.

La misma publicación pone a su lado otras cuatro construcciones 3D, y el patrón se repite: una exposición interactiva en Three.js de la construcción de la Torre Eiffel entre 1887 y 1889 a partir de fotografías históricas y láminas de ingeniería; una reconstrucción en Three.js de 906.000 triángulos de la oficina Platform 37 de Google, creada a lo largo de diez iteraciones nocturnas a partir de siete PDFs de planificación del Ayuntamiento; un visualizador textil con seguimiento polar de 110 fibras; y un fortepiano tocable con física de escape de 61 teclas. Sea lo que sea cierto, esto no es un prompt afortunado. Es un conjunto de ejecuciones con la misma forma.

¿Dos agentes, o un agente con tres trabajos?

Los relatos de los observadores y el propio artículo de Google describen la misma ejecución desde ángulos distintos, y la diferencia es instructiva. El resumen en chino más compartido, de @dotey el 10 de noviembre, lo divide en un agente constructor y un agente revisor que comprueba sus propias renderizaciones. El autor original, Vamsi Batchu de Google AI Studio, presenta lo mismo como un pelícano que recoge chips TPU por el campus — y atribuye a la función /swarm de Google Antigravity, que Google describe como convertir un solo prompt en "un equipo coordinado de agentes que puedes seguir en tiempo real".

La publicación de Google asigna a Carbon los roles en lugar de a los medios: «diseño arquitectónico, coordinación y auditoría». Leída junto con la descripción del observador, la forma es la de un constructor que produce geometría y código, y un auditor que examina el resultado en lugar del código fuente. Esa distinción importa más que el número de agentes. Un agente que revisa su propio diff tiene una señal débil; un agente que revisa un fotograma renderizado, un shader que compila o una captura de pantalla del juego en ejecución tiene una señal fuerte, porque el fallo es visible en el artefacto en lugar de discutible en la prosa.

Dos advertencias honestas sobre las fuentes. La división entre constructor y revisor proviene de personas que describen la ejecución, no de un diagrama de arquitectura publicado; trátala como un resumen fiel y no como una especificación. Y /swarm está en versión preliminar en Antigravity, así que la capa de orquestación que estarías reproduciendo no está disponible de forma general.

También hay un detalle práctico que nadie menciona: la app vinculada de AI Studio está detrás de un inicio de sesión de Google. No pude abrir el juego de forma anónima; la URL redirige directamente a accounts.google.com. Así que «jugable en tu navegador» significa «jugable si tienes una cuenta de Google y, para la propia app, una sesión de AI Studio». Es un detalle pequeño que cien reposts del vídeo se saltaron en silencio.

Por qué un juego es una prueba más difícil que el SVG al que reemplazó

El prompt del pelícano en bicicleta es de Simon Willison, que lo ha probado con prácticamente todos los lanzamientos de frontera desde 2024: primero como una única petición de SVG y, después, cuando los modelos dejaron de diferenciarse con SVG planos, como prompts en 3D: una página WebGL, renders de Blender, bocetos de p5.js. El valor de la prueba nunca estuvo en que un pelícano sea difícil, sino en que la salida es visual, autocontenida y cualquier persona puede juzgarla al instante en menos de un segundo.

Lo que hace la ejecución de Carbon es llevar esa misma propiedad a un nivel superior de dificultad. Un SVG es un único artefacto en un solo lenguaje. Esto es geometría de una herramienta, código en otra, un runtime en una tercera, y un paso de revisión que tiene que conciliar los tres —que es exactamente la clase de tarea en la que el trabajo de agentes de horizonte largo suele venirse abajo, no en el primer paso sino en el decimocuarto, cuando el modelo ya ha olvidado a qué sistema de coordenadas se comprometió.

El resumen que hace Google de la capacidad es preciso, y nombra el mecanismo: para el desarrollo de aplicaciones web, el modelo «ejecuta bucles de compilación y verificación, se recupera de los errores y comprueba tanto su código como la interfaz de usuario renderizada». Ese es todo el truco, dicho sin rodeos. La variable interesante no es lo buena que sea la primera tentativa. Es cuántas veces puede girar el bucle antes de que el agente deje de mejorar y empiece a dar bandazos.

Lo que la demo no te dice

Una demo de proveedor es una muestra seleccionada, y la selección es el quid del ejercicio. Tres cosas que no puede responder:

• Con qué frecuencia falla. Vemos la ejecución que terminó. Nadie publica las once que se atascaron, y no hay ningún denominador en ninguna parte de la publicación.

• Cuánto costó. Diez ciclos nocturnos en la compilación de Platform 37 implican muchos tokens y mucho tiempo de reloj. Con las tarifas de Carbon, eso es una cifra real, y Google no la proporciona.

• Si un modelo más barato habría bastado. Esta es la pregunta que un lector debería plantearse en realidad, y la demo es estructuralmente incapaz de responderla.

Para las partes que se pueden medir, Artificial Analysis es el contrapeso, y sus cifras son menos halagüeñas que las del vídeo. Gemini 4 Carbon con alto esfuerzo obtiene 60 en Intelligence Index v5.0.1 —cuarto de 74 modelos, por detrás de tres configuraciones de Claude Fable 5.2 con 65, 62 y 62—. Su coste por tarea del índice es de 7,76 $, ocupa el puesto 61 de 73 en esa medida y consume 205 millones de tokens de salida en todo el índice frente a una mediana cercana a los 73 millones: es un modelo verboso, y el precio por token subestima lo que cuesta una carga de trabajo de Carbon. La velocidad de salida es de unos 82 tokens por segundo, con aproximadamente 67,5 segundos hasta el primer token de respuesta: lo bastante rápido por token, pero lo bastante lento hasta el primero como para que se lea como un perfil de lotes y espera en lugar de uno de caja de chat. En el Coding Agent Index, el mismo evaluador situó a Carbon en 59 con Antigravity CLI, frente a 62 de Claude Code con Opus 5.5.

Nada de eso contradice la demo. Un modelo puede ocupar el cuarto puesto en un índice general, ser caro por tarea y aun así ser el que mantiene en pie una compilación de cuatro horas: son mediciones distintas, y la demo es evidencia de la tercera, no de la primera. Lo que no es, es una prueba, y la pieza faltante más barata es la que esta línea genealógica suele aportar. Willison ejecuta el prompt del pelícano en casi cada lanzamiento y publica los resultados; en noviembre de 2026, sus entradas sobre el pelícano abarcan Claude Fable 5.2 en cinco niveles de razonamiento y Muse Ember en seis, y no hay ningún conjunto de Carbon entre ellas. Hasta que aparezca uno, la demo del pelícano es un artefacto de Google y de nadie más: una compilación seleccionada por el proveedor con una descripción escrita por el proveedor, y ninguna ejecución externa con la que comparar la tasa de fallos.

Cuánto cuesta ejecutar el mismo bucle por tu cuenta

Carbon solo está disponible en el nivel de pago de Google. No hay una vía gratuita: la app de AI Studio necesita una cuenta de Google, la API necesita facturación y se cobra por cada token procesado, incluidos los tokens de pensamiento. La tarifa es introductoria y de duración limitada:

• Hasta el 30 de noviembre de 2026 — 2,00 $ por millón de tokens de entrada, 10,00 $ por millón de tokens de salida.

• A partir del 1 de diciembre de 2026 — $4.00 y $20.00, con un modelo que no ha cambiado.

• Contexto — 1M de tokens, sin tarifa por tramos según la longitud, por lo que un código base de 900.000 tokens cuesta lo mismo por token que un prompt de 2.000 tokens.

Pon la verbosidad junto al precipicio y la aritmética se vuelve incómoda. Un bucle de construcción y revisión es intensivo en salida por diseño: el revisor escribe, el constructor reescribe y la transcripción crece en cada turno. Una carga de trabajo de 100 millones de tokens de entrada y 20 millones de tokens de salida factura 400 $ este mes —200 $ de entrada y 200 $ de salida— y 800 $ a partir del 1 de diciembre por el mismo tráfico. Si estás haciendo un piloto en noviembre, calcula su precio con las tarifas de diciembre o aprobarás un presupuesto equivocado por un factor de dos.

Vale la pena aclarar dónde nos situamos: Gemini 4 Carbon no está en el catálogo de OrcaRouter, y nada de lo que aquí se dice debe interpretarse como una afirmación de que sí lo está. Lo que sí hay es google/gemini-4-argon al propio precio de Google de $2 de entrada / $10 de salida —la misma tarifa que tiene Carbon este mes— junto con DeepSeek V4 Pro a $0.66/$1.98 y Grok 4.7 a $2/$6, todo con una única clave compatible con OpenAI para 216 modelos, con el precio de lista del proveedor trasladado sin margen (0 %) de modo que un cambio de tarifa del proveedor se aplica el mismo día en que ocurre, en lugar de después de un ciclo de revisión de precios. Para este patrón en concreto, eso importa por un motivo aburrido: un bucle de compilación multiagente es la carga de trabajo con más probabilidades de toparse con un límite de velocidad o con una mala tarde en un proveedor, y la conmutación por error a una segunda ruta sale más barata que descubrir el techo a mitad de una ejecución de diez bucles.

Si quieres copiar la estructura, copia el paso de revisión.

La parte transferible de esta demo no es Blender, ni es Three.js. Es que al revisor se le dio algo que pudiera mirar. Tres movimientos, en orden de cuánto cambian el resultado:

• Haz que el artefacto sea la entrada de la revisión. Haz una captura de la app en ejecución, renderiza el frame, compila el shader, ejecuta el test y luego devuelve eso de vuelta, no el diff. Un agente al que se le pregunta «¿este código es correcto?» estará de acuerdo consigo mismo. Un agente al que se le pregunta «¿esta captura coincide con el encargo?» tiene algo sobre lo que equivocarse.

• Limita el bucle y comprueba la convergencia. Diez bucles nocturnos es la cifra que Google cita para una compilación. Elige tu propio límite superior y registra si cada turno mejoró realmente el artefacto: un agente que ha dejado de mejorar suele ser un agente que ha empezado a redecorar.

• Mantén la cadena de herramientas aburrida y verificable. Las exportaciones de Blender, Three.js, WebGL y un navegador son deterministas e inspeccionables. Nada en esta ejecución depende de una capacidad que solo tenga un proveedor; depende de un modelo que seguirá adelante tras el primer fallo.

Lo que hay que vigilar a continuación es acotado y específico. Si /swarm sale de la vista previa, porque la orquestación es la parte que hoy no se puede reproducir. Si alguien fuera de Google publica un Carbon pelican —la versión de Willison es lo más parecido a un resultado independiente que tiene este linaje, y no ha aparecido. Y si el intervalo de doce días entre el anuncio con acceso restringido del 28 de octubre y el lanzamiento general del 10 de noviembre resulta ser el patrón o la excepción. La demo se citará durante meses. El bucle que hay detrás es lo que o bien se generaliza, o bien no.