Google presentó el 30 de septiembre de 2026 Gemini 4 Argon, un nuevo modelo para tareas profesionales prolongadas, desarrollo de software y ciberdefensa. El acceso inicial se concede a un grupo seleccionado de socios del programa Fairwind. Pese al alcance del anuncio, todavía no está abierto a todos los usuarios de Gemini, y una suscripción existente tampoco garantiza el acceso al modelo.
La compañía señala un límite de salida de un millón de tokens, frente a los 64 mil anteriores. Son los tokens que el modelo puede generar mientras trabaja, no solo la cantidad de material que puede recibir. La diferencia importa: leer un documento extenso y seguir generando contenido a lo largo de una tarea son capacidades distintas, con implicaciones diferentes para el tiempo de trabajo y la factura.
La tabla de resultados muestra ventajas, pero también desventajas
La página del modelo de Google DeepMind presenta resultados en varias pruebas. En DeepSWE v1.1, centrada en tareas de desarrollo de software, Argon obtuvo un 77.9%, frente al 74.1% de GPT-6 Astra y el 74.2% de Claude Opus 5.5. Es una comparación publicada por Google, no una prueba independiente de AI24 ni una promesa de que la diferencia se repetirá en todos los repositorios de código.
La misma tabla ofrece otro panorama en FrontierSWE v2: Argon obtuvo un 55.0%, frente al 65.5% de GPT-6 Astra y el 62.3% de Claude Opus 5.5. También en Terminal-bench 4.0, el resultado de Argon, un 57.4%, queda por debajo del 66.4% de Claude Opus 5.5. Llamar a un modelo buque insignia no convierte cada fila de la tabla en una victoria.
CWE-bench v1 recoge un resultado del 68.0% tanto para Argon como para GPT-6 Astra, mientras que Google comunica un 51.3% de Argon en AutomationBench. Estas pruebas evalúan distintos tipos de trabajo, por lo que no procede combinar sus porcentajes en un promedio improvisado ni traducirlos directamente a la proporción de tareas que una oficina concreta podría delegar en la IA.
Una comparación útil empieza por preguntar qué se evaluó exactamente. Corregir un error en un repositorio conocido, utilizar herramientas en un entorno definido y analizar un documento empresarial no son tareas idénticas. Un equipo que evalúa un modelo debe identificar qué prueba se parece a su trabajo y comprobar después si las condiciones de ejecución encajan con su sistema.
También conviene separar un resultado aislado impresionante de la fiabilidad a lo largo de una secuencia de acciones. Si una tarea exige leer material, editar archivos y ejecutar pruebas, acertar en la primera fase no la completa. La medida empresarial es el resultado utilizable y el tiempo necesario para obtenerlo, incluida la revisión humana.
Un pequeño experimento comparativo puede incluir una tarea que el sistema actual resuelve bien, otra en la que encuentra dificultades y un caso en el que falta información esencial. Así se evalúa tanto la capacidad de avanzar como la de reconocer que no hay base para una respuesta. Los ejemplos deben mantenerse fijos para que una diferencia en el resultado no proceda de haber cambiado la pregunta.
También es importante comparar los permisos concedidos en cada ejecución. Un modelo con acceso a información adicional o a herramientas distintas no se evalúa en las mismas condiciones. Esta distinción no invalida los indicadores públicos; define qué hay que saber antes de trasladar sus conclusiones a un sistema local.
Por qué el acceso comienza por quienes trabajan en ciberdefensa
El programa Fairwind de Google DeepMind busca dar a organizaciones seleccionadas acceso temprano a capacidades de defensa. Su página incluye entre los destinatarios a gobiernos, proveedores sanitarios e infraestructuras de telecomunicaciones. La lógica declarada es permitir que los defensores encuentren y corrijan vulnerabilidades antes de que se utilicen capacidades equivalentes contra ellos.
Según el programa, algunos socios reciben acceso a Argon y pueden utilizarlo dentro de CodeMender, un agente específico para encontrar vulnerabilidades y corregir código. La participación incluye comprobaciones de idoneidad y normas de uso. Las tareas de doble uso, como analizar software malicioso o simular ataques autorizados, se permiten dentro de fines definidos de defensa e investigación.
Aquí hay una diferencia entre la potencia del modelo y el derecho del usuario a utilizarlo. Poder analizar un sistema no otorga permiso para poner a prueba el de un tercero. Incluso dentro de un programa formal hay que definir qué activos están incluidos, quién autoriza las acciones y cómo se gestionan los hallazgos sensibles.
Para una organización israelí dedicada a proteger software, puede ser una vía relevante para consultar si cumple los requisitos. La publicación no confirma que se acepte a todas las empresas israelíes, no garantiza una fecha de admisión ni promete servicio local. Que el acceso no aparezca en una cuenta de consumo habitual no indica por sí solo una avería.
En la práctica, también conviene distinguir entre una corrección propuesta y una ya implantada. Una prueba de seguridad puede producir código que parezca convincente pero modifique el comportamiento existente. La evaluación debe incluir la reproducción del problema, la comprobación del cambio y la demostración de que las operaciones normales del sistema siguen funcionando.
Un millón de tokens no es una instrucción para producir un millón de tokens
Una salida extensa puede ser útil cuando hay que mantener una secuencia de trabajo compleja. También puede dificultar la supervisión si el usuario recibe un resultado enorme que nadie sabe cómo comprobar. La pregunta principal no es, por tanto, cuánto puede escribir el modelo, sino en qué puntos se puede verificar que el trabajo avanza correctamente.
Un ejemplo posible es migrar un componente de software a otro lenguaje. El trabajo puede dividirse en identificar su comportamiento, introducir un cambio pequeño y comprobar la compatibilidad. Así se puede comparar el resultado en cada etapa. Una única ejecución prolongada puede resultar cómoda, pero no sustituye a definir qué debe permanecer intacto.
También al trabajar con documentos conviene pedir un resultado concreto: qué datos se solicitaron, de qué fuente proceden y qué sigue sin saberse. Una respuesta más larga no es necesariamente más completa. A veces, un resumen breve que distingue con claridad entre hechos y lagunas permite tomar una decisión mejor.
El precio introductorio y la disponibilidad requieren comprobaciones separadas
Google anunció un precio introductorio de 2 dólares por millón de tokens de entrada y 10 dólares por millón de tokens de salida. Tras ese periodo, las tarifas declaradas son de 4 y 20 dólares, respectivamente. El anuncio no especifica cuándo termina el periodo introductorio, por lo que un presupuesto a largo plazo no debería basarse solo en la tarifa reducida.
Son tarifas de uso del modelo, no el precio de una suscripción mensual ni un compromiso sobre el coste de una tarea completa. Para comparar costes hay que medir cuánta entrada y salida consume el mismo trabajo, cuántas veces se repite y cuántas correcciones necesita. Comparar únicamente el precio por millón de tokens deja fuera parte de la factura.
El anuncio no publicó resultados específicos para el hebreo. Cuando se abra un acceso adecuado, una prueba local debería incluir documentos en hebreo, nombres y términos que el equipo utilice realmente y resultados verificables. Por ahora, el anuncio aporta un modelo nuevo y un programa de distribución limitado. Decidir si se le confía trabajo real exigirá tanto acceso efectivo como pruebas obtenidas con las tareas de la propia organización.