Gemini 4 Argon ist öffentlich: die Einsätze, die Google am ersten Tag meldet, und der Preis, der sich am 1. Dezember verdoppelt

Seit dem 13. Oktober lässt sich Gemini 4 Argon aufrufen. Der Changelog führt gemini-4-argon als allgemein verfügbar, und Googles Ankündigung kam mit einer langen Liste von Dingen, die das Modell schon erledigt hat. Vor zwei Wochen habe ich geschrieben, dass die Defender-Version nicht die ist, die du aufrufen wirst. Jetzt gibt es eine, die du aufrufen kannst, zu einem Preis mit Enddatum.

Das hier ist eine Liste der Einsätze, die Google meldet, jeweils mit der Quelle. Gemeldet heißt im Folgenden: Ein Google-Beitrag sagt, dass es passiert ist, und ich gebe es weiter. Ich habe das Modell nicht aufgerufen, und keiner dieser Läufe lässt sich aus dem, was Google veröffentlicht hat, exakt reproduzieren. Vor der Liste kommen die Konditionen, denn einige davon stehen in der Doku und nicht in der Ankündigung.

Wer kann Gemini 4 Argon aufrufen, und mit welchem Tarif?

Jeder im kostenpflichtigen Tarif der Gemini API, und niemand im kostenlosen. Die Preisseite, die den API-Zugang abdeckt, sagt, Argon sei „weder im Free-Tarif noch im Google-AI-Pro-Abo verfügbar“. Die Tarife unterscheiden sich je nach Produkt:

Mit einem Pro-Abo kannst du also mit Argon chatten, Entwicklerzugang ist nicht dabei. Wer darauf bauen will, braucht den kostenpflichtigen API-Tarif oder Ultra. Die letzte Zeile ist die Aufteilung aus dem Beitrag vom 1. Oktober, und sie besteht weiter: Die Ankündigung lädt Defender ein, sich „laufend um Zugang zu Argon ohne Cyber-Guardrails“ zu bewerben.

Was kostet Gemini 4 Argon vor und nach dem 1. Dezember?

$2 pro Million Input-Tokens und $10 pro Million Output-Tokens bis zum 30. November 2026, ab dem 1. Dezember dann $4 und $20. Am 1. Oktober hatte der Einführungspreis kein Enddatum. Jetzt hat er eines, in sieben Wochen.

Zwei Details zeigt die Tabelle nicht. Thinking-Tokens werden als Output abgerechnet. Und Caching gibt es nur implizit: Die Migrationsseite sagt, explizites Caching werde „auf Gemini 4 Argon nicht unterstützt“, und der implizite Rabatt gelte für Prompts ab 4.096 Tokens. Die 95 % Rabatt hängen an einem Cache-Treffer, den du nicht anfordern kannst.

Der Dezember-Preis ist der Listenpreis von Opus 5.5. Was du wegen des Preises auf Argon umziehst, entscheidest du in sieben Wochen noch einmal.

Was kostet ein langer Output von Gemini 4 Argon, wenn Long Decode den Input erneut sendet?

Mehr als Output-Preis mal Output, weil jede Fortsetzung als neue Anfrage über alles Bisherige abgerechnet wird. Das beworbene Limit heißt „1M unified“: Input, Thinking und Output teilen sich ein Fenster von 1.048.576 Tokens. Auf der Interactions API endet eine synchrone Anfrage trotzdem bei 65.536 Output-Tokens, und laut der Long-Decode-Seite gibt es einen 400, wenn du mehr verlangst und die Hintergrundausführung aus ist. Über diese Grenze hinaus kommst du mit Long Decode: ein Hintergrundlauf, erzeugt in Hops von 65.536 Tokens. Dieselbe Seite nennt die clientseitige Fortsetzung über die GenerateContent API als eigenen Weg. Den lasse ich hier weg.

Each hop sends your prompt plus everything generated so far back to the model as input, so the same tokens are counted again in every later hop.

Googles Rechenbeispiel ist ein Prompt mit 1.000 Tokens, der 200.000 Tokens Thinking und Output erzeugt. Das braucht vier Hops, mit Inputs von 1.000, 66.536, 132.072 und 197.608 Tokens. Das Usage-Feld meldet die Summe:

total_input_tokens is the sum of every hop's input, not the size of your context.

Diese Summe beträgt 397.216 Tokens, bei einem Kontext, den dieselbe Seite mit etwa 201.000 angibt. Die Doku sagt, der wiederholte Input werde durch implizites Caching um 95 % rabattiert, und du zahlst für jeden Hop, „auch für Hops, die nur Thinking enthalten“. Abgebrochene und fehlgeschlagene Läufe werden für die geleistete Arbeit abgerechnet.

