Gemini 3.6 Flash: Thinking-Regler bewegt die Kosten um 30x

Bei Gemini 3.6 Flash werden neben der Antwort auch Thinking-Tokens abgerechnet. Wie viele davon das Modell verbraucht, lässt sich für jeden Request einstellen. Bei derselben Schreibaufgabe mit 120 Wörtern kostete die Standardeinstellung $0.03316, mit minimal waren es $0.00110. Das ist ein Faktor von 30, obwohl Leser keinen Unterschied im Ergebnis erkennen konnten. Dieser Regler ist die wichtigste Stellschraube für die Kosten des Modells, hat aber einen klaren Haken. Gemini 3.6 Flash ist seit 2026-07-21 allgemein verfügbar und kostet $1.50 pro Million Input-Tokens sowie $7.50 pro Million Output-Tokens. Bei 3.5 Flash waren es noch $9 für den Output. Gleichzeitig erschienen Gemini 3.5 Flash-Lite und die auf Security abgestimmte Variante 3.5 Flash Cyber. Dieser Beitrag untersucht die beiden universell einsetzbaren Tiers: 3.6 Flash und Flash-Lite.

TL;DR

• reasoning_effort: "minimal" senkte die Kosten pro Call gegenüber der Standardeinstellung um 91-97% und bei einer Aufgabe mit 120 Wörtern um den Faktor 30. Bei einstufigen Aufgaben, strukturiertem Output und Tool-Calls gab es keinen Genauigkeitsverlust, bei mehrstufiger Mathematik sank die Trefferquote jedoch von 3/3 auf 0/3.
• Googles Angabe „17% weniger Output-Tokens“ hängt vom Workload ab: Unsere Reasoning-lastigen Aufgaben benötigten 19% weniger Tokens und waren 32% günstiger. In unserer Agent-Suite stieg der Token-Verbrauch dagegen um 9%, während die Kosten um 6% sanken.
• Das Kontextfenster mit 1M Tokens ist real: Eine bei 972K Tokens platzierte Information wurde korrekt wiedergegeben. Auch beim Prompt-Caching entspricht die Untergrenze exakt den von Google genannten 4,096 Tokens. Anders als manche Modelle mit angeblichem „1M-Kontext“ hält Gemini damit beide Spezifikationen ein.

Alle folgenden Werte wurden am 2026-07-24 über das Synthorai-Gateway gemessen. Wiederholte Prompts erhielten jeweils einen Salt, um Cache-Treffer zu verhindern. Sämtliche Zahlen basieren auf den Rohdaten zur Nutzung.

Was kostet Gemini 3.6 Flash pro Aufgabe mit den Standardeinstellungen?

Der größte Teil der Output-Kosten entfällt auf Reasoning. Diese Tokens werden auch dann berechnet, wenn sie nicht sichtbar sind. Mit dem standardmäßigen Effort verbraucht das Modell deutlich mehr Tokens fürs Denken als für die eigentliche Antwort. Abgerechnet werden sie zum vollen Output-Preis von $7.50/M:

Dieses Muster sollte man im Kopf behalten: Selbst eine Faktenantwort mit zwei Tokens verursachte 69 Reasoning-Tokens. Beim Absatz mit 120 Wörtern verbrauchte das Modell 30-mal mehr Tokens fürs Denken als fürs Schreiben. Die Anzahl der Reasoning-Tokens steht in completion_tokens_details.reasoning_tokens, ihr Inhalt bleibt jedoch verborgen. Gemini liefert weder eine Zusammenfassung noch einen Trace des Denkprozesses. In unserer Untersuchung zur Anatomie des Token-Verbrauchs ist das die geschlossenste Variante: Kimi K3 gibt seine vollständige Gedankenkette zurück, GPT-5.6 zumindest eine Zusammenfassung. Im nächsten Abschnitt geht es darum, diese Kosten zu senken.

Was bewirkt der Thinking-Regler tatsächlich?

Der Regler ist eine echte, monotone Stellschraube für die Kosten und bei den meisten Aufgabentypen praktisch geschenktes Geld. Mit reasoning_effort beziehungsweise dem nativen thinking_config.thinking_level auf minimal sank die Zahl der Reasoning-Tokens auf null. Die Kosten pro Aufgabe gingen um 91-97% zurück:

Akzeptiert werden die Werte minimal, low, medium (Standard) und high. In unseren Tests stieg der Reasoning-Verbrauch mit jeder Stufe monoton an: minimal 0 Tokens, low ~180, medium ~530 und high ~650. minimal kann allerdings nicht denken, und mehrstufige Arithmetik braucht genau das. Als das Modell die Textaufgabe mit Stiften und Taschen knapp beantworten sollte, lag es in allen drei Durchläufen falsch. Die falschen Antworten waren unterschiedlich und nicht auf einen einzelnen systematischen Fehler zurückzuführen. Bei Retrieval, Klassifizierung, Formatierung und einstufigen Fragen blieb die Genauigkeit dagegen erhalten, während die Kosten um eine Größenordnung sanken.

In der Praxis gilt dieselbe Regel wie bei Kimi K3: Für Extraktion, Lookup und Formatierung ist minimal eine vertretbare Standardeinstellung. Bei Aufgaben mit Zwischenschritten ist sie gefährlich. Konfiguriert den Wert pro Route statt global und prüft die Genauigkeit mit euren eigenen Aufgaben, bevor ihr minimal für Reasoning-lastige Workloads produktiv einsetzt.

Zwei häufige Produktionsmuster zeigen das besonders deutlich: Strukturierter Output und Function Calling verbrauchen mit der Standardeinstellung Reasoning-Tokens, funktionieren aber beide zuverlässig mit minimal. Eine schema-basierte Extraktion (response_format mit einem JSON-Schema) verbrauchte standardmäßig 337 Reasoning-Tokens und lieferte gültiges JSON. Mit minimal waren es null Reasoning-Tokens, das Ergebnis entsprach weiterhin dem Schema, und die Kosten sanken um den Faktor 9. Ein Function Call verhielt sich genauso: In der Standardeinstellung fielen 74 Reasoning-Tokens an und der Call get_weather(city) war korrekt. Mit minimal gab es denselben korrekten Call ohne Reasoning-Tokens und zu einem Viertel der Kosten. Es handelt sich um einstufige Aufgaben, die lediglich „strukturiert“ verpackt sind. Das Modell muss nicht erst überlegen, um ein explizit vorgegebenes Feld zu befüllen. Besteht euer Traffic hauptsächlich aus Extraktion oder Tool-Routing, ist minimal nahezu geschenktes Geld.

Stimmt die Aussage „17% weniger Output-Tokens“?

Das hängt vom Workload ab, und der Unterschied ist aufschlussreich. Zum Launch stellte Google 3.6 Flash als Modell vor, das im Artificial Analysis Index etwa 17% weniger Output-Tokens als 3.5 Flash benötigt, bei einzelnen agentischen Evals sogar bis zu 65%. Wir haben beide Modelle mit zwei eigenen Testbeds verglichen und gegensätzliche Ergebnisse erhalten:

Bei den kurzen, Reasoning-lastigen Aufgaben bestätigte sich die Angabe nicht nur, sondern wurde sogar übertroffen: Der gesamte Output sank um 19% und lag damit nahe an Googles 17%. Fast die gesamte Einsparung entfiel auf das Denken, nicht auf die Antwort. In einem gepaarten erneuten Durchlauf beider Modelle schrumpfte die sichtbare Antwort nur um 4%, während die Reasoning-Tokens um 19% zurückgingen. Der Unterschied konzentrierte sich auf Mathematik- und Schreibaufgaben, bei denen 3.6 mit weniger Überlegung zum gleichen Ergebnis kam. Genau das erklärt den Benchmark: Wenn ein Workload stark vom Thinking-Budget abhängt, arbeitet 3.6 bei gleicher Antwort tatsächlich effizienter.

