Gemini 4 Argon ist seit dem 13. Oktober 2026 allgemein verfügbar und hebt das bisherige Ausgabelimit von Google von 64K Tokens auf rund 1 Million an, sodass das Modell „Hunderttausende von Tokens in einem einzigen Durchlauf generieren“ kann. Im Entwickler-Leitfaden von Google wird beschrieben, wie das funktioniert. Eine normale Anfrage stoppt standardmäßig weiterhin bei 65.536 Ausgabetokens. Setzt man max_output_tokens in der Interactions API zusammen mit background: true höher, generiert der Server in Schritten von bis zu 64K weiter, bis das Limit erreicht ist – bis zu 1.048.576 Tokens abzüglich des Inputs. Google weist darauf hin, dass anspruchsvolle Prompts mehrere Minuten dauern können.
Der Satz im Ankündigungsbeitrag, den man zweimal lesen sollte, betrifft nicht das Limit selbst. Es geht vielmehr darum, wofür Google Ausgaben dieser Größenordnung eingesetzt hat. Google gibt an, Argon intern für Migrationen von C/C++ nach Rust genutzt zu haben – von „Zehntausenden Zeilen in Kernbibliotheken wie re2 und libgav1 bis hin zu über 800.000 Zeilen für den Fuchsia-Zircon-Kernel“. Zudem durchlaufen diese Neufassungen „vor dem Rollout in die Produktion gründliche automatisierte und manuelle Audits, Emulationstests und Reviews“. Selbst das Labor, das das Modell trainiert hat, prüft den Code vor der Bereitstellung. Ein Team, dessen Agenten nun Ergebnisse unter einer 16-mal höheren Obergrenze liefern können, braucht daher vor allem eines: einen Review-Plan, noch bevor es das Modell einsetzt.
TL;DR
Ein Ausgabelimit von einer Million Tokens verlagert den Flaschenhals von der Codegenerierung hin zur Freigabe. Da ein einzelner Durchlauf nun derart viel Code liefern kann, sollte man die Arbeit in Tasks aufteilen, die ein Mensch in einer einzigen Sitzung prüfen kann – jeweils mit einer schriftlichen Definition of Done sowie einem Timeout pro Task. Verlangen Sie Nachweise für jeden Task und berechnen Sie vorab die verfügbare Review-Kapazität. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen das Ergebnis ab.
Was sich ändert, wenn ein einzelner Durchlauf so viel liefern kann
Die Review-Kapazität bezeichnet die Anzahl fertiger Agenten-Ergebnisse, die ein Team pro Tag lesen, beurteilen und abnehmen kann – und sie wird von Menschen bestimmt, nicht vom Modell. Ein höheres Output-Limit erhöht lediglich die Menge, die auf einen Schlag eintreffen kann.
Die alte Obergrenze fungierte unabsichtlich als Scope-Kontrolle: Eine Antwort konnte nur eine bestimmte Länge haben, weshalb die Ergebnisse in Teilschritten mit Zwischenstopps zurückkamen. Googles Begründung für das neue Limit zielt genau in die entgegengesetzte Richtung – auf den Spielraum, „schwierige Probleme in einem Zug zu lösen“. Für Reviewer bedeutet „in einem Zug“ allerdings: ein einziges Gesamtergebnis, eine einzige Entscheidung und kein Kontrollpunkt, an dem ein Mensch rechtzeitig hätte sagen können: „Falsche Richtung“.
Hinzu kommt, dass das Token-Fenster geteilt wird. Das Fenster von 1.048.576 Tokens bei Argon umfasst Input, Thinking und Output zusammen. Ein Durchlauf, der 300K Tokens an Code einliest, hat also noch rund 748K Tokens für das Nachdenken und Generieren übrig. Das ist immer noch weit mehr, als irgendjemand in einer einzigen Sitzung Zeile für Zeile durchlesen kann.
Und dann ist da noch die Qualität. Zur Veröffentlichung berichtete Bloomberg unter Berufung auf anonyme Google-Mitarbeiter, dass Argon bei manchen Programmier- und Frontend-Aufgaben gemessen an seinen Benchmarks hinter den Erwartungen zurückbleibe; Google bezeichnete das als unzutreffend. In Googles eigener Übersicht liegt Argon in zwei von vier Kategorien für agentenbasiertes Coden hinten (unser Vergleich geht detailliert darauf ein). Ein Benchmark ist lediglich eine Aussage über einen Testdatensatz. Ihr Diff hingegen betrifft Ihre tatsächliche Codebasis – und wird anhand konkreter Nachweise abgenommen, ganz gleich, welches Modell ihn verfasst hat.
Definieren Sie den Task-Scope, nicht das Token-Budget
Die Einheit, die Sie kontrollieren, ist der Task, nicht die Token-Anzahl. Überlassen Sie der Obergrenze des Modells den Arbeitsumfang, erhalten Sie das größtmögliche Ergebnis, das es erzeugen kann. Bestimmen Sie den Umfang selbst, erhalten Sie Ergebnisse, die ein Mensch auch prüfen und freigeben kann. Googles eigene Empfehlungen bestätigen das: Behalten Sie den Standardwert von 65.536 für reguläre Aufgaben bei und nutzen Sie den Hintergrundmodus bei 131.072 oder 262.144 Tokens für komplexes Reasoning und Coding – nicht das Maximum.
Googles eigene Beschreibung unterteilt die Arbeit bereits nach Bibliotheken und Kernel. Gehen Sie bei einer Portierung genauso vor: ein Task pro Modul, den ein Reviewer in einer Sitzung bewältigen kann. In Sharkly entspricht das einem übergeordneten Task mit einem Sub-Task pro Modul sowie Verknüpfungen wie „blocks / is blocked by“, falls ein Modul zuerst fertiggestellt werden muss. Ziel, Umfang und Akzeptanzkriterien stehen in der Task-Beschreibung – gleichermaßen für den Agenten wie für den Reviewer:
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
Zwei Einstellungen für Agenten unterstützen diesen Ansatz. Das Timeout pro Task orientiert sich am Task selbst, nicht am Modell: höher als die längste realistische Laufzeit für ein einzelnes Modul, aber unterhalb einer Laufzeit, deren Kosten man bereuen würde. Die maximale Parallelität (Max concurrency bei zugewiesenen Tasks) begrenzt, wie viele Module gleichzeitig in Bearbeitung sind – denn 40 gleichzeitig laufende Sub-Tasks führen zu 40 Ergebnissen, die alle auf denselben Reviewer warten.
Die Entscheidungshilfe lautet: Übertragen Sie einem einzelnen Durchlauf die Gesamtaufgabe nur dann, wenn automatisierte Tests das vollständige Ergebnis abdecken können – wie etwa bei einer mechanischen Umbenennung, die durch den Compiler und eine vollständige Testsuite abgesichert ist. Teilen Sie die Arbeit auf, sobald ein Mensch irgendeinen Teil davon beurteilen muss, was bei Sprachmigrationen fast immer der Fall ist. Durchläufe, die über den Feierabend hinausgehen, erfordern dieselben Voraussetzungen: eine Abbruchbedingung, einen Wartezustand und eine Person, die am nächsten Morgen die Verantwortung übernimmt.
Hinterlegen Sie die Nachweise direkt am Task
Ein umfangreiches Ergebnis ohne Nachweise ist kein Review. Es ist ein Re-Run, durchgeführt von einem Menschen, in Zeitlupe.
Das Beispiel von libgav1 veranschaulicht, wie gute Nachweise aussehen. Google berichtet, dass Argon 32.000 Zeilen SIMD-Code in einer bestehenden Rust-Portierung ersetzt hat und das Ergebnis „2,7-mal schneller läuft als der bisherige Rust-Port, bei identischer Videoausgabe“. Genau die zweite Hälfte dieses Satzes macht 32.000 Zeilen überhaupt erst prüfbar: Dieselben Eingaben durchliefen den alten und neuen Code, und die Ausgaben stimmten überein. Das ist differentielles Testen – und es entlastet Reviewer, sodass sie sich auf Aspekte konzentrieren können, die ein bloßer Vergleich nicht erfasst: Unsafe-Code, Fehlerpfade und die Frage, ob der Geschwindigkeitsvorteil auch unter realen Workloads standhält.
Jeder Durchlauf sollte vier Dinge an den Task zurückmelden:
| Nachweis am Task | Frage des Reviewers, die damit beantwortet wird |
|---|---|
| Zusammenfassung der Änderungen | Was wurde geändert, wo und warum? |
| Output von Tests, Typecheck und Build | Besteht der Code weiterhin die Prüfungen, denen wir bereits vertrauen? |
| Was wurde verifiziert und wie? | Blieb das Verhalten unverändert und bei welchen Eingaben? |
| Bekannte Einschränkungen | Worauf sollte ich selbst noch ein Auge werfen? |
Genau diesen Ablauf bildet der Workflow von Sharkly ab: Der Agent führt Typecheck, Tests und den Build aus und hängt anschließend die Zusammenfassung der Änderungen, die Verifikationsergebnisse sowie bekannte Einschränkungen an; ein Mensch gibt den Task frei, fordert Änderungen an oder entscheidet über den Merge- und Release-Schritt. Die finale Antwort des Agenten wird am Task gespeichert und das Ausführungsprotokoll liegt im Tab „Executions“ – die Nachweise landen also direkt am Task statt in einem flüchtigen Terminal. Der Artikel Reviewing with task-level evidence beschreibt die empfohlene Lesereihenfolge, und Übergabe-Templates geben dem Bericht eine feste Struktur.
Erfolgreiche Prüfungen bedeuten noch keine Abnahme, und ein Merge ist es ebenso wenig: In Sharkly ändert das Mergen eines verknüpften Pull Requests nicht den Status des Tasks. Automatisierte Prüfungen verifizieren, was möglich ist – wo ihre Grenzen liegen, zeigt der Beitrag über KI-Review-Agenten. Letztlich entscheidet immer ein Mensch, ob die Änderung tatsächlich das erfüllt, was im Task gefordert war.
Berechnen Sie die Review-Kapazität vor dem Start
Reviews funktionieren wie eine Warteschlange: Ergebnisse treffen ein, ein Mensch arbeitet sie ab, und wenn mehr Ergebnisse eintreffen als abgearbeitet werden, wächst die Warteschlange. Ein höheres Ausgabelimit verändert ausschließlich die Eingangsseite. Ein Rechenbeispiel mit hypothetischen Werten:
| Beispielparameter (hypothetisch) | Wert |
|---|---|
| Module in der Migration | 40 |
| Review-Zeit pro Modul, nur Diff | 2 Stunden |
| Review-Zeit pro Modul, mit differentiellen Nachweisen und Zusammenfassung | 30 Minuten |
| Stunden, die ein Reviewer pro Tag für gründliche Reviews aufbringen kann | 3 |
Prüft man nur das reine Diff, erfordert die Migration 80 Reviewer-Stunden – etwa 27 Arbeitstage. Mit nachvollziehbaren Belegen an jedem Task sinkt der Aufwand auf 20 Stunden, also rund sieben Tage. Ob ein einzelner riesiger Durchlauf oder 40 kleinere: Der Aufwand aufseiten des Reviewers bleibt unterm Strich identisch.
Was sich grundlegend ändert, ist der Entscheidungsprozess. 40 Tasks treffen in einem steuerbaren Tempo ein, und jeder erhält sein eigenes Urteil. Ein Gesamtergebnis für alle 40 Module erhält dagegen nur eine einzige Entscheidung – ein Problem in Modul 31 blockiert somit auch die anderen 39. Mit Sub-Tasks reicht ein Kommentar zum fehlerhaften Modul, um einen Folge-Durchlauf für genau diesen Task zu starten, während die restlichen Module bereits weiterlaufen können.
Rechnen Sie auch die Kosten durch. Ein voll ausgereizter Durchlauf erzeugt rund 1 Million Ausgabetokens: Das entspricht ungefähr 10 US-Dollar beim aktuellen Preis von 10 US-Dollar pro Million Tokens bis zum 30. November und etwa 20 US-Dollar ab dem 1. Dezember. Bei einem Tier-1-Projekt liegt das ausgabenbasierte Limit von Google bei 10 US-Dollar pro rollierendem 10-Minuten-Fenster. Ein einziger maximaler Durchlauf schöpft dieses Fenster beim aktuellen Tarif bereits vollständig aus und übersteigt es ab dem 1. Dezember um das Doppelte. Halten Sie daher die maximale Parallelität (Max concurrency) bei jedem Agenten niedrig, der so lange Durchläufe ausführen darf.
Kalkulieren Sie Ihre eigenen Zahlen vor dem ersten großen Durchlauf – nicht erst, wenn die Warteschlange bereits überquillt. Der Artikel zur Berechnung der Review-Kapazität schlüsselt diese Rechnung auf Teamebene auf, und der Beitrag Menschliche Reviews als Flaschenhals stellt die Statusübergänge und Kontrollpunkte vor, die die Warteschlange transparent machen.
Checkliste vor Ihrem ersten Millionen-Token-Durchlauf
- [ ] Die Arbeit ist in Tasks unterteilt, die ein Reviewer in einer Sitzung bewältigen kann – inklusive Sub-Tasks und „Blocked by“-Verknüpfungen.
- [ ] Jede Task-Beschreibung definiert klar, was „Done“ bedeutet und was außerhalb des Umfangs liegt.
- [ ] Das Timeout pro Task ist auf die konkrete Aufgabe abgestimmt (lange Hintergrundanfragen dauern Minuten) und orientiert sich nicht am maximalen Ausgabelimit des Modells.
- [ ] Ein voll ausgereizter Durchlauf bleibt innerhalb des Ausgabenlimits Ihres API-Tiers.
- [ ] Die maximale Parallelität des Agenten für zugewiesene Tasks entspricht dem, was Reviewer tatsächlich abarbeiten können – nicht dem, was die Maschine ausführen könnte.
- [ ] Jeder Durchlauf liefert eine Zusammenfassung der Änderungen, Check- und Testergebnisse, Angaben zur Verifikation sowie bekannte Einschränkungen.
- [ ] Bei verhaltenserhaltenden Aufgaben liegt ein differentieller Abgleich mit dem alten Code vor.
- [ ] Jedem Task ist ein namentlich genannter Reviewer zugewiesen, und die Freigabe erfolgt ausschließlich durch die explizite Statusänderung dieser Person – niemals als automatischer Nebeneffekt eines Merges.
Nichts davon hängt zwingend an Argon, das sich inzwischen mit jedem kostenpflichtigen Gemini-API-Key aufrufen lässt. Googles Vorgehensweise dient hier als Blaupause: umfangreicher Output, gefolgt von Audits, Emulationstests und Reviews – und erst danach der Gang in die Produktion. Welches Forschungslabor auch immer den nächsten Sprung bei der Ausgabegröße vorlegt: Der Plan liegt im Task verankert, nicht im Modell. Sharkly legt sich nicht auf bestimmte Modelle fest: Gemäß der Agenten-Dokumentation nutzt ein Agent das Standardmodell seiner Runtime, das sich über benutzerdefinierte Argumente oder die Konfiguration des Tools anpassen lässt. Sobald ein leistungsfähigeres Modell in einer von Ihnen betriebenen Runtime bereitsteht, ändert sich lediglich dieser Wert – während Tasks, Nachweise und Review-Gates unverändert bestehen bleiben. Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Reviews bleiben so von der Anfrage bis zum Release lückenlos nachvollziehbar.
Wenn Sie bereits mehrere Agenten einsetzen, bietet Ihnen Sharkly einen zentralen Ort, um deren Aufgaben und Ergebnisse zu verwalten.