Die Rechnung zu diesem Beispiel stammt von mir und ist keine gemessene Rechnung: Die 200.000 erzeugten Tokens kosten zum Einführungspreis $2.00. Die 397.216 Input-Tokens kosten etwa $0.04, wenn der erste Hop voll berechnet wird und der Input jedes späteren Hops den Cache-Preis bekommt. So dokumentiert Google das Verhalten. Ganz ohne Cache-Treffer wären es etwa $0.79. Diese zweite Zahl nenne ich als Obergrenze. Bei einem kleinen Prompt liegt der erneut gesendete Input also irgendwo zwischen einem Rundungsfehler und 40 % Aufschlag auf die Output-Kosten.

Ein großer Prompt verändert das Bild. Setz einen Prompt mit 300.000 Tokens vor denselben Output, nimm dieselben vier Hops an, und der summierte Input liegt bei rund 1,59 Millionen Tokens: etwa $0.73 nach dem dokumentierten Verhalten, davon $0.60 für den ersten, ungecachten Durchlauf des Prompts, und $3.19 an der Obergrenze, bei denselben $2.00 für den Output. Am 1. Dezember verdoppelt sich das alles.

Google beschreibt den Rabatt auf wiederholten Hop-Input als automatisch und nennt keine Miss-Rate für den Cache. Ich habe keinen Long Decode laufen lassen, also kann ich keine ergänzen. Die Zahl, die du bei deinem ersten eigenen Lauf mitschreiben solltest, ist total_input_tokens neben der Zahl der gecachten Tokens.

Was ändert sich an einer Anfrage an Gemini 4 Argon gegenüber früheren Gemini-Modellen?

Fünf Dinge sind zu prüfen, alle von der Migrationsseite. Die ersten zwei ändern das Verhalten, ohne dass ein Fehler kommt:

• temperature, top_p und top_k werden ignoriert, wenn du sie sendest.
• max_output_tokens ist eine Gesamtzahl für Thinking und Output zusammen. Google rät, jedes Limit unter 32K auf mindestens 32.768 anzuheben, weil Argon mehr davon für Thinking verbrauchen kann als frühere Modelle. Laut der Long-Decode-Seite kann ein Lauf, der das Limit noch während des Thinkings erreicht, mit leerem Text zurückkommen.
• Thinking hat drei Stufen, low, medium und high, wobei medium der Standard ist. Die Seite empfiehlt, die eigene Evaluation auf allen drei laufen zu lassen und die niedrigste zu nehmen, die besteht.
• Client-Timeouts sollten bei mindestens 15 Minuten liegen, oder die Anfrage sollte im Hintergrund laufen.
• Aufrufe für explizites Caching werden nicht unterstützt, siehe oben.

Noch ein Fakt für die Eval: Die Model Card nennt März 2026 als Wissensstand.

Was hat der Nachtlauf von Gemini 4 Argon auf Googles Agent Development Kit ausgeliefert?

Zwei von sechs vorgeschlagenen Optimierungen. Das ist der einzige gemeldete Einsatz, der sein eigenes Review-Protokoll veröffentlicht, deshalb steht er an erster Stelle. Gemeldet von drei Autoren aus Google Cloud im Google Developers Blog.

Das Ziel war google/adk-python, das Agent Development Kit (ADK): rund 205.000 Zeilen, knapp 800 Quelldateien, knapp 17.000 Unit-Tests. Eine erste Runde von etwa zwei Stunden lief ohne Repository-Anweisungen und verfehlte Konventionen der Maintainer, unter anderem mit einer Änderung an einem öffentlichen JSON-Schema. Die zweite Runde lief elf Stunden unbeaufsichtigt, las zwölf Richtliniendateien, bevor sie Code anfasste, und schlug sechs Optimierungen über 32 Dateien vor.

Das Code-Review lehnte vier ab. Eine war ein Cache auf Basis einer schwachen Referenz, der über Sessions hinweg veraltete Daten liefern konnte, für einen Gewinn von 17 %, der sich nur in einem synthetischen Benchmark zeigte. Eine las ein privates OpenTelemetry-Attribut, das ein Minor-Upgrade brechen könnte. Zwei brachten zusätzliche Komplexität, ohne die End-to-End-Zahl zu bewegen. Die zwei, die ausgeliefert wurden: den Session-Verlauf im Speicher filtern, bevor er kopiert wird, und schwere Pakete erst bei Bedarf laden. Der Beitrag meldet etwa 40 % weniger Overhead bei der Session-Vorbereitung in langen Sessions und ein um 21 % schnelleres import google.adk.