Bei agentischem Multi-Turn-Traffic kehrt sich das Vorzeichen um: Über die gesamte Suite hinweg verbrauchte 3.6 etwa 9% mehr Output-Tokens als 3.5. Der Effizienzgewinn entsteht in der Reasoning-Phase. Agent-Loops verwenden anteilig weniger ihres Budgets dafür, sodass dort weniger eingespart werden kann und die etwas längeren Turns von 3.6 überwiegen. Die Rechnung fällt trotzdem niedriger aus, nur wirken die beiden Effekte je nach Workload anders zusammen: Reasoning-lastige Aufgaben profitieren sowohl von weniger Tokens als auch von der Preissenkung von $9 auf $7.50 und werden dadurch 32% günstiger. Bei Agent-Traffic kommt die Ersparnis von 6% allein vom niedrigeren Preis. „17% weniger Output-Tokens“ trifft zu, wenn Thinking den Output dominiert. Andernfalls kann sich der Effekt umkehren. Messt daher euren eigenen Traffic-Mix, statt euch auf die Schlagzeile zu verlassen. Der Regler aus dem vorigen Abschnitt hat ohnehin deutlich mehr Einfluss als der Versionswechsel.

Ist das Kontextfenster mit 1M Tokens real?

Ja, und bei Überschreitung gibt es einen klaren Fehler statt stiller Kürzung. Wir haben eine abzurufende Information am Anfang von Prompts mit steigender Größe platziert. Selbst bei 972K Input-Tokens wurde sie noch korrekt wiedergegeben. Ein Prompt oberhalb des Limits lieferte sauber 400 input token count exceeds the maximum, statt Inhalte unbemerkt abzuschneiden. Das ist relevant, weil nicht jedes als „1M-Kontext“ vermarktete Modell tatsächlich das vollständige angegebene Fenster bereitstellt. Wer den Test nachbauen will, sollte abwechslungsreichen, satzförmigen Fülltext verwenden. Ein Prompt aus demselben ständig wiederholten Token ließ das Modell schon deutlich vor dem Größenlimit in unbrauchbares Kauderwelsch abgleiten.

Das Prompt-Caching läuft automatisch und entspricht bei der entscheidenden Zahl genau der Spezifikation. Google nennt für das Context-Caching der Flash-Modelle mindestens 4,096 Tokens. Unser Sweep traf diese Grenze exakt: Präfixe mit bis zu ~2.1K Tokens wurden nie gecacht, ab etwa 4.1K Tokens gab es Hits. Nach einem Warm-up von 5 bis 8 Calls blieben bei jedem Hit ungefähr die letzten 2.1K Tokens ungecacht. Gecachter Input kostet $0.15/M und damit ein Zehntel des regulären Preises von $1.50. Das ist der erfreuliche Fall: Bei manchen von uns getesteten Modellen versprechen die veröffentlichten Werte mehr, als der Endpoint tatsächlich liefert. Bei Gemini 3.6 Flash funktionieren sowohl die Cache-Untergrenze als auch das Kontextfenster mit 1M Tokens wie dokumentiert. Caching lohnt sich weiterhin nur für wirklich lange, stabile Präfixe. Die Flash-Tiers unterstützen außerdem nur automatisches, implizites Caching und nicht die explizite Cached-Content-API. Ein großes Dokument lässt sich daher nicht manuell fest im Cache halten und unterhalb der Mindestgrenze wiederverwenden.

Welche Rolle spielt Gemini 3.5 Flash-Lite?

Flash-Lite ist der Tier mit vorhersehbaren Kosten. Das Modell verbraucht nie unbemerkt Reasoning-Tokens, daher entsprechen die Kosten für den Output direkt dem sichtbaren Ergebnis. Bei derselben mehrstufigen Mathematikaufgabe kostete Flash-Lite $0.00057, während 3.6 Flash mit der Standardeinstellung $0.00368 kostete. Flash-Lite war damit etwa 6-mal günstiger und legte den Rechenweg offen, statt ihn in einem verborgenen Reasoning-Feld abzulegen. Mit $0.30/M für Input und $2.50/M für Output ist es die passende Standardeinstellung für große Mengen latenzkritischer, einstufiger Aufgaben. Wechselt zu 3.6 Flash, wenn eine Aufgabe das zusätzliche Reasoning benötigt, das sich über den Regler aktivieren lässt. Der Tokenizer ist nicht nur bei den drei neuen Modellen unverändert, sondern reicht bis Gemini 2.5 Flash zurück: Für Englisch, Chinesisch, Japanisch, Koreanisch und Python haben wir über alle geprüften Generationen identische Token-Zahlen gemessen. Sprachspezifische Budgets für 2.5 lassen sich daher ohne neue Baseline auf 3.6 übertragen.

