Am Dienstag, 13. Oktober, hat Google Gemini 4 Argon allgemein verfügbar gemacht. Wer im November Budgets dafür plant, rechnet womöglich mit einem Preis, der am 30. November endet. Laut Google gilt bis dahin ein Einführungspreis von 2 $ je 1 Mio. Input-Tokens und 10 $ je 1 Mio. Output-Tokens. Ab 1. Dezember gelten doppelte Listenpreise je Token: 4 $ und 20 $. Und das Denken, also die Thinking-Tokens, zahlen Sie zum Output-Preis. Genau das ist der Posten, der in Agenten-Workflows die Rechnung bestimmt.

Das hier ist ein Meinungsstück und zugleich ein Follow-up. Am 1. Oktober haben wir über den frühen, eng begrenzten Zugang berichtet, nachzulesen in unserem Stück „Gemini 4 Argon: Was Google zuerst nur Cyber-Verteidigern gibt“. Diese Geschichte erzähle ich nicht noch einmal. Jetzt geht es ums Geld, um Konfiguration und um die Frage, was Sie in Ihre Planung schreiben sollten.

Meine These: Planen Sie Argon in Agenten-Workflows mit dem Dezember-Preis. Verstehen Sie das Thinking-Level als Kostenhebel, nicht als Komforteinstellung. Und prüfen Sie Ihre bestehende Integration auf ein halbes Dutzend Migrationsfallen, bevor der erste Produktionsaufruf rausgeht. Das ist meine Einschätzung, keine Gewissheit. Ich habe Argon nicht selbst gemessen. Alles, was ich Ihnen zeige, stützt sich auf Googles Angaben und auf Rechnungen, deren Annahmen ich offenlege.

Was am 13. Oktober bei Argon neu ist

Zuerst die Eckdaten, so wie Google sie nennt. Die Modell-ID lautet gemini-4-argon. Das Default-Thinking-Level ist laut API-Dokumentation medium, wählbar sind low, medium und high. Google empfiehlt ausdrücklich, den eigenen Workload auf allen drei Stufen zu testen. Merken Sie sich diesen Satz. Er ist nämlich keine Randnotiz, sondern der eigentliche Planungsauftrag: Wer nur den Default benutzt, hat sich für eine Kostenstufe entschieden, ohne es zu merken.

Input, Thinking und Output teilen sich ein gemeinsames Fenster von 1.048.576 Tokens. Das ist der Rahmen, in dem alles stattfindet. Wie viel davon das Denken beansprucht, entscheidet am Ende nicht Ihr Prompt allein.

Wo ist Argon überhaupt verfügbar? Hier lohnt ein genauer Blick, weil zwei Dinge namens „Pro“ im Umlauf sind. Laut Googles Blog vom 13. Oktober gilt:

Entwicklerinnen, Entwickler und Unternehmen erreichen Argon über die API in AI Studio und auf der Gemini-Plattform.
Abonnierende von Google AI Ultra bekommen Argon in Google Antigravity. Antigravity gibt es dafür nur mit Ultra.
Abonnierende von Google AI Ultra und von Google AI Pro bekommen Argon in der Gemini-App und im AI Mode der Suche.

Das Pro-Abo der Gemini-App ist aber nicht der „Google AI Pro plan“, von dem die API-Dokumentation spricht. Dort steht wörtlich: „Gemini 4 Argon is not available on the Free tier or on the Google AI Pro plan.“ Gemeint ist die API-Seite. Wer also mit einem Pro-Abo in der App chattet, hat damit noch keinen API-Zugang zu Argon. Wer auf der API-Seite im Free Tier experimentiert, kommt an Argon ebenfalls nicht heran. Für Budgetplanung heißt das: Ein Pilot braucht ein bezahltes API-Setup, und das sollten Sie vor dem Kick-off klären, nicht danach.

Einen Satz zum Rest des Blogs, damit es der Vollständigkeit genügt: Google beginnt laut eigener Angabe die Erweiterung auf hunderte weitere Fairwind-Program-Partner, und 10.000 Forschende erhalten für sechs Monate die höchste Nutzungsstufe in Google Antigravity kostenlos, nach Eignung, Kapazität und Auswahl. Für Ihr Budget ist das ohne Belang, es sei denn, Sie gehören zu dieser Gruppe.

