Gemini 3.6 Flash: Der Thinking-Regler, der die Kosten um das 30-Fache verschiebt (gemessen)

Gemini 3.6 Flash berechnet dir zusätzlich zur Antwort auch Thinking-Tokens, und wie viele davon anfallen, steuerst du pro Request über einen Regler. Bei derselben Schreibaufgabe mit 120 Wörtern kostete die Standardeinstellung 0,03316 $, die Einstellung minimal dagegen 0,00110 $ – das 30-Fache für ein Ergebnis, das ein Leser nicht auseinanderhalten könnte. Dieser Regler ist die wichtigste Kostenentscheidung bei diesem Modell, und er hat eine scharfe Kante. Gemini 3.6 Flash ist seit dem 21.07.2026 allgemein verfügbar, zu 1,50 $ pro Million Input-Tokens und 7,50 $ pro Million Output-Tokens – gegenüber 9 $ Output bei 3.5 Flash. Es kam zusammen mit Gemini 3.5 Flash-Lite und einem sicherheitsoptimierten 3.5 Flash Cyber; dieser Beitrag misst die beiden Allzweck-Stufen, 3.6 Flash und Flash-Lite.

TL;DR

• reasoning_effort: "minimal" senkt die Kosten pro Aufruf um 91–97 % gegenüber dem Standard (das 30-Fache bei einer 120-Wörter-Aufgabe). Bei einstufigen Aufgaben, strukturierter Ausgabe und Tool-Calling ist das kostenlos, aber es bricht mehrstufige Mathematik von 3/3 auf 0/3.
• Googles “17 % weniger Output-Tokens” hängt vom Workload ab: unsere reasoning-lastigen Aufgaben liefen 19 % leichter (32 % günstiger), unsere Agent-Suite 9 % schwerer (6 % günstiger).
• Der 1M-Context ist echt (eine Nadel bei 972K Tokens wurde wiedergefunden), und Prompt Caching trifft Googles veröffentlichte Untergrenze von 4.096 Tokens exakt – eine saubere Übereinstimmung mit der Spezifikation, anders als bei manchen “1M-Context”-Modellen, die weniger liefern, als sie bewerben.

Alles Folgende wurde am 24.07.2026 über das Synthorai-Gateway gemessen, wobei wiederholte Prompts mit Salt versehen wurden, um Caches auszuhebeln; jede Zahl ist durch rohe Usage-Records belegt.

Was kostet Gemini 3.6 Flash pro Aufgabe bei Standardeinstellungen?

Reasoning dominiert die Output-Rechnung, und es wird berechnet, egal ob du es siehst oder nicht. Beim Standard-Effort verbraucht das Modell weit mehr Tokens fürs Denken als für die Antwort, und diese Reasoning-Tokens werden zum vollen Output-Satz von 7,50 $/M abgerechnet:

Das Muster sollte man sich einprägen: Eine Faktenantwort aus zwei Tokens brachte trotzdem 69 Reasoning-Tokens mit, und der 120-Wörter-Absatz verbrauchte fürs Denken 30-mal mehr Tokens als fürs Schreiben. Die Reasoning-Tokens stehen einzeln in completion_tokens_details.reasoning_tokens, du siehst also die Anzahl, aber nie den Inhalt. Gemini liefert überhaupt keine Thinking-Zusammenfassung und keine Trace – das geschlossenste Ende des Spektrums, das wir in unserer Studie zur Anatomie der Token-Nutzung kartiert haben, wo Kimi K3 seine vollständige Gedankenkette zurückgibt und GPT-5.6 eine Zusammenfassung. Im nächsten Abschnitt geht es darum, diesen Verbrauch herunterzudrehen.

Was macht der Thinking-Regler eigentlich?

Er ist ein echter, monotoner Kostenhebel, und bei den meisten Task-Typen ist er quasi geschenktes Geld. Setzt man reasoning_effort (oder das native thinking_config.thinking_level) auf minimal, gehen die Reasoning-Tokens auf null und die Kosten pro Task sinken um 91–97 %:

Der Regler funktioniert wirklich, und die akzeptierten Werte sind minimal, low, medium (der Standard) und high. Jede Stufe kaufte in unseren Tests monoton mehr Reasoning ein (minimal 0 Tokens, low ~180, medium ~530, high ~650). Das Einzige, was minimal nicht kann, ist denken – und genau das braucht mehrschrittige Arithmetik: Gezwungen, die Bleistift-und-Beutel-Textaufgabe knapp zu beantworten, lag das Modell alle drei Male daneben, mit verstreuten falschen Ergebnissen statt einem einzigen systematischen Fehler. Bei Retrieval, Klassifikation, Formatierung und einstufigen Fragen hielt minimal die Genauigkeit und senkte die Rechnung um eine Größenordnung.

Die praktische Regel deckt sich mit dem, was wir bei Kimi K3 gefunden haben: minimal ist ein vertretbarer Standard für Extraktion, Lookup und Formatierung, und ein Griff ins Klo für alles, was Zwischenschritte braucht. Setze den Wert pro Route, nicht global, und prüfe die Genauigkeit an deinen eigenen Tasks, bevor du ihn auf etwas Reasoning-lastiges loslässt.