FAQ

Lässt sich Reasoning bei Gemini 3.6 Flash vollständig deaktivieren?

reasoning_effort: "minimal" beziehungsweise thinking_level: "minimal" senkte die Zahl der Reasoning-Tokens in unseren Tests auf null und ist die niedrigste Reglerstufe. Akzeptiert werden minimal, low, medium und high. Einen separaten Zustand „disabled“ gibt es nicht. Versuche, Reasoning hart zu deaktivieren, werden upstream abgewiesen. Niedriger als minimal geht es also nicht, für einstufige Aufgaben reicht das aber aus.

Warum ist meine Gemini-Rechnung höher, als die sichtbare Antwort vermuten lässt?

Reasoning-Tokens werden zum vollen Output-Preis berechnet, sind aber nicht im zurückgegebenen Text enthalten. Selbst eine Antwort mit zwei Tokens kann Dutzende bis Tausende kostenpflichtige Reasoning-Tokens enthalten. Den tatsächlichen Output-Verbrauch findet ihr in completion_tokens_details.reasoning_tokens oder über total_tokens − prompt − completion. Senkt den Regler, wenn die Aufgabe es zulässt.

Gemini 3.6 Flash oder Claude Haiku 4.5?

Beide besetzen bei ähnlichen Preisen denselben schnellen Tier. Welches Modell besser passt, hängt vom Workload ab. Aus Kostensicht ist der Thinking-Regler das Unterscheidungsmerkmal von 3.6 Flash: Mit minimal wird es bei einstufigem Traffic um eine Größenordnung günstiger. In der Standardeinstellung berechnet es dagegen Reasoning-Tokens, die bei Haiku 4.5 zum Preis von $1/$5 nicht anfallen. In veröffentlichten Benchmarks liegt Haiku 4.5 bei anspruchsvollen Coding-Aufgaben vorn, 3.6 Flash dagegen bei Mathematik und beim reinen Token-Preis. Entscheidet anhand eures Traffics und testet beide Modelle mit euren eigenen Aufgaben, bevor ihr euch festlegt.

Ist Gemini 3.6 Flash günstiger als 3.5 Flash?

Ja, bei allen von uns gemessenen Workloads. Wie groß der Unterschied ist, hängt von der Art der Aufgaben ab. Der Output-Preis sank von $9/M auf $7.50/M. Bei kurzen, Reasoning-lastigen Aufgaben benötigte 3.6 zusätzlich weniger Output-Tokens, wodurch die Kosten um etwa 32% zurückgingen. Bei Agent-Traffic verbrauchte es etwas mehr Tokens; dort stammte die Ersparnis von etwa 6% allein aus der Preissenkung. Günstiger ist es in beiden Fällen. Migriert und messt euren eigenen Traffic-Mix erneut. Eine Aufschlüsselung der Token-Kosten über mehrere Modellfamilien hinweg findet ihr in unserer Untersuchung zur Anatomie des Token-Verbrauchs.

Gemessen am 2026-07-24 mit gemini-3.6-flash, gemini-3.5-flash und gemini-3.5-flash-lite über das Synthorai-Gateway. Die Token-Zahlen der Task-Matrix und Agent-Suite stammen aus den Nutzungsdaten der einzelnen Calls. Die Ergebnisse des Effort-Reglers basieren auf einer gesalzenen Ablation mit fünf Aufgaben (n=3 pro Zelle), die Kontext- und Cache-Tests auf Needle-Recall- und Präfix-Sweeps. Für die Genauigkeitswerte wurden Aufgaben mit genau einer überprüfbaren Antwort verwendet. Preise und Verhalten können sich ändern; prüft sie anhand eurer eigenen Nutzungsdaten.

← Zurück zum Blog