Gemini 3.7 Flash: Aufgaben kosten 2,5- bis 8-mal weniger

Gemini 3.7 Flash rechnet dieselben Aufgaben 2,5- bis 8-mal günstiger ab als Gemini 3.6 Flash. Nur die Hälfte dieser Ersparnis stammt aus der angekündigten Preissenkung. Der Einführungspreis von $0.75 pro Million Input-Token und $3.75 pro Million Output-Token liegt 50 % unter dem von 3.6. Auf unserem Zähler kostete derselbe Prompt mit 6,9K Token exakt die Hälfte ($0.00529 statt $0.01057). Der zweite Effekt fällt weniger auf: gemini-3.7-flash verbrauchte bei denselben vier Testaufgaben 26 % bis 77 % weniger Thinking-Token als 3.6. Wir haben das Modell am zweiten Tag nach dem Release untersucht: Preise, Thinking-Regler inklusive einer weggefallenen Stufe, die von Google dokumentierten und unterschätzten Kompatibilitätsbrüche sowie Cache, Kontext und Tokenizer-Kontinuität.

TL;DR

• Der Einführungspreis von $0.75/$3.75 gilt bis zum 31. Dezember 2026, danach werden $1.50/$7.50 fällig. Derselbe Prompt kostete auf unserem Zähler exakt halb so viel wie bei 3.6.
• Das standardmäßige Thinking sank gegenüber 3.6 um 26–77 % (144 statt 384 Token bei einer Aufgabe mit 5 Schritten). Die Kosten pro Aufgabe fallen damit um den Faktor 2,5 bis 8, nicht nur um den Faktor 2.
• Der Off-Schalter ist weg: Jede Schreibweise für „aus“ liefert einen 400-Fehler (“Thinking level is unsupported”); low ist jetzt die niedrigste Stufe.
• In einem Tool-Loop mit zwei Turns halbierte 3.7 die Überlegung im Turn mit dem Tool-Ergebnis (32 statt 61 Token). Die Ablehnung einer nicht beantwortbaren Frage kostete bei beiden Modellen 500.

Was kostet Gemini 3.7 Flash tatsächlich?

Bis zum 31. Dezember 2026 halb so viel wie 3.6 und bei jeder von uns gemessenen Aufgabe weniger als die Hälfte der Token. Google setzt den Einführungspreis auf $0.75 pro Million Input-Token und $3.75 pro Million Output-Token. Ab dem 1. Januar 2027 steigt er wieder auf $1.50/$7.50 und entspricht damit exakt dem Preis von 3.6. Cache-Reads kosten $0.075 pro Million, also 10 % des Einführungspreises für Input. Unsere Messung bestätigt die Preisliste: Derselbe Prompt mit 6,9K Token kostete bei 3.7 $0.0052875 und bei 3.6 $0.0105675, also genau die Hälfte.

Noch stärker wirkt sich aus, was das Modell nicht mehr verbraucht. Identische Aufgaben mit Salt, jeweils drei Durchläufe, Median der Reasoning-Token und daraus resultierende Output-Kosten:

Google schreibt zum Launch, dass 3.7 „sorgfältiger denkt“. In unseren Aufgaben bedeutet das weniger Token, nicht mehr. Beide Modelle lösten alle Aufgaben in 3/3 Durchläufen korrekt. Der halbierte Preis und das mindestens halbierte Thinking ergeben zusammen 61–88 % niedrigere Kosten pro Aufgabe, noch vor Caching. Der einzige Haken ist das Datum: Budgets sollten mit der Preiserhöhung am 1. Januar kalkuliert werden, analog zum Einführungspreis von Sonnet 5.