Zwei häufige Production-Muster machen das konkret: Structured Output und Function Calling verbrauchen beide beim Standard Reasoning, und beide laufen problemlos auf minimal. Eine schema-gebundene Extraktion (response_format mit JSON-Schema) verbuchte beim Standard 337 Reasoning-Tokens und lieferte valides JSON; bei minimal waren es null Reasoning-Tokens, das JSON war weiterhin valide und schema-konform, und die Kosten lagen um Faktor 9 niedriger. Ein Function Call verhielt sich genauso: 74 Reasoning-Tokens und ein korrekter get_weather(city)-Aufruf beim Standard, gegenüber null Reasoning und demselben korrekten Aufruf bei minimal, 4x günstiger. Das sind einstufige Tasks im “strukturierten” Gewand, und das Modell muss sich den Weg zu einem Feld, das es füllen soll, nicht erst erdenken. Wenn dein Traffic also aus Extraktion oder Tool-Routing besteht, ist minimal quasi geschenktes Geld.

Hält die Behauptung “17 % weniger Output-Tokens” stand?

Das hängt vom Workload ab, und die Aufteilung ist aufschlussreich. Beim Launch positionierte Google 3.6 Flash so, dass es im Artificial Analysis Index rund 17 % weniger Output-Tokens verbraucht als 3.5 Flash (bei einzelnen agentischen Evals bis zu 65 %). Wir haben beide Modelle durch zwei eigene Testbeds geschickt und dabei gegensätzliche Vorzeichen erhalten:

Bei den reasoning-lastigen Kurzaufgaben bestätigte sich die Behauptung nicht nur, sie übertraf sogar den Schlagzeilenwert: Der gesamte Output fiel um 19 %, nahe an Googles 17 %, und das kam fast ausschließlich vom Thinking, nicht von der Antwort. Wenn man die Output-Tokens in einem gepaarten Rerun beider Modelle aufteilt, schrumpfte die sichtbare Antwort nur um 4 %, während das Reasoning um 19 % fiel, konzentriert auf die Mathe- und Schreibaufgaben, bei denen 3.6 mit weniger Überlegung zum selben Ergebnis kommt. Das ist der Mechanismus hinter dem Benchmark: Bei Arbeit, die stark auf das Thinking-Budget setzt, ist 3.6 bei gleichem Ergebnis tatsächlich effizienter.

Bei agentischem Traffic über mehrere Turns kippt das Vorzeichen: 3.6 verbrauchte über die Suite hinweg rund 9 % mehr Output als 3.5. Der Effizienzgewinn steckt in der Reasoning-Phase, und Agent-Loops geben dort anteilig weniger von ihrem Budget aus. Es gibt also weniger zu sparen, und die etwas längeren Turns von 3.6 überwiegen. In beiden Fällen sinkt die Rechnung, weil sich die beiden Effekte unterschiedlich addieren: Reasoning-lastige Aufgaben sparen sowohl an Tokens als auch an der Preissenkung von 9 $ auf 7,50 $ (−32 %), während Agent-Traffic nur am Preis spart (−6 %). Die ehrliche Zusammenfassung: “17 % weniger Output-Tokens” stimmt dort, wo das Thinking den Output dominiert, und kehrt sich dort um, wo es das nicht tut. Miss also deinen eigenen Mix, statt dich auf die Schlagzeile zu verlassen, und denk daran, dass der Regler aus dem vorigen Abschnitt das weit stärker bewegt als der Versionssprung.

Ist das 1M-Kontextfenster echt?

Ja, und es scheitert laut statt still. Wir platzierten eine Recall-Needle am Anfang von Prompts mit zunehmender Größe: Sie wurde bei 972K Input-Tokens noch korrekt abgerufen, und ein Prompt jenseits des Limits gab ein sauberes 400 input token count exceeds the maximum zurück, statt still Inhalt zu verwerfen. Das ist erwähnenswert, weil nicht jedes “1M-Kontext”-Modell am Markt das beworbene Fenster wirklich bedient. Ein Testhinweis für alle, die das nachstellen wollen: Fülle mit abwechslungsreichem, satzförmigem Füllmaterial, denn ein Prompt aus einem einzelnen wiederholten Token trieb das Modell schon weit vor dem Größenlimit in degeneriertes Kauderwelsch.

Prompt-Caching läuft automatisch und trifft die entscheidende Zahl der Spezifikation. Google dokumentiert für die Flash-Modelle ein Minimum von 4.096 Tokens für Context-Caching, und unser Sweep landete genau dort: Präfixe von etwa 2,1K oder darunter cachten nie, Hits begannen bei rund 4,1K Tokens, und jeder Hit ließ ungefähr die letzten 2,1K ungecacht, nach einer Aufwärmphase von 5 bis 8 Calls. Gecachter Input kostet 0,15 $/M, ein 10-facher Rabatt gegenüber der Frisch-Rate von 1,50 $. Das ist klar zu benennen, weil es der beruhigende Fall ist: Anders als bei manchen von uns gemessenen Modellen, deren beworbene Zahlen überzeichnen, was der Endpoint tatsächlich liefert, tun der Cache-Floor von Gemini 3.6 Flash und sein 1M-Fenster beide genau das, was die Docs sagen. Caching lohnt sich weiterhin nur bei wirklich langen, stabilen Präfixen, und beachte: Die Flash-Tiers unterstützen nur automatisches (implizites) Caching, nicht die explizite Cached-Content-API. Du kannst also kein großes Dokument manuell fixieren und unterhalb des Floors wiederverwenden.