Der Lauf bestand alle 16.892 Open-Source-Tests, und eine seiner Änderungen brach trotzdem 25 interne Test-Targets bei Google, die genau die entfernten Attribute gepatcht hatten. Die Autoren nennen ihre Einschränkungen selbst. Die 40 % gelten nur für den In-Memory-Session-Service. Der Benchmark nutzte ein Modell und Tools, die sofort antworten, er misst also den Overhead des Frameworks. Die Zeit von einem neuen Prozess bis zur ersten Modellanfrage blieb gleich. Der Beitrag nennt keine Token-Zahl und keine Kosten.

Ihr Fazit:

That division of labor is why the workflow worked: the agent explores, the maintainer subtracts.

Welche anderen Einsätze von Gemini 4 Argon meldet Google?

Sechs weitere, zu denen es genug Details für eine Beschreibung gibt. In allen sechs berichten Google-Teams über sich selbst, und keines veröffentlicht ein Review-Protokoll, wie es der ADK-Beitrag tut.

1. Einen Legacy-Ordner in Chrome aufteilen. Laut der Ankündigung half Argon dabei, die zentrale Verarbeitung von Webseiten aus einem Legacy-Ordner mit rund 6 Millionen Zeilen herauszulösen, in einer Codebasis mit 40 Millionen Zeilen, „Monate an Arbeit in Wochen“. Keine Angabe dazu, wie viele Änderungen es waren oder was zurückgerollt wurde.
2. Die CPU-Last des Kommentar-Frontends von YouTube halbieren. Der Antigravity-Beitrag sagt, redundantes Emoji-Rendering habe fast 45 % des Server-Overheads ausgemacht. Darauf seien 12 Optimierungen gefolgt, und die serverseitige Latenz beim Laden der Kommentare sei um 30 ms gesunken.
3. Einen Bug-Rückstand abbauen. Von 134 offenen Meldungen schloss Argon 97 als veraltet oder doppelt, in unter drei Stunden und „mit dokumentiertem Commit-Nachweis“, und sortierte die übrigen 37 nach Zuständigen. Derselbe Beitrag.
4. Fortran nach Rust. Eine alte Fortran-Codebasis, in Rust neu geschrieben, mit einem gemeldeten Leistungsgewinn von 1,8x. Der Beitrag nennt weder die Codebasis noch ihre Größe.
5. Ein Audit der Zugriffskontrolle. Vier kritische Sicherheitslücken in Änderungen an der Zugriffskontrolle, in Code, zu dem laut Beitrag zwei frühere Frontier-Modelle „zu dem Schluss kamen, dass es null Sicherheitslücken gibt“. Die Modelle werden nicht genannt, und auch nicht, welcher Build das Audit durchgeführt hat.
6. Finanz-Workflows. In 80 Workflows über sieben Geschäftstage ergaben 15,5 Stunden menschlicher Anleitung rund 335 „menschenäquivalente Stunden“ an validiertem Output. Die Einheit stammt von Google.

Derselbe Beitrag meldet Nutzungszahlen, die ich nicht als Fälle zählen würde: über 100.000 monatliche Nutzer von Argon im internen Antigravity von Alphabet, 35 % mehr agentischer Code und 30 % weniger Rollbacks nach dem Submit über vier Wochen.

Was haben die gemeldeten Einsätze von Gemini 4 Argon gemeinsam?

Alle sieben fanden innerhalb von Google statt. Wo überhaupt ein Review-Schritt beschrieben wird, hat ein Mensch das Ergebnis danach gekürzt, und nur der ADK-Beitrag dokumentiert diesen Schritt. Die anderen behandeln Implementierung, Triage, ein Audit und Finanzarbeit und sagen wenig darüber, wer den Output geprüft hat. Die Ankündigung nennt dazu ein paar externe Namen, darunter Wiz, Isomorphic Labs und Gamow Labs. Auch die gibt Google in einem Launch-Beitrag weiter.

In jedem der sieben Fälle fehlen zwei Dinge: was es gekostet hat und auf welcher Thinking-Stufe es lief. Nur der ADK-Beitrag sagt, wie viel vom Output weggeworfen wurde, und er veröffentlicht auch seine Prompts, seine Benchmark-Methode und den gemergten Commit. Wer einen Lauf von elf Stunden kalkulieren will, hat die Token-Preise von oben und keine Token-Zahl, mit der er sie multiplizieren könnte.