Die Primärquellen sind Googles Ankündigung im Blog und die Seite „What’s new in Gemini 4 Argon“ in der API-Dokumentation. Lesen Sie beide selbst. Ich zitiere hier nur, was dort steht, und kennzeichne es als Googles Angabe.

Was mich an dieser Doku-Seite stört? Nichts Dramatisches. Aber die Preislogik steht prominent in einem Preisblock, während das Verhalten des Modells beim Denken in Konfigurationshinweisen versteckt ist. Beides gehört zusammen. Wer nur die Preisliste liest, sieht zwei Zahlen. Wer die Hinweise zu Limits und Timeouts liest, ahnt, wie viel Output am Ende abgerechnet wird.

Der Preis mit Ablaufdatum

Der Preisblock der Dokumentation ist erfreulich deutlich. Bis 30. November 2026 gilt der Einführungspreis, ab 1. Dezember 2026 der Listenpreis:

Input: 2 $ je 1 Mio. Tokens, ab 1. Dezember 4 $.
Output: 10 $ je 1 Mio. Tokens, ab 1. Dezember 20 $.
Gecachter Input über implizites Caching: 0,10 $ je 1 Mio. Tokens, ab 1. Dezember 0,20 $.

Der entscheidende Satz im Preisblock lautet im Original:

Output tokens, including thinking tokens: $10.00 per 1M tokens ($20.00 starting December 1, 2026)

Lesen Sie das „including thinking tokens“ zweimal. Es heißt: Was das Modell intern an Überlegung erzeugt, wird zum Output-Preis berechnet, auch wenn Ihre Anwendung davon nichts anzeigt. Dazu kommt eine Fußnote im Google-Blog. Laut Google gilt nach Ablauf der Einführungsphase am 30. November der Preis von 4 $ und 20 $, und er „applies to the Argon model intended for public access only“. Ich lese das als Hinweis, dass die Preisangaben genau für das öffentlich zugängliche Modell gelten, und mehr nicht.

Listenpreis je 1 Mio. Tokens laut Google (bis 30. November)

Jetzt zur ersten dm-Rechnung, bewusst grob. Annahme: Sie verarbeiten 1 Mio. Input-Tokens und erzeugen 1 Mio. Output-Tokens, inklusive Thinking. Rechenweg bis 30. November: 2 $ + 10 $ = 12 $. Ab 1. Dezember: 4 $ + 20 $ = 24 $. Je Token verdoppeln sich also die Listenpreise. Ob Ihre Gesamtkosten sich verdoppeln, hängt allein von Ihrem Volumen ab. Läuft weniger, kostet es weniger, läuft mehr, kostet es mehr. Die Verdopplung gilt für den Preis je Token, nicht automatisch für die Rechnung am Monatsende.

Die Einführungsphase dauert vom 13. Oktober bis 30. November, beide Tage eingeschlossen. Das sind rechnerisch 49 Tage: 19 Tage im Oktober (13. bis 31.) plus 30 Tage im November. Für ein Projekt, das im November erst Budget bekommt, bleiben davon oft nur Wochen. Für ein Projekt, das Anfang Dezember in Produktion geht, bleibt gar nichts.

Hier ist meine Wertung, und ich kennzeichne sie als solche: Ich halte den Einführungspreis für ein Lockangebot mit Ablaufdatum. Das sage ich ohne Vorwurf. Einführungspreise sind branchenüblich, und Google nennt das Enddatum offen. Das Problem liegt bei den Planenden, die den günstigeren Preis zur Rechengrundlage machen, weil er in der Tabelle zuerst steht. Ob Google die Einführungsphase verlängert, steht in keiner der beiden Quellen. Planen Sie also nicht damit.

Für die Einordnung ein einziger Satz zum Markt: Ab 1. Dezember liegt Argon auf API-Listenpreis-Niveau von Muse Wonder, das laut Metas Preisseite, wie in unserem Stück zum Contributor-Modus nachzulesen, 4 $ Input und 20 $ Output je 1 Mio. Tokens kostet.

Und die Kürze der Frist hat noch eine zweite Seite. Wer im Oktober und November testet, misst unter dem Einführungspreis. Wer daraus Business Cases ableitet, vergleicht Äpfel mit der Hälfte der Äpfel. Rechnen Sie jede Testkostenzeile gedanklich mal zwei, sobald es um die Planung für das nächste Jahr geht.

