Gemini 4 Argon: los benchmarks de código no coinciden
Argon lidera DeepSWE, pero queda por detrás en otros tests de código. Comparo los benchmarks, el millón de tokens de salida y el acceso limitado.

En esta página
Google anunció Gemini 4 Argon el 30 de septiembre de 2026, y sus resultados de programación me dan motivos para probarlo antes de cambiar de modelo. Argon lidera la comparación de Google en DeepSWE, pero queda por detrás de Astra y Opus en otros tests. Además, el límite de salida sube a un millón de tokens y el acceso empieza por un programa restringido de ciberdefensa. [1] [2]
¿Qué muestran los benchmarks de código de Gemini 4 Argon?
Argon gana en DeepSWE, pero la propia tabla de lanzamiento de Google muestra que el líder cambia según la tarea. Lo incluiría entre los candidatos para trabajar con repositorios sin dar por hecho que sustituye a Astra u Opus. Estas tres filas explican el motivo. [2]
Comparación de lanzamiento de Google DeepMind, consultada el 1 de octubre de 2026. Los porcentajes proceden de benchmarks y configuraciones diferentes; compara dentro de cada fila, no entre filas. [2, 3]
| Benchmark de código | Gemini 4 Argon | GPT-6 Astra | Claude Opus 5.5 |
|---|---|---|---|
| DeepSWE v1.1 | 77,9 % | 74,1 % | 74,2 % |
| FrontierSWE v2 | 55,0 % | 65,5 % | 62,3 % |
| Terminal-bench 4.0 | 57,4 % | 58,2 % | 66,4 % |
En DeepSWE v1.1, Argon consigue el 77,9 %, frente al 74,1 % de Astra y el 74,2 % de Opus 5.5. Es un resultado útil para el desarrollo de software. Sin embargo, FrontierSWE v2 sitúa a Astra en el 65,5 %, frente al 55,0 % de Argon, y Terminal-bench 4.0 da a Opus un 66,4 %, frente al 57,4 % de Argon. Las diferencias son de 10,5 y 9,0 puntos porcentuales, calculadas a partir de las cifras publicadas. [2]
La diferencia importa porque «el mejor para programar» es una conclusión demasiado amplia para esta tabla. Resolver un problema acotado y completar un encargo largo pueden exigir cosas distintas a un agente. Los resultados sugieren que la tarea debe determinar qué modelo pruebo primero, que es la misma distinción práctica que explico en por qué los benchmarks de IA no reflejan toda la calidad de un modelo.
Los buenos resultados de Argon también aparecen fuera de la programación. Google publica un 51,3 % para Argon en High en AutomationBench, frente al 41,4 % de Astra en Max y el 42,5 % de Opus 5.5 en Max con fallbacks predeterminados. En la evaluación de Zapier, un paso rechazado se envía al modelo de respaldo predeterminado del proveedor. Eso justifica investigar los flujos automatizados, pero ese resultado no elimina las debilidades visibles en las filas de código. [2] [11]
¿Por qué discrepan los benchmarks de código?
Los benchmarks evalúan trabajos diferentes, y Google también combina resultados obtenidos con métodos distintos. El modelo es solo una parte del sistema evaluado: las instrucciones, las herramientas y el tiempo disponible pueden cambiar el resultado. El informe de evaluación de Google aporta los detalles necesarios para interpretar la tabla. [3]
En DeepSWE, Google evaluó Argon con el harness mini-swe, el software que proporciona las herramientas al modelo y ejecuta la tarea. Las cifras de sus competidores proceden del ranking del benchmark o de las fichas de sus fabricantes. Google suele publicar sus resultados con el nivel de razonamiento más alto; pass@1 mide el éxito en un solo intento, sin votar entre respuestas generadas en paralelo. Esa regla tiene excepciones y no puede aplicarse a todas las filas. [3]
La calidad de los tests de DeepSWE también merece atención. En su auditoría del 7 de septiembre de 2026, Epoch AI encontró errores en al menos 23 de las 113 tareas, donde soluciones válidas podían marcarse como fallos. La auditoría no demuestra que la puntuación de Argon sea incorrecta, pero me da un motivo para tratar con cautela la diferencia exacta, en lugar de asumir que todas las tareas eran pruebas fiables. [10]
FrontierSWE es una excepción importante. El ranking público de Proximal muestra la media de cinco intentos en cada una de las 34 tareas, con un máximo de 20 horas por intento en su entorno de agentes proximus. También muestra el peor y el mejor resultado. Es una medición distinta de la tasa de éxito en un solo intento, y las ejecuciones largas sirven para evaluar si un agente puede seguir trabajando en un encargo exigente. [4]
También existe una comprobación independiente de sus capacidades generales. En la consulta del 1 de octubre del Intelligence Index v4.3.2, Artificial Analysis da a Argon en High una puntuación redondeada de 53, igual que Astra en Max. Opus 5.5 en Max con fallback predeterminado obtiene 58. Las configuraciones son distintas y el índice combina diez evaluaciones, principalmente de texto en inglés; no es un porcentaje de tareas de repositorio completadas. Es otro motivo para probar Argon sin perder de vista los resultados individuales de programación. [5] [7] [8]
Por eso me interesa la configuración completa al comparar Claude y Codex en funcionalidades grandes. Si una ejecución recibe más tiempo o herramientas distintas, el resultado puede seguir siendo útil, pero responde a otra pregunta que cambiar únicamente el modelo.
¿Tiene Gemini 4 Argon una ventana de contexto de un millón de tokens?
El anuncio del millón de tokens se refiere a la salida. Google afirma que Argon eleva el límite de salida de 64.000 a un millón de tokens, lo que permite generar respuestas mucho más largas. Eso establece cuánto puede producir el modelo, pero no anuncia una nueva ventana de contexto de entrada. [1]
La distinción tiene consecuencias prácticas. La ventana de contexto limita el material con el que el modelo puede trabajar en una petición; el límite de salida determina cuánto puede generar. Una salida más larga podría ayudar cuando el encargo requiere mucho código o un informe detallado, pero no establece por sí sola cuánto del repositorio puede proporcionarse como entrada.
El nuevo límite equivale a unas 15,6 veces el anterior, de 64.000 tokens. Es un cálculo a partir de las cifras de Google, no una afirmación de que una tarea dure 15,6 veces más o gane fiabilidad en la misma proporción. El límite indica dónde debe detenerse la generación, no si merece la pena conservar todo lo que se ha producido antes.
Me interesaría primero el trabajo que antes se detenía sin entregar un resultado completo. Mantendría la gestión de contexto para agentes de programación, porque un mayor presupuesto de generación no justifica quitar las instrucciones y la información del repositorio que hacen comprensible la tarea. La evaluación seguiría buscando un cambio que pueda revisar, no una cantidad de tokens.
¿Quién puede usar Gemini 4 Argon en el lanzamiento?
El acceso empieza con equipos de ciberdefensa de confianza dentro del programa Fairwind de Google. La empresa dice que después llegará a más usuarios, empezando por los clientes de pago de la API y los suscriptores de Google AI Ultra, pero no da una fecha para esa etapa. A 1 de octubre de 2026, el acceso se amplía por etapas y todavía no está abierto a todos los desarrolladores. [1]
Google DeepMind describe Fairwind como un programa de acceso anticipado para organizaciones aprobadas que trabajan en seguridad defensiva e investigación. Entre sus socios puede haber gobiernos y responsables de infraestructuras críticas, sujetos a controles de acceso y restricciones de uso. El programa requiere una aprobación aparte, por lo que una cuenta de pago ordinaria no implica acceso al despliegue inicial de Argon. [6]
El énfasis del lanzamiento en ciberseguridad tiene un benchmark detrás. La tabla de Google da a Argon un 68,0 % en CWE-bench v1, igual que Astra y ligeramente por encima del 67,0 % de Opus 5.5. CWE-bench evalúa la auditoría y corrección de vulnerabilidades: Argon usa Antigravity, Astra usa Codex y Opus usa Claude Code. Las puntuaciones comparan modelos junto a sus herramientas de agente, por lo que respaldan un buen resultado del sistema Argon evaluado, no una ventaja del modelo aislado. [2] [9]
Para un desarrollador que elige herramientas ahora, la restricción de acceso importa tanto como una puntuación prometedora. Puedo preparar una tarea de comparación, pero no incorporar un anuncio a un flujo de producción. Esperaría a conocer la vía de acceso documentada y la configuración del modelo antes de cambiar una integración.
¿Cuánto costará Gemini 4 Argon?
Google anuncia tarifas iniciales de API de 2 dólares por millón de tokens de entrada y 10 dólares por millón de salida. Después pasan a 4 y 20 dólares. La entrada en caché recibe un descuento del 95 %. Son tarifas anunciadas para la próxima ampliación del acceso; Google no indica cuánto durará el periodo inicial. [1]
Tarifas de API anunciadas. Los precios de entrada en caché se calculan a partir del descuento del 95 % de Google. No se anunció una fecha de fin para el periodo inicial. [1]
| USD por millón de tokens | Tarifa inicial | Tarifa posterior |
|---|---|---|
| Entrada sin caché | 2,00 | 4,00 |
| Entrada en caché | 0,10 | 0,20 |
| Salida | 10,00 | 20,00 |
Las tarifas normales por token duplican las iniciales, así que presupuestaría el trabajo recurrente con 4 y 20 dólares. Para una petición hipotética de 100.000 tokens de entrada sin caché y 10.000 de salida, las tarifas dan un coste de 0,30 dólares al principio y 0,60 después. Son cálculos del cargo por tokens, no mediciones del coste de una tarea.
El límite de un millón de tokens de salida también hace más visible esa parte de la factura. Generar un millón de tokens de salida facturados costaría 10 dólares con la tarifa inicial o 20 después, antes de contar la entrada. El modelo no necesita llegar al límite en cada petición. Fijaría un presupuesto de generación para la tarea, en lugar de considerar preferible la respuesta más larga permitida.
Esta es la distinción que explico al analizar el menor coste medido por tarea de GPT-6.1 Sol: el precio por token y el coste del trabajo terminado son mediciones diferentes. El precio de Argon será más útil cuando una evaluación registre los tokens necesarios para producir un resultado aceptado.
¿Qué probaría cuando se amplíe el acceso?
Probaría una tarea suficientemente larga para revelar las diferencias entre los benchmarks de programación y mediría el trabajo necesario para aceptar el resultado. La puntuación de Argon en DeepSWE justifica esa prueba; sus resultados inferiores en FrontierSWE y Terminal-bench me indican que debo observar la ejecución sostenida, en lugar de juzgarlo por la primera respuesta.
La comparación partiría del mismo commit del repositorio, con las mismas instrucciones, herramientas y comprobaciones de aceptación. Incluiría una corrección acotada y un cambio mayor que requiera varios pasos, repetiría las ejecuciones y conservaría los fallos en los resultados. Mediría el tiempo de revisión junto al coste de la API, porque un parche barato que necesita muchas reparaciones no es trabajo terminado barato.
También separaría la finalización del volumen. Una respuesta más larga ayuda si entrega la parte que faltaba del encargo; si añade código ajeno a la tarea, crea otra carga de revisión. Quiero saber si Argon puede terminar el cambio grande con menos correcciones al precio normal. Esa es la comparación que prepararía mientras se amplía el acceso.