Das ADK-Verhältnis ist die nützlichste Zahl im Launch-Material, weil sie nicht schmeichelt. Wenn Googles eigene Maintainer von einem Nachtlauf auf einer Codebasis mit 17.000 Tests und schriftlichen Richtlinien zwei von sechs annehmen, dann ist Review-Kapazität das Erste, was du dimensionieren musst, noch vor den Tokens. Ein Lauf ist keine Quote, aber er ist der einzige, den Google mit gezählten Ablehnungen veröffentlicht hat. Die 25 fehlgeschlagenen internen Targets zeigen dasselbe von der anderen Seite: Eine grüne öffentliche Test-Suite deckte nicht ab, was die Änderung kaputt gemacht hat.

Ist das öffentliche Gemini 4 Argon der Build aus der Benchmark-Tabelle?

Google sagt es nicht, und die Model Card zeigt jetzt Schutzmaßnahmen für den öffentlichen Build. Im Abschnitt zur Frontier-Sicherheit heißt es, Google könne „nicht ausschließen“, dass Argon die Cybersecurity-Schwelle im eigenen Frontier Safety Framework erreicht, und „wende Schutzmaßnahmen an“, um das Risiko darunter zu drücken. Außerhalb von Google bleibt der Build ohne Guardrails bei den Fairwind-Partnern. Die Card meldet außerdem, dass ungerechtfertigte Ablehnungen gegenüber Gemini 3.1 Pro um 9,6 Prozentpunkte gesunken sind. Das ist ein Vergleich mit dem Vorgängermodell. Er sagt dir nicht, wie oft der öffentliche Build sicherheitsnahe Arbeit ablehnt, die die Defender-Version erledigen würde.

Mein Punkt vom 1. Oktober zu den Cyber-Zeilen gilt unverändert: CWE-bench mit 68 % beschreibt ein Modell, und die Frage bleibt, welchen Build. Was du jetzt tun kannst: die Ablehnungen bei deinen eigenen Aufgaben zählen.

Welcher Build auch immer gelaufen ist, die Tabelle hat auch Zeilen, die Google nicht nach vorn gestellt hat. Auf Terminal-bench 4.0 kommt Argon auf 57,4 %, Opus 5.5 auf 66,4 %, und auf FrontierSWE v2 auf 55,0 %, GPT-6 Astra auf 65,5 %. Es führt bei DeepSWE v1.1 mit 77,9 % und in der GraphWalks-Zeile von 256K bis 1M mit 84,2 % gegenüber 71,8 % für GPT-6 Astra.

Solltest du Gemini 4 Argon testen, bevor sich der Preis ändert?

Ja, wenn du die Eval schon hast, und der Test ist jetzt billiger, als er im Dezember sein wird. Ich habe es nicht laufen lassen, das hier ist also eine Lesart der Doku.

Am 1. Oktober habe ich gesagt, bau die Eval vor dem Zugang, damit Tag eins ein Tausch der Modell-ID ist. Tag eins ist da, und im Tausch steckt mehr als die ID: Sampling-Parameter, die stillschweigend ignoriert werden, ein Output-Budget, von dem Argon mehr für Thinking verbrauchen kann, ein Timeout, das du anheben musst. Lass die Eval auf allen drei Thinking-Stufen laufen, wie Google es vorschlägt, und schreib die Input-Tokens pro Anfrage mit, denn bei langen Outputs passt diese Zahl nicht mehr zur Größe deines Kontexts.

Behandle den Einführungspreis als Rabatt aufs Testen. Die Entscheidung, einen Workload umzuziehen, solltest du mit $4 und $20 kalkulieren, denn so viel kostet er die meiste Zeit seines Betriebs. Ich pinne Modellversionen und lege die Metriken vorab fest, damit sich eine Änderung zuordnen lässt. Ein Preis mit Enddatum ist eine Änderung, die du heute in den Kalender eintragen kannst.

Zur Frage, auf welchem Platz man es probieren sollte, habe ich nur das Argument vom August: Das agentischere Modell passte in meinem Setup besser auf den Platz des Reviewers als auf den des Workers. Googles am besten dokumentierter Fall hat die andere Form, ein lang laufender Worker mit einem menschlichen Reviewer dahinter. Ich habe Argon auf keinem der beiden Plätze laufen lassen. Der ADK-Beitrag legt nahe, was du messen solltest, wenn du es tust: welchen Anteil dessen, was es über Nacht vorschlägt, dein Reviewer behält.