Denken kostet Output-Preis

Was bedeutet es, wenn Thinking zum Output zählt? Es heißt zuerst: Das Reasoning-Volumen ist kein Qualitätsmerkmal, das gratis dabei ist, sondern ein Kostenfaktor. Bei einem klassischen Chat-Modell fragen Sie sich, wie lang die Antwort wird. Bei Argon fragen Sie sich zusätzlich, wie lange das Modell nachdenkt. Und nur eine der beiden Größen sehen Sie im Ergebnis.

Wie viel Thinking Argon bei Ihrer Aufgabe erzeugt, kann ich Ihnen nicht sagen. Das hängt vom Aufgabenprofil und vom gewählten Thinking-Level ab. Die Quellen nennen keine typischen Mengen, und ich erfinde keine. Ich kann Ihnen nur sagen, wo Sie nachsehen müssen: in den Nutzungsangaben Ihrer eigenen Aufrufe, getrennt nach Level.

Daraus folgt der Kern meiner These. Das Thinking-Level ist der Hebel. Google sagt es selbst, wenn auch an anderer Stelle: Wer weniger Tokens will, soll das Thinking-Level senken, nicht das Limit für die Ausgabe. Das ist übrigens eine ziemlich klare Ansage. Ein niedrigeres max_output_tokens spart nicht, es schneidet ab. Dazu gleich mehr.

Für Teams bedeutet das eine neue Disziplin. Bisher war Modellwahl eine Frage von Preis und Qualität. Bei Argon kommt eine dritte Achse dazu, nämlich die Denktiefe pro Aufruf. Es lohnt sich, nicht jeden Schritt eines Agenten auf derselben Stufe laufen zu lassen. Ein Schritt, der nur ein Feld aus einem Dokument zieht, braucht vermutlich nicht dieselbe Überlegung wie ein Schritt, der einen Plan über zehn Tools hinweg ableiten soll. Das ist meine Vermutung, kein Messergebnis. Aber sie ist testbar, und Google rät ja selbst zum Test auf allen drei Stufen.

Auch die Frage, welches Modell überhaupt für welchen Schritt läuft, gehört dazu. Wie sich Routing als Kostenhebel verhält, haben wir am Beispiel eines anderen Modells beschrieben, und die Logik überträgt sich: Wer Aufgaben nach Schwierigkeit verteilt, zahlt nicht für Tiefgang, den die Aufgabe nicht braucht. Wir bei digital-magazin.de halten das für eine unterschätzte Stellschraube in Agentenarchitekturen, weil sie keine einzige Zeile Prompt-Arbeit verlangt, sondern nur eine ehrliche Bestandsaufnahme der Schritte.

Eine Randbemerkung zur Kommunikation im Haus. IT-Verantwortliche und Einkauf sprechen bei Modellen gern über „Preis pro Million Tokens“. Bei Argon sollten sie über „Preis pro erledigtem Schritt“ sprechen. Das ist unbequemer, weil es Messung verlangt. Es ist aber die einzige Zahl, die später in der Rechnung wiederzufinden ist.

Die Rechnung für einen Agentenschritt

Dann rechnen wir ein Beispiel durch. Wichtig vorab: Es ist eine dm-Rechnung mit angenommenen Token-Mengen, kein Messwert. Die Annahme lautet: Ein Agentenschritt hat 20.000 Input-Tokens und 30.000 Output-Tokens, wobei das Thinking in diese 30.000 eingerechnet ist. Kein Caching. Das Thinking-Volumen hängt in der Praxis vom Aufgabenprofil und vom Level ab, die 30.000 sind also eine Setzung.

Rechenweg bis 30. November:

Input: 0,02 Mio. Tokens × 2 $ = 0,04 $.
Output inklusive Thinking: 0,03 Mio. Tokens × 10 $ = 0,30 $.
Summe: 0,04 $ + 0,30 $ = 0,34 $ je Schritt.

