Google lanza Gemini 4 Carbon: una ventana de 1 millón de tokens para depuración compleja

Cuando un error atraviesa tres servicios, corregir un archivo a menudo solo oculta la causa. Google ha lanzado Gemini 4 Carbon para este tipo de tareas: el modelo está diseñado para sesiones prolongadas de depuración con comprobación de hipótesis. A los desarrolladores les puede resultar útil probarlo con un problema en el que su asistente habitual ya da vueltas en círculo y comparar el coste de una corrección aceptada.

La afirmación de que está «disponible para todos» necesita una precisión. En la aplicación Gemini, el AI Mode del buscador y Antigravity, el acceso está disponible para los suscriptores de Google AI Ultra. Los desarrolladores pueden utilizar una API de pago. Las condiciones figuran en el anuncio de Google.

Cómo se trabaja con un error complejo

Imaginemos una tienda en línea: un comprador vuelve a intentar un pago tras agotarse el tiempo de espera y se le cobra el pedido dos veces. Es un ejemplo hipotético. La causa podría estar en la interacción entre el gestor de pagos, la cola de eventos y la lógica de reintentos. Un resultado útil sería una prueba que reproduzca el error, una explicación de la secuencia de eventos y una corrección que soporte la entrega repetida de un mensaje.

Carbon está diseñado precisamente para estas investigaciones de varios pasos. En la ficha del modelo, Google explica que utiliza más tokens de razonamiento que Argon para explorar hipótesis y ejecutar comprobaciones adicionales. El nivel de razonamiento es configurable; la latencia y el coste cambian en consecuencia.

Antes de probarlo en un proyecto propio, conviene definir los criterios de éxito. Por ejemplo: un reintento no genera un segundo pago, la cola admite entregas repetidas y los flujos de reembolso existentes siguen funcionando. Así se puede verificar el resultado con independencia de lo convincente que parezca la respuesta del modelo. Una explicación impecable que no reproduzca el error deja sin resolver el problema de ingeniería original.

Antigravity también ha incorporado una versión preliminar de /swarm: una sola petición pone en marcha un equipo coordinado de agentes. Según Google, se puede asignar a Carbon la arquitectura, la coordinación o la auditoría, y dejar las tareas paralelas a modelos más ligeros. En el ejemplo del pago, sería razonable separar la reproducción del error, la preparación del parche y la comprobación de efectos secundarios. Es una propuesta de flujo de trabajo; su eficacia tendrá que medirse con tu código.

Un millón de tokens exige hacer cuentas

La ficha de Carbon especifica una ventana conjunta de entrada y salida de hasta un millón de tokens. Por tanto, sería incorrecto prometer «un millón de entrada y otro millón para la respuesta». Al cargar un repositorio grande, hay que dejar espacio para el resultado. El tamaño de la ventana tampoco demuestra por sí solo que el modelo vaya a encontrar la dependencia relevante entre todos los archivos.

En la práctica, yo empezaría con un conjunto mínimo: módulos relacionados, registros, un esquema del intercambio de eventos y una prueba que reproduzca el error. Conviene añadir contexto cuando la investigación revele una carencia concreta. Así resulta más fácil entender qué información ayudó y comparar varias ejecuciones.

Hasta el 30 de noviembre, el precio anunciado es de $2 por millón de tokens de entrada y $10 por millón de tokens de salida. A partir del 1 de diciembre, será de $4 y $20, respectivamente. Google recoge estas tarifas en su anuncio. La duración del trabajo también influye en el presupuesto: los ciclos adicionales de comprobación pueden elevar el gasto incluso con un precio por token atractivo.

Qué comprobar antes de adoptarlo

Google afirma que Carbon lidera CursorBench 4.0, WANDR y AutomationBench, con un coste por tarea inferior al del siguiente mejor modelo externo. Es un buen motivo para realizar una prueba propia. Sería prematuro trasladar el resultado de una tabla de evaluación a un repositorio concreto sin medirlo.

La ficha del modelo menciona expresamente las alucinaciones, la posible lentitud y los tiempos de espera agotados. La elección de métricas del equipo resulta especialmente reveladora: cuántas correcciones superan una verificación independiente, cuánto dura la investigación y cuánto cuesta la ejecución completa, incluidos los reintentos.

Para una primera prueba, toma varios errores complejos ya resueltos y oculta los parches definitivos. Compara Carbon con tu herramienta actual en las mismas condiciones. Los desarrolladores obtendrán una respuesta verificable sobre la calidad de la depuración; los responsables de producto, datos sobre la latencia; y los fundadores, el coste de un resultado útil. Esos tres indicadores deberían determinar qué tareas justifican un razonamiento más caro.