Wo ordnet sich Gemini 3.5 Flash-Lite ein?

Flash-Lite ist die Stufe mit vorhersehbaren Kosten. Es verbraucht nie stillschweigend Reasoning-Token, also entspricht die Rechnung eins zu eins dem sichtbaren Output. Bei derselben mehrstufigen Mathematikaufgabe berechnete Flash-Lite 0,00057 $ gegenüber den 0,00368 $ des Defaults von 3.6 Flash, also etwa 6x günstiger, und es rechnete die Antwort offen aus statt in einem versteckten Reasoning-Feld. Mit 0,30 $/M Input und 2,50 $/M Output ist es der richtige Default für latenzsensible Single-Step-Arbeit mit hohem Volumen; für Aufgaben, die das per Regler zuschaltbare Reasoning brauchen, steigt man auf 3.6 Flash um. Der Tokenizer ist nicht nur über die drei neuen Modelle hinweg unverändert, sondern bis zurück zu Gemini 2.5 Flash: identische Token-Zahlen bei Englisch, Chinesisch, Japanisch, Koreanisch und Python über jede geprüfte Generation. Sprachbezogene Budgets, die für 2.5 gebaut wurden, gelten damit für 3.6 ohne neue Baseline.

FAQ

Kann man Reasoning bei Gemini 3.6 Flash komplett abschalten?

reasoning_effort: "minimal" (oder thinking_level: "minimal") drückte die Reasoning-Token in unseren Tests auf null und ist das untere Ende des Reglers; akzeptiert werden die Stufen minimal, low, medium und high. Einen separaten Zustand „disabled” gibt es nicht, und Versuche, Reasoning hart abzuschalten, werden upstream abgelehnt. Minimal ist also das Minimum, und für Single-Step-Aufgaben reicht das.

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

Weil Reasoning-Token zum vollen Output-Tarif abgerechnet werden und nicht Teil des zurückgelieferten Texts sind. Eine Antwort aus zwei Token kann Dutzende bis Tausende abgerechneter Reasoning-Token mit sich tragen; lies completion_tokens_details.reasoning_tokens aus (oder rechne total_tokens − prompt − completion nach), um die echten Output-Kosten zu sehen, und dreh den Regler herunter, wo die Aufgabe es zulässt.

Gemini 3.6 Flash oder Claude Haiku 4.5?

Beide besetzen denselben Fast-Tier-Slot zu ähnlichen Preisen, und die Aufteilung hängt vom Workload ab, nicht von einem einzelnen Sieger. Aus unserer Kostensicht ist der Thinking-Regler von 3.6 Flash der Unterschied: minimal macht es bei Single-Step-Traffic um eine Größenordnung günstiger, während sein Default Reasoning verbraucht, das Haiku 4.5 bei 1 $/5 $ nicht ausgibt. Veröffentlichte Benchmarks geben Haiku 4.5 den Vorsprung bei Coding-Tiefe und 3.6 Flash die Führung bei Mathematik und reinem Token-Preis; wähle danach, woraus dein Traffic besteht, und miss beide an deinen eigenen Aufgaben, bevor du dich festlegst.

Ist Gemini 3.6 Flash günstiger als 3.5 Flash?

Ja, in jedem gemessenen Workload, wobei das Ausmaß von der Form abhängt. Der Output sank von 9 $/M auf 7,50 $/M, und bei reasoning-lastigen kurzen Aufgaben verbrauchte 3.6 zudem weniger Output-Token, sodass die Kosten um rund 32 % fielen; bei Agent-Traffic verbrauchte es etwas mehr Token, und die Ersparnis kam allein aus der Tarifsenkung, etwa 6 %. So oder so ist es günstiger; migriere und miss deinen eigenen Mix neu. Für die Zerlegung der Kosten pro Token über Familien hinweg siehe unsere Studie zur Anatomie der Token-Nutzung.

Gemessen am 24.07.2026 mit gemini-3.6-flash, gemini-3.5-flash und gemini-3.5-flash-lite über das Synthorai-Gateway; Token-Zahlen aus Task-Matrix und Agent-Suite aus Usage-Records pro Call, Ergebnisse zum Effort-Regler aus einer gesalzenen Fünf-Task-Ablation (n=3 pro Zelle), Kontext- und Cache-Tests aus Needle-Recall und Prefix-Sweeps. Genauigkeitszahlen nutzen Aufgaben mit einer einzigen prüfbaren Antwort. Preise und Verhalten können sich ändern; prüfe gegen deine eigenen Usage-Records.

← Zurück zum Blog