Derselbe Schritt ab 1. Dezember, bei gleichen Annahmen: 0,02 × 4 $ = 0,08 $ für den Input, 0,03 × 20 $ = 0,60 $ für Output und Thinking, zusammen 0,68 $. Der Output-Anteil liegt in beiden Fällen bei rund 88 Prozent (0,30 von 0,34 $ beziehungsweise 0,60 von 0,68 $). Das gilt nur für diese Annahme. Mit anderen Token-Mengen kippt das Verhältnis, mit einem niedrigeren Thinking-Level vermutlich auch. Die Richtung bleibt aber: Wo viel gedacht wird, dominiert der Output-Preis.

Jetzt der Cache, wieder als dm-Rechnung. Annahme: Von den 20.000 Input-Tokens sind 15.000 gecacht, und zwar bis 30. November. Rechenweg: 5.000 Tokens × 2 $ je 1 Mio. = 0,010 $, dazu 15.000 Tokens × 0,10 $ je 1 Mio. = 0,0015 $. Der Input kostet dann 0,0115 $ statt 0,04 $. Der Output bleibt bei 0,30 $. Der Schritt kostet damit rund 0,31 $ statt 0,34 $.

Die Pointe ist unbequem. Caching hilft beim Input, und zwar kräftig. Das Thinking bleibt trotzdem zum Output-Preis auf der Rechnung. Wer sein Kostenproblem allein mit Prompt-Caching lösen will, löst das kleinere Problem. Das ist meine Einschätzung, und die Rechnung oben stützt sie nur für die angenommenen Mengen.

Skalieren Sie das gedanklich. Stellen Sie sich vor, ein Agent braucht für eine Aufgabe zwanzig solcher Schritte, und Ihr Team startet täglich viele solcher Aufgaben. Dann sind es nicht mehr Cent, sondern Posten, die in einer Budgetrunde auffallen. Welche Menge Sie wirklich erreichen, weiß ich nicht. Sie wissen es auch erst nach der Messung. Genau deshalb gehört die Messung vor die Zusage.

Wer Agenten nutzungsbasiert abrechnet oder intern verrechnet, steht vor derselben Frage in anderer Gestalt. Wie man Agentenkosten pro Nutzung statt pro Platz denkt, haben wir am Beispiel der Copilot-Credits durchgespielt. Das Prinzip ist übertragbar: Ohne Messung pro Schritt gibt es keine belastbare Verrechnung.

Migrationsfallen: Caching, Temperatur, Timeouts

Sanduhr neben Laptop mit Token-Verbrauchsgrafiken als Sinnbild für den befristeten Argon-Einführungspreis — Der Einführungspreis läuft ab (Symbolbild)

Nun zum Handwerk. Die API-Dokumentation nennt eine Reihe von Punkten, an denen eine bestehende Integration mit Argon anders reagiert als mit früheren Modellen. Ich gehe sie der Reihe nach durch, weil jeder für sich harmlos wirkt und alle zusammen einen Rollout bremsen können.

Explizites Caching fällt weg

Implizites Caching ist laut Google standardmäßig aktiv, und zwar für Prompts ab 4.096 Tokens. Auf Cache-Treffer gibt es 95 Prozent Rabatt. Explizites Caching dagegen, also cachedContents beziehungsweise caches.create, wird bei Argon nicht unterstützt. Aufrufe, die cached_content erzeugen oder referenzieren, sollen entfernt werden. Wer bisher seine Kostenplanung auf explizite Caches gebaut hat, muss umdenken: Der Rabatt kommt nur noch automatisch, und nur bei ausreichend langen, wiederkehrenden Prompt-Präfixen. Ob Ihr Prompt-Aufbau davon profitiert, prüfen Sie am besten an den tatsächlichen Treffern in Ihren Nutzungsdaten.

Temperatur und Verwandte

Die Parameter temperature, top_p und top_k sollen laut Dokumentation aus den Requests entfernt werden. Falls sie gesetzt sind, werden sie ignoriert. Das klingt nach einem Detail. Es ist aber eines der Dinge, die in Tests unbemerkt bleiben: Ihr Code läuft, nur ändert Ihre Stellschraube nichts mehr. Wer Reproduzierbarkeit über eine niedrige Temperatur erreichen wollte, sollte das Verhalten in seinen Tests also neu bewerten, statt sich auf den alten Wert zu verlassen.

Das Limit für die Ausgabe

