Google berichtet, dass zwei Änderungen an seinem Agent Development Kit (ADK), die Gemini 4 Argon vorgeschlagen hatte, den Aufwand für bestimmte Abläufe verringerten. In einem am 13. Oktober 2026 veröffentlichten Bericht beziffert das Unternehmen die Einsparung bei langen Sitzungen mit InMemorySessionService auf rund 40 Prozent und beim kalten Import des Python-Pakets auf 21 Prozent. Gemessen wurde damit der Aufwand des ADK-Frameworks – nicht Argons allgemeine Programmierleistung oder Antwortgeschwindigkeit. Google beschreibt den Versuch und seine Messwerte.
Wie Google den ADK-Lauf organisierte
Der Versuch betraf das Repository google/adk-python, Googles Open-Source-Python-Framework zum Entwickeln von Agenten. Es umfasst laut Google rund 205.000 Codezeilen, knapp 800 Quelldateien und fast 17.000 Unit-Tests. Der zweite Lauf mit Argon dauerte elf Stunden; das Kalenderdatum des Laufs nannte Google nicht.
Für diesen Durchgang verwendete Google in Antigravity den /goal-Modus und hinterlegte zwölf Dateien mit Hinweisen zu den Konventionen des Projekts. Argon schlug sechs Änderungen vor. Nach menschlicher Prüfung wurden zwei übernommen, vier verworfen. Eine frühere, etwa zweistündige Runde mit einem allgemein gehaltenen Auftrag hatte zwar Engpässe aufgespürt, aber unter anderem Vorgaben der Maintainer verfehlt. Der zweite Durchgang lief mit ausführlicheren Projekthinweisen.
Was Google im ADK-Benchmark gemessen hat
Google prüfte mehrere getrennte Arbeitslasten. Für den zurückgehaltenen Testsatz verwendete das Unternehmen sofort antwortende Modell- und Tool-Aufrufe, identische Modellanfragen vor und nach den Änderungen sowie den Median aus jeweils sechs bis zwölf Durchläufen. So sollte der zusätzliche Aufwand des ADK möglichst isoliert erfasst werden. Die Werte betreffen unterschiedliche Abläufe und lassen sich nicht zu einer einzigen Laufzeit zusammenziehen.
| Messgröße und Bedingungen | Vor der Änderung | Nach der Änderung | Veränderung |
| Vorbereitung der ersten Modellanfrage nach 50 früheren Turns; In-Memory-Sitzung, Garbage Collection aus | 64 ms | 36 ms | −43 % |
| Vorbereitung der ersten Modellanfrage nach 150 früheren Turns; In-Memory-Sitzung, Garbage Collection aus | 200 ms | 122 ms | −39 % |
Kalter Import von google.adk in einem neuen Python-Prozess | 1,22 s | 0,97 s | −21 % |
| Neuer Prozess bis zur ersten Modellanfrage, einschließlich kaltem Import und Einrichtung des ersten Turns | 3,07 s | 3,09 s | Praktisch unverändert |
| Gesamtlauf mit 158 Turns, je drei Runden aus vier Tool-Aufrufen pro Turn; Garbage Collection an | 65,6 s | 56,1 s | 9,5 s weniger, rund 14,5 % |
Die rund 40 Prozent beziehen sich auf die Vorbereitung langer Sitzungen mit InMemorySessionService. Die kürzere Importzeit beschleunigte den Weg vom Start eines neuen Prozesses bis zur ersten Modellanfrage dagegen nicht: Die benötigten verzögert geladenen Module werden laut Google im ersten Turn geladen. Auch die Gesamtlaufzeit des 158-Turn-Tests sank, doch dieser Wert beschreibt genau diesen ADK-Ablauf und keinen allgemeinen Geschwindigkeitsgewinn beim Programmieren.
Wo die Änderungen ansetzen
Die erste übernommene Änderung filtert benötigte Ereignisse aus dem In-Memory-Sitzungsverlauf, bevor dieser kopiert wird. Dadurch muss ADK für eine Anfrage nicht den gesamten Verlauf vorbereiten. Die zweite lädt ausgewählte umfangreiche Module erst bei Bedarf; öffentliche Attribute bleiben dabei laut Google weiterhin patchbar.
Der Sitzungsgewinn gilt nicht für jede Speicherart. Google zufolge änderten sich die Lesezeiten bei externen Datenbanken, SQLite, der Gemini-Plattform, Firestore und Redis durch diese Anpassung nicht. Diese Speicher lesen Sitzungsdaten aus ihrem jeweiligen Speicher, statt den beschriebenen In-Memory-Kopierpfad zu verwenden.
Was andere Programmier-Benchmarks über Argon aussagen
Google meldet für Argon 77,9 Prozent bei DeepSWE v1.1. Die Werte anderer Tests zeichnen jedoch kein einheitliches Bild. MindStudio nennt 55 Prozent bei Frontier SWE v2 und stellt dem 65,5 Prozent für GPT-6 Astra sowie 62,3 Prozent für Claude Opus 5.5 gegenüber. In MindStudios Terminal-Bench-Vergleich liegt Argon bei 57,4 Prozent, Claude Opus 5.5 bei 66,4 Prozent. MindStudio weist zugleich darauf hin, dass Argons DeepSWE-Wert mit Googles eigenem Agenten-Framework ermittelt wurde, während die Vergleichswerte aus anderen Bestenlisten und Systemberichten stammen. Googles DeepSWE-Angabe und MindStudios Benchmark-Analyse beziehen sich auf unterschiedliche Auswertungen.
Auch die von Vals AI aufgeführten Ergebnisse betreffen eigene Testsuiten: 68,17 ± 4,35 Prozent bei Code Migration und 91,91 ± 1,90 Prozent bei Vibe Code Bench v1.1. Vals AI nennt für Claude Sonnet 5.5 in diesen Tests 69,83 beziehungsweise 92,39 Prozent. Die Benchmark-Übersicht von Vals AI ergänzt damit weitere aufgabenspezifische Resultate, aber keine gemeinsame Messskala. Die Prozentwerte verschiedener Tests beantworten unterschiedliche Fragen; aus ihnen ergibt sich kein allgemeiner Sieger bei Programmieraufgaben.
NeoTeo hatte zuvor über die Kritik an Argons Programmierleistung und Googles Reaktion darauf berichtet. Der ADK-Versuch liefert dazu ein konkretes Beispiel für Änderungen an einem großen Python-Framework, nicht aber einen universellen Vergleich der Modelle.
Ein Entwickler berichtet von seinem Argon-Projekt
Navin Reddy, der den Kanal Telusko betreibt, schildert einen separaten Einsatz mit frühem Zugang zu Argon. Er berichtet, an der rund 20.000 Codezeilen umfassenden Anwendung CamStudio Recorder gearbeitet zu haben, die Rust, React und WebGL nutzt. Das ist die Erfahrung eines einzelnen Entwicklers und kein standardisierter Leistungsvergleich. Reddys englischsprachiger Bericht bei Telusko zeigt seine Projektarbeit mit Argon.