Ein Aufgabentyp widersetzt sich diesem Trend und taucht in kaum einer Budgetplanung auf: die Ablehnung. Wir fragten nach fünf erfundenen Entitäten, darunter ein Unternehmen, ein Institut, eine Gemeindeordnung, eine Legierung und eine Auszeichnung. Beide Modelle lehnten alle fünf Fragen ab und verbrauchten dabei mehr Thinking als bei jeder anderen gemessenen Aufgabe. Der Median lag bei 511 Reasoning-Token für 3.7 und 494 für 3.6. Die Aussage „Dazu gibt es keine Aufzeichnungen“ kostete 3,5-mal so viel Thinking wie die Rechenkette mit 5 Schritten. Retrieval-Augmented-Pipelines mit häufig fehlenden Daten zahlen diesen Aufschlag bei jedem Fehlschlag. Hier verschwindet der Effizienzvorteil von 3.7. Die Messung ordnet auch eine Sorge aus der Release-Woche ein: Reviewer berichteten von einer höheren Halluzinationsrate bei 3.7. Bei Fragen zu erfundenen Entitäten äußerte das Modell jedoch in 5 von 5 Fällen Vorbehalte, genau wie 3.6.

Welche Thinking-Einstellungen funktionieren bei 3.7 noch?

Drei Stufen, kein Off: low, medium als Standard und high, genau wie dokumentiert. Die Dokumentation sagt nicht ausdrücklich, dass die Auswege von 3.6 nicht mehr funktionieren. Alle von uns gesendeten Varianten zum Abschalten, reasoning_effort: "none", "minimal", thinking_budget: 0, thinking: {"type": "disabled"}, enable_thinking: false, lieferten denselben Upstream-400: “Thinking level is unsupported: THINKING_LEVEL_MINIMAL”. Ein zweiter, unabhängiger Request-Pfad formuliert es noch klarer: “Reasoning is mandatory for this endpoint and cannot be disabled”. Das Verhalten kommt also vom Modell und nicht von der Übersetzungsschicht eines Clients. Bei 3.6-flash, im selben Batch gemessen, reduzieren none und minimal den Verbrauch weiterhin auf null. Die Flash-Reihe folgt damit der Regel des Pro-Tiers: Thinking lässt sich nicht abschalten, und 3.6 ist nun das letzte Flash-Modell, bei dem das noch möglich ist.

Der verbleibende Regler bei der Aufgabe mit 5 Schritten (Median aus 3 Durchläufen, alle 3/3 korrekt):

Zwei praktische Hinweise. Die Angabe, dass medium der Standard ist, bestätigt sich: Nicht konfigurierte Durchläufe in der Testmatrix verbrauchten 154 Token und lagen damit praktisch gleichauf mit den 147 Token bei explizitem medium. thinking_budget ist tatsächlich veraltet: Jeder von uns getestete Wert ungleich null, von 16 bis 1.024, wurde akzeptiert und führte zum gleichen Verbrauch von 135–138 Token. Der Parameter hat keine Wirkung. Bei 3.6 schalten kleine Budgets das Thinking weiterhin ab, größere setzen eine Obergrenze. Wer bei einer 3.6-Integration die Kosten über Budgets steuert, muss für 3.7 nur noch eine Stufe wählen. Weitere Hersteller und Regler vergleicht unsere Matrix der Thinking-Einstellungen.

Was kostet der Agentenbetrieb pro Schritt?

Die Tool-Auswahl ist gegenüber 3.6 unverändert. Günstiger wurde die Überlegung zwischen den Schritten. Wir haben einen Loop mit zwei Turns und zwei Funktionen ausgeführt: Zuerst wird ein Incident abgerufen, danach der darin genannte Service neu gestartet. Pro Modell liefen drei Durchgänge:

Beide Modelle wählten in 3/3 Durchläufen zuerst get_incident und danach restart_service, bei identischer Zahl an Prompt-Token. Der Unterschied entsteht im zweiten Turn: 3.7 denkt etwa halb so lange nach, bevor es den nächsten Aufruf ausführt. Genau diesen Schritt wiederholt ein Agent. Ein Loop mit 20 Schritten kostet bei diesen Medianwerten ungefähr $0.0043 an Output mit 3.7 gegenüber $0.0131 mit 3.6. Das Verhältnis bleibt auch nach der Preiserhöhung im Januar bestehen, weil es durch die Tokenzahl und nicht durch den Preis entsteht. Deshalb kann Google den Sprung bei Agenten-Benchmarks als Kostenvorteil darstellen: weniger Deliberation-Token pro Schritt, multipliziert mit vielen Schritten.

Wie das Modell gegenüber Konkurrenten abschneidet, hängt vom Benchmark ab und sollte vor der Umstellung eines Coding-Agenten geprüft werden. Unabhängige Vergleiche sehen 3.7 Flash bei FrontierCode vorn (43,6 % gegenüber 42,7 % für Sonnet 5) und bei AutomationBench fast dreimal so stark wie Sonnet 5. Laut demselben Vergleich und der Berichterstattung aus der Release-Woche führt GPT-5.6 Terra bei Terminal-bench, während Sonnet 5 beim Desktop-Task-Test vorn liegt. Beim niedrigsten Preis ist 3.7 dagegen eindeutig überlegen.

Was bricht beim Upgrade von 3.6?

Zwei Änderungen führen sicher zu einem 400-Fehler, mehrere weitere scheitern unauffälliger, als es die Dokumentation vermuten lässt. Laut Googles Migrationshinweis müssen temperature, top_p, top_k, candidate_count und vorbefüllte Model-Turns entfernt werden. Unsere Messungen:

Das Verhalten ist nicht einheitlich: Der Thinking-Regler wird strikt validiert, und eine nicht unterstützte Stufe liefert einen klaren 400-Fehler mit dem betreffenden Wert. Sampling-Parameter und Output-Limits werden dagegen unabhängig vom gesendeten Wert geschluckt. Setzt eine Client-Library standardmäßig temperature, funktioniert sie aktuell weiter. Befüllt sie Assistant-Turns für gelenkte Ausgaben vor, war sie schon vor dem Upgrade defekt.

Bleiben Cache, Kontext und Tokenizer kompatibel?

Ja, allerdings mit einer Verzögerung. Der implizite Cache trifft bei derselben Struktur wie unter 3.6: Beim zweiten Aufruf eines identischen Prompts kamen 4.076 von 6.905 Token aus dem Cache, wodurch die Kosten des Aufrufs um 52 % sanken. Reads kosten 10 % des Einführungspreises für Input. Der Cache-Aufbau dauerte jedoch länger: Bei 3.6 gab es 4 Sekunden nach dem ersten Aufruf einen Treffer. 3.7 lieferte nach 4 Sekunden noch keinen Treffer, nach 30 Sekunden dagegen schon. Schnell aufeinanderfolgende identische Requests kommen an, bevor der Cache bereit ist. Die Kosten auf der Schreibseite bleiben ansonsten unverändert.

Ein Aufruf mit 708.912 Input-Token wurde akzeptiert und die Needle-Frage korrekt beantwortet. Das entspricht der Angabe von 1M Kontext; eine separate Preisstufe für langen Kontext gibt es in der Preisliste nicht. Der Text-Tokenizer ist über vier Generationen byte-identisch: gemini-3.1-pro-preview, 3.5-flash, 3.6 und 3.7 zählten denselben gemischten Korpus aus Englisch, Chinesisch und Code mit jeweils 50 Token. Token-Budgets lassen sich daher unverändert übernehmen. Bild-Inputs werden weiterhin mit pauschal 1.089 Token bei jeder Größe abgerechnet, wie bei allen von uns gemessenen Gemini-Modellen. Keine der beiden Generationen gibt ihren Reasoning-Text zurück: reasoning_content war bei jedem Aufruf leer. Das bezahlte Thinking bleibt bei beiden unsichtbar, ein wiederkehrender Kritikpunkt in Diskussionen aus der Release-Woche. Structured Output funktioniert: Ein striktes json_schema lieferte in 3/3 Durchläufen gültiges und korrektes JSON. Mit reasoning_effort: "low" sank das Thinking bei der Extraktion auf null, derselbe sichere Bereich für Aufgaben mit nur einem Schritt, den unsere Regler-Matrix überall zeigte.

FAQ

Wie viel kostet die Gemini 3.7 Flash API?

Der Einführungspreis beträgt bis zum 31. Dezember 2026 $0.75 pro Million Input-Token und $3.75 pro Million Output-Token. Ab dem 1. Januar 2027 steigt er auf $1.50/$7.50 und entspricht damit dem Preis von Gemini 3.6 Flash. Cache-Reads kosten $0.075 pro Million. Bei identischen Prompts berechnete unser Zähler für 3.7 exakt die Hälfte des Preises von 3.6.

Lässt sich Thinking bei Gemini 3.7 Flash abschalten?

Nein. Jede Schreibweise für „aus“ liefert einen 400-Fehler (“Thinking level is unsupported”). Der Regler bietet low, medium als Standard und high. Selbst low verbrauchte bei unserer Aufgabe mit 5 Schritten noch 133 Reasoning-Token. Gemini 3.6 Flash ist das neueste Flash-Modell, bei dem reasoning_effort: "none" funktioniert, zum Preis von 3.7 nach Ablauf des Einführungspreises.

Ist Gemini 3.7 Flash pro Request tatsächlich günstiger als 3.6?

Der Vorteil ist größer als die beworbenen 50 %: Das Modell denkt bei denselben Aufgaben zusätzlich 26–77 % weniger. Unsere gemessenen Kosten pro Aufgabe sanken damit um 61–88 %; eine Textaufgabe mit 2 Schritten fiel von $0.0020 auf $0.0002. Nach dem 31. Dezember steigt der Preis wieder auf das gleiche Niveau, sodass nur die Ersparnis beim Thinking bleibt.

Läuft Code für Gemini 3.6 Flash auch mit 3.7?

Größtenteils. Sampling-Parameter (temperature, top_p, top_k) werden trotz der Streichliste in der Dokumentation weiterhin akzeptiert. Zu hohe Werte für max_tokens werden stillschweigend begrenzt. Zwei Änderungen führen sicher zu Fehlern: Vorbefüllte Assistant-Turns liefern einen 400-Fehler, wie bereits bei 3.6, und jeder Off-Schalter für Thinking führt jetzt ebenfalls zu einem 400. Die Kostensteuerung muss deshalb von thinking_budget auf die drei Stufen umgestellt werden.

Gemessen am 2026-08-15 über das Synthorai-Gateway, zwei Tage nach Release: Matrix aus Thinking-Stufen und Off-Schaltern (7 Effort-Werte, 5 Budgets, 2 Off-Parameter, n=3; gemini-3.6-flash wurde für jeden Vergleich im selben Batch erneut ausgeführt), Messreihe zur Reasoning-Last mit vier Aufgaben, Structured Output mit striktem JSON, Tests veralteter Parameter, Akzeptanz des Output-Limits und eines Kontexts mit 708K Token, Paare für implizites Caching mit zwei Wartezeiten, Tokenizer-Vergleich mit festem Korpus über vier Gemini-Generationen, Function-Calling-Loop mit zwei Turns (n=3 pro Modell) und Ablehnungstest mit fünf Fragen zu erfundenen Entitäten. Die Kosten pro Aufgabe ergeben sich aus den gemessenen Completion-Token und dem aktuellen Output-Preis des jeweiligen Modells. Zwei Aussagen wurden über einen zweiten, unabhängigen Request-Pfad gegengeprüft: die Akzeptanz überhöhter max_tokens-Werte und das Fehlen einer Off-Stufe. Einführungspreis und Daten stammen aus Googles veröffentlichten Konditionen. Das Verhalten kann sich im weiteren Rollout ändern.

← Zurück zum Blog