Hier lauert die tückischste Falle. Für Standard-Aufgaben empfiehlt Google, den Default von 65.536 für max_output_tokens zu behalten oder gar nichts zu setzen. Bestehende Apps mit einem Limit unter 32K sollen auf mindestens 32.768 angehoben werden. Der Grund: Argon kann laut Google mehr vom Limit fürs Thinking verbrauchen als frühere Modelle. Und das Limit ist hart. Die Antwort stoppt, sobald Thinking und Output zusammen es erreichen.

Stellen Sie sich vor, ein Agent hat ein altes Limit von 8.000 Tokens, weil die Antworten früher kurz waren. Mit Argon denkt das Modell, erreicht die Grenze, und die Antwort bricht ab, womöglich mitten in einer Tool-Anweisung. Das ist ein hypothetisches Szenario, aber es folgt direkt aus dem, was die Dokumentation beschreibt. Wer weniger Tokens will, soll laut Google das Thinking-Level senken, nicht das Limit.

Wartezeiten und Timeouts

In der Dokumentation steht: „Hard prompts can take several minutes.“ Google empfiehlt Background Execution oder HTTP-Client-Timeouts von mindestens 15 Minuten. Viele Gateways, Load Balancer und Client-Bibliotheken kappen Verbindungen deutlich früher. Prüfen Sie die gesamte Kette, nicht nur Ihren eigenen Code. Und überlegen Sie, ob ein Workflow, in dem Nutzerinnen und Nutzer auf eine Antwort warten, mit solchen Laufzeiten überhaupt sinnvoll ist.

Langer Output und Multi-Turn

Long Decode reicht laut Dokumentation bis 1 Mio. Tokens abzüglich Input. Für mehr als 64K Output soll Background Execution genutzt werden. Für Multi-Turn-Dialoge und Function Calling nennt Google previous_interaction_id. Wer Unterhaltungen bisher selbst zusammensetzt und bei jedem Aufruf die gesamte Historie schickt, sollte prüfen, ob sich das mit Argon anders organisieren lässt. Ob das Kosten spart, sagt die Quelle nicht. Es ist ein Punkt für den Test, keine Zusage.

Mein Vorschlag für die Reihenfolge: erst Parameter und Caching-Aufrufe bereinigen, dann Limits und Timeouts anpassen, dann erst über Thinking-Level reden. Meiner Einschätzung nach diskutieren Teams in Migrationen gern zuerst über Qualität und stolpern dann über Konfiguration. Umgekehrt ist es billiger.

Was die Herstellerzahlen sagen – und was nicht

Google liefert in seiner Ankündigung eine Reihe von Zahlen. Ich nenne sie, weil Sie sie ohnehin in Präsentationen sehen werden, und sortiere sie ein. Alles Folgende sind Angaben von Google, nicht unabhängig geprüft.

Laut Google belegt Argon Platz 1 im Vals Index, der laut Google Leistung in Finanzen, Coding, Recht und Steuern misst.
Laut Google, intern in Antigravity gemessen, habe Argon Teams geholfen, agentische Code-Submissions um mehr als 35 Prozent zu steigern und Code-Rollbacks um fast ein Drittel zu senken.
Laut Google sanken Shortcut-Versuche auf Coding-Benchmarks auf 2 Prozent, Googles bester Wert im Vergleich zu früheren Gemini-Modellen.
Laut Google liegt der Angriffserfolg beim Gray-Swan-Test zu indirekter Prompt Injection über 15 adaptive Versuche bei 0,7 Prozent.

Fair gegenüber Google muss man sagen: Der Hersteller begründet die höhere Token-Nutzung mit gründlicherem Arbeiten. Aus Googles Sicht sprechen diese Zahlen für Effizienz pro Ergebnis. Wer mehr denkt, braucht womöglich weniger Nacharbeit, weniger Rollbacks, weniger Umwege. Dieses Argument ist nicht abwegig. Es ist plausibel, dass ein Agent, der seltener falsch abbiegt, am Ende weniger Schritte braucht.

