Le 13 octobre 2026, Google a publié un compte rendu d’une expérience menée avec Gemini 4 Argon sur son framework Python Agent Development Kit (ADK). Deux modifications retenues après examen humain ont réduit certains temps de préparation de session et d’import, selon les mesures communiquées par Google. Elles concernent le fonctionnement d’ADK, pas la vitesse de génération du modèle. Google détaille l’expérience et ses résultats.
Ce compte rendu technique porte sur un sujet différent des critiques et de la réponse de Google abordées dans notre précédent article sur le codage de Gemini 4 Argon : ici, Google mesure la surcharge de son framework ADK.
Ce que Google a mesuré dans ADK
Google dit avoir confié à Argon une tâche sur google/adk-python, un dépôt d’environ 205 000 lignes réparties dans près de 800 fichiers source. L’agent a travaillé sans intervention pendant 11 heures et proposé six modifications ; deux ont été acceptées après examen humain, les quatre autres écartées. Google indique aussi que l’équipe a relancé les 16 892 tests du dépôt. La date calendaire de cette exécution n’est pas précisée.
Pour son test de contrôle, Google a utilisé des réponses instantanées du modèle et des outils, des requêtes identiques avant et après les changements, et des médianes calculées sur 6 à 12 essais. L’objectif était d’isoler le temps pris par ADK, plutôt que celui de la génération du modèle. Le test de contrôle avait été préparé avant les exécutions et n’avait pas été montré à Argon.
Les mesures varient selon la charge : elles vont de la préparation d’une session en mémoire à l’exécution complète de 158 tours. Les résultats ci-dessous sont ceux que Google rapporte pour son test de contrôle.
| Charge de travail et conditions | Avant | Après | Évolution rapportée |
| Préparation avant le premier appel au modèle, après 50 tours antérieurs ; session en mémoire, ramasse-miettes désactivé | 64 ms | 36 ms | −43 % |
| Préparation avant le premier appel au modèle, après 150 tours antérieurs ; session en mémoire, ramasse-miettes désactivé | 200 ms | 122 ms | −39 % |
Import à froid de google.adk dans un nouveau processus Python | 1,22 s | 0,97 s | −21 % |
| Nouveau processus jusqu’à la première requête au modèle, import à froid et préparation du premier tour compris | 3,07 s | 3,09 s | Stable selon Google (+1 %) |
| Exécution complète de 158 tours, trois séries de quatre appels d’outil par tour, ramasse-miettes activé | 65,6 s | 56,1 s | −9,5 s, soit environ −14,5 % |
La baisse d’environ 40 % concerne la préparation de sessions longues en mémoire. Elle ne se retrouve pas dans le temps entre le démarrage d’un nouveau processus et sa première requête au modèle : Google mesure 3,07 secondes avant les modifications et 3,09 secondes après. Pour l’exécution de 158 tours, l’écart entre les deux mesures est de 9,5 secondes.
Les deux changements ciblent des coûts précis
Les modifications acceptées filtrent les événements nécessaires d’une session en mémoire avant de les copier, et chargent certains modules volumineux seulement au moment où ils sont requis. La première évite de copier l’historique entier lorsqu’une partie suffit ; la seconde reporte le chargement de paquets sélectionnés. Google indique que cette dernière conserve les attributs publics modifiables utilisés par les tests.
Le gain sur les sessions concerne InMemorySessionService. Google indique que ces modifications n’ont pas réduit les temps de lecture des sessions stockées dans une base externe, SQLite, la plateforme Gemini, Firestore ou Redis. Les résultats ne s’étendent donc pas aux parcours de session qui s’appuient sur ces stockages.
Le tri des propositions compte aussi : parmi les quatre pistes rejetées, un cache d’événements améliorait un benchmark synthétique de 17 %, mais risquait de servir des données périmées. D’autres changements reposaient sur un attribut privé d’OpenTelemetry, ne réduisaient pas la latence de bout en bout dans le test de contrôle ou n’aidaient que des tests synthétiques de rejeu de workflows. Le gain retenu dépend donc autant de la mesure sur les charges choisies que de l’examen humain des modifications.
Les résultats de codage varient selon les benchmarks
Google rapporte 77,9 % pour Gemini 4 Argon sur DeepSWE v1.1, un benchmark de programmation. L’annonce de Google décrit ce résultat dans son évaluation du modèle. Les autres comparaisons de code donnent des résultats différents selon les tâches.
Dans son analyse, MindStudio rapporte 55 % pour Argon sur Frontier SWE v2, contre 65,5 % pour GPT-6 Astra et 62,3 % pour Claude Opus 5.5. Pour sa comparaison sur Terminal-Bench, MindStudio donne 57,4 % à Argon et 66,4 % à Claude Opus 5.5. MindStudio précise aussi que le score DeepSWE d’Argon vient du harness d’agents de Google, tandis que les résultats des autres modèles proviennent de classements et de fiches système distincts. MindStudio détaille ces comparaisons.
Vals AI rapporte séparément 68,17 % ± 4,35 sur Code Migration et 91,91 % ± 1,90 sur Vibe Code Bench v1.1 ; sur ces deux évaluations, ses chiffres pour Claude Sonnet 5.5 sont respectivement de 69,83 % et 92,39 %. Vals AI publie aussi 57,58 % ± 2,31 pour Argon sur Terminal-Bench 4.0. Les résultats de Vals AI portent sur des suites distinctes : leurs scores ne se fondent pas en une mesure unique. L’ensemble décrit des résultats propres à chaque benchmark, pas un vainqueur général en programmation.
Le projet de Navin Reddy en accès anticipé
Navin Reddy, créateur de Telusko, rapporte avoir utilisé Gemini 4 Argon en accès anticipé pour construire et faire évoluer CamStudio Recorder, une application d’environ 20 000 lignes réalisée avec Rust, React et WebGL. C’est un retour d’expérience individuel, distinct du test ADK de Google, et non un benchmark standardisé. Reddy raconte son expérience dans une vidéo en anglais.
