Google publicó el 13 de octubre un informe sobre una prueba de Gemini 4 Argon en su repositorio de Python google/adk-python. La compañía afirma que dos cambios aceptados tras revisión humana redujeron ciertas esperas del Agent Development Kit (ADK), sobre todo al preparar sesiones largas en memoria. Son mediciones de la sobrecarga del framework, no de la velocidad de respuesta del modelo. Google detalla el experimento y sus resultados; la fecha de la ejecución no está indicada.
Qué midió Google en ADK
El repositorio tiene unas 205.000 líneas de código, cerca de 800 archivos fuente y casi 17.000 pruebas unitarias, según Google. La compañía preparó un benchmark de control y afirma que usó solicitudes idénticas antes y después de los cambios, con respuestas instantáneas del modelo y de las herramientas para aislar el tiempo del framework. Los resultados son medianas de entre 6 y 12 ejecuciones.
| Carga de trabajo y condiciones | Antes | Después | Cambio comunicado |
| Primera solicitud al modelo tras 50 turnos anteriores; sesión en memoria y recogida de basura desactivada | 64 ms | 36 ms | −43 % |
| Primera solicitud al modelo tras 150 turnos anteriores; sesión en memoria y recogida de basura desactivada | 200 ms | 122 ms | −39 % |
Importación en frío de import google.adk en un proceso de Python nuevo | 1,22 s | 0,97 s | −21 % |
| Proceso nuevo hasta la primera solicitud al modelo, con importación en frío y configuración del primer turno | 3,07 s | 3,09 s | Prácticamente sin cambios |
| Ejecución de 158 turnos, con tres rondas de cuatro llamadas a herramientas por turno y recogida de basura activada | 65,6 s | 56,1 s | 9,5 s menos; aproximadamente un 14,5 % |
La mejora de cerca del 40 % en sesiones largas se refiere a preparar el contexto antes de enviar una solicitud al modelo. No equivale a una respuesta más rápida del modelo. De hecho, el recorrido desde un proceso nuevo hasta la primera solicitud quedó prácticamente igual: Google atribuye ese resultado a que los módulos cargados de forma diferida se necesitan en el primer turno.
Qué cambió y dónde se aplica
Gemini 4 Argon propuso seis optimizaciones y los revisores aceptaron dos. La primera filtra los eventos necesarios de una sesión en memoria antes de copiarlos; la segunda aplaza la carga de ciertos módulos pesados hasta que hacen falta, manteniendo accesibles los atributos públicos que pueden modificarse en las pruebas.
La primera ronda duró unas dos horas y partió de una instrucción general, sin guías específicas del repositorio. Google cuenta que esa aproximación alteró el esquema JSON público de un modelo de autenticación y pasó por alto casos límite relacionados con eventos simulados. Para la segunda ronda añadió instrucciones de mantenimiento en .agents/skills y utilizó el modo /goal de Google Antigravity. Argon trabajó sin supervisión durante 11 horas y, según Google, volvió a ejecutar las 16.892 pruebas del proyecto.
La revisión humana también descartó cuatro propuestas. Entre ellas había una caché que mejoraba un benchmark sintético un 17 %, pero podía devolver datos obsoletos; otras no mejoraban la latencia del benchmark de control o beneficiaban pruebas sintéticas en vez del uso habitual. El cambio final aceptado abarcó 22 archivos y añadió 17 funciones de prueba.
El ahorro en preparación de sesiones se limita a InMemorySessionService. Google dice que la prueba no redujo los tiempos de lectura de sesiones en bases de datos externas, SQLite, Gemini platform, Firestore ni Redis. Si tu aplicación usa uno de esos almacenes, las cifras de sesiones en memoria no describen ese recorrido.
Los benchmarks de programación dan resultados distintos
El 30 de septiembre, Google comunicó un 77,9 % para Gemini 4 Argon en DeepSWE v1.1, una prueba de programación de larga duración. El anuncio de Google ofrece un resultado destacado en esa suite, pero las cifras de otras pruebas dibujan un panorama menos uniforme.
MindStudio sitúa a Argon en el 55 % en Frontier SWE v2, frente al 65,5 % de GPT-6 Astra y el 62,3 % de Claude Opus 5.5. En su comparación de Terminal-Bench, informa de un 57,4 % para Argon y un 66,4 % para Claude Opus 5.5. MindStudio también advierte que la cifra de Argon en DeepSWE se obtuvo con el sistema de agentes de Google, mientras que las de otros modelos proceden de clasificaciones y fichas técnicas distintas. Su análisis recoge las comparaciones y esa diferencia metodológica.
Por su parte, Vals AI publica un 68,17 % ± 4,35 en Code Migration y un 91,91 % ± 1,90 en Vibe Code Bench v1.1 para Argon. En esas pruebas, la misma página sitúa a Claude Sonnet 5.5 en el 69,83 % y el 92,39 %, respectivamente. Vals AI presenta los resultados de cada benchmark. Como cada suite evalúa tareas distintas, el conjunto no permite proclamar un ganador general en programación.
Este seguimiento amplía la cobertura anterior de NeoTeo sobre la respuesta de Google a las críticas al rendimiento de Gemini 4 Argon: aquí la referencia concreta es la sobrecarga de ADK en un repositorio de Python, no una medida única de la capacidad de programación del modelo.
Navin Reddy relata su experiencia con una aplicación propia
Navin Reddy, creador de Telusko, cuenta que utilizó acceso anticipado a Gemini 4 Argon mientras desarrollaba e iteraba sobre CamStudio Recorder, una aplicación de unas 20.000 líneas hecha con Rust, React y WebGL. Es un caso práctico narrado por su autor, distinto de las mediciones controladas de ADK.