Aber belegt ist es nicht. Unabhängige Messungen zu Kosten pro Ergebnis liegen mir nicht vor, und die genannten Quellen enthalten keine. Die Zahl zu den Code-Submissions stammt aus Googles eigener Nutzung. Der Vals-Index-Rang ist eine Herstellerangabe. Und ein niedriger Shortcut-Wert auf Benchmarks sagt nichts über Ihre Aufgaben aus. Ich verwende diese Zahlen deshalb nicht als Beleg für meine These. Meine These stützt sich auf die Preisstruktur, die schwarz auf weiß in der Dokumentation steht, nicht auf Leistungsversprechen.

Man kann das auch positiv wenden. Falls Google recht hat, wird Ihr eigener Test das zeigen: weniger Wiederholungen, weniger Korrekturschleifen, ein besserer Preis pro erledigter Aufgabe. Falls nicht, zeigt er das ebenso. In beiden Fällen ist der Test billiger als die Annahme. Und er sollte unter dem Dezember-Preis ausgewertet werden, sonst bleibt das Ergebnis geschönt.

Eine zweite Seite: Auch die Sicherheitszahl taugt nicht als Freibrief. 0,7 Prozent Angriffserfolg in einem benannten Test heißt nicht, dass Ihre Agenten mit eigenen Tools und eigenen Datenquellen genauso widerstandsfähig sind. Das ist meine Einschätzung. Wer Agenten mit Schreibrechten ausstattet, braucht eigene Prüfungen, egal wie gut die Herstellerzahl klingt.

Häufige Fragen

Wie lange gilt der Einführungspreis?

Laut Google bis einschließlich 30. November 2026. Ab 1. Dezember 2026 gelten 4 $ je 1 Mio. Input-Tokens und 20 $ je 1 Mio. Output-Tokens. Dass die Phase verlängert wird, steht in keiner der beiden Quellen. Planen Sie damit nicht.

Zählen Thinking-Tokens extra?

Sie zählen als Output. Der Preisblock sagt ausdrücklich „Output tokens, including thinking tokens“. Es gibt also keinen separaten Tarif, sondern denselben Preis wie für die sichtbare Antwort.

Kann ich Argon im Free Tier oder mit Google AI Pro auf der API nutzen?

Laut API-Dokumentation nein. Die Pro-Abos der Gemini-App und des AI Mode sind davon getrennt zu betrachten: Dort nennt der Blog Ultra- und Pro-Abonnierende als Berechtigte. Für Antigravity nennt der Blog nur Ultra.

Soll ich das Ausgabelimit senken, um Kosten zu sparen?

Google rät davon ab. Wer weniger Tokens will, soll das Thinking-Level senken. Das Limit ist hart, die Antwort stoppt, sobald Thinking und Output zusammen es erreichen. Bestehende Apps mit einem Limit unter 32K sollen laut Google auf mindestens 32.768 angehoben werden.

Welches Thinking-Level soll ich wählen?

Der Default ist medium. Google empfiehlt, den eigenen Workload auf low, medium und high zu testen. Eine allgemeine Empfehlung kann ich Ihnen seriös nicht geben, weil die Quellen keine typischen Mengen nennen. Messen Sie Kosten und Ergebnisqualität pro Level an Ihren eigenen Aufgaben.

Budget, Thinking-Level, Migration: drei Schritte vor dem 1. Dezember

Meine Einschätzung in drei Sätzen, damit sie sich nicht im Text verliert. Rechnen Sie in der Budgetplanung mit dem Dezember-Preis von 4 $ und 20 $, auch wenn Ihre ersten Tests günstiger laufen. Behandeln Sie das Thinking-Level als Kostenhebel, den Sie pro Schritt bewusst setzen. Und gehen Sie die Migrationspunkte durch, bevor etwas in Produktion geht.

Ist Argon deshalb ein schlechtes Angebot? Das behaupte ich nicht. Es kann sein, dass das Modell bei Ihren Aufgaben so gründlich arbeitet, dass der höhere Output-Anteil sich lohnt. Es kann auch sein, dass ein niedrigeres Level genügt. Ich weiß es nicht, und Google kann es für Ihren Fall auch nicht wissen.

Sicher ist nur, was in der Dokumentation steht: ein Preis, der am 30. November endet, Denken zum Output-Preis und ein paar Konfigurationsdetails, die ein Projekt bremsen können. Wer das vor dem Start weiß, plant besser. Wir bei digital-magazin.de bleiben an dem Thema dran, sobald belastbare, unabhängige Messungen zu Kosten pro Ergebnis vorliegen.