Gemini 3.6 Flash Migration: Fünf API-Änderungen und ein stiller Ausfall

Das Wichtigste in Kürze Die Migration auf gemini-3.6-flash oder gemini-3.5-flash-lite umfasst fünf Request-Änderungen. Vier davon geben HTTP 400 zurück, du erfährst es also sofort. Eine nicht: temperature, top_p und top_k werden jetzt akzeptiert und ignoriert. Wenn deine Pipeline auf temperature=0 für stabile Ausgaben angewiesen ist, gibt sie weiterhin 200 OK zurück, während die Garantie, auf die du gezählt hast, verschwunden ist. Behebe diese eine zuerst, dann die vier lauten.

Last verified: 2026-07-21

Wenn du in einer Konfigurationsdatei nur eine Modell-ID austauschst und erwartest, dass der Rest weiterläuft, lies den ersten Abschnitt, bevor du deployst.

Die fünf Änderungen, sortiert danach, wie du sie bemerkst

Vier dieser fünf Fehler melden sich selbst. Deine Integrationstests fangen sie ab, dein Error-Tracker alarmiert dich, du behebst sie an einem Nachmittag. Der erste ist der, der die Produktion erreicht.

Die gefährliche: temperature, top_p und top_k werden jetzt ignoriert

Lies diese Abfolge genau, denn die Reihenfolge ist für dich entscheidend. Heute ist der Parameter eine Leeroperation. Später wird er zu einem Fehler. Das bedeutet: Der Zeitraum, in dem du dich am ehesten über dein eigenes System täuschst, ist genau jetzt, während alles noch 200 zurückgibt.

Welche Pipelines ohne Fehler kaputtgehen

Eine stille Leeroperation ist nur dann gefährlich, wenn du dich auf den Parameter verlassen hast. Vier verbreitete Setups waren:

• Determinismus-Pipelines. Alles, was temperature=0 setzt, damit wiederholte Aufrufe untereinander übereinstimmen: Cache-Keys, die aus Modellausgaben gebaut werden, Deduplizierungsläufe, Klassifizierungsjobs, die eine nachgelagerte State Machine speisen. Die Einstellung ist jetzt wirkungslos, also wird die Ausgabestabilität, die sie dir erkauft hat, nicht mehr erkauft.
• Golden-File- und Snapshot-Tests. Suiten, die temperature=0 festgenagelt haben und die Modellausgabe gegen einen gespeicherten Erwartungsstring diffen. Diese fangen nach dem Modellwechsel an zu flackern, und das Flackern sieht aus wie eine Qualitätsregression des Modells, nicht wie ein Konfigurationsproblem, was dich in die falsche Debugging-Richtung schickt.
• Strukturierte Ausgaben, die durch niedrige Temperatur zusammengehalten werden. Teams, die nie strukturierte Ausgaben eingeführt und stattdessen temperature nahe null plus top_p eng gehalten haben, damit das Modell zuverlässig parsebares JSON ausgibt. Beide Regler sind jetzt gleichzeitig wirkungslos.
• Pro Route abgestimmte Konfigurationen. Produkte, die einen Kreativitäts-Slider anbieten oder „Zusammenfassen" mit einer Temperatur und „Brainstorming" mit einer anderen routen. Der Slider bewegt sich weiterhin in deiner UI. Im Modell bewegt er nichts mehr.

Keines davon erzeugt einen Stacktrace. Sie erzeugen eine Ausgabe, die sich leicht von dem unterscheidet, was du validiert hast, in einem System, das sich selbst als gesund meldet.

Auch dein Gateway warnt dich nicht

Das ist der Teil, der selbst sorgfältige Teams erwischt. Modell-Gateways veröffentlichen maschinenlesbare Metadaten, die beschreiben, welche Parameter jedes Modell unterstützt, und Tooling liest diese Metadaten, um zu entscheiden, was gesendet wird.

Was temperature ersetzt

Googles angegebener Ersatz ist kein weiterer Parameter. Es ist die System Instruction – also die Anweisung ganz am Anfang des Gesprächs, die das globale Verhalten des Modells festlegt: Schreibe das gewünschte Verhalten als Regel, die das Modell liest, statt als Sampling-Konstante.

Das ist eine echte Veränderung darin, wie du Absicht ausdrückst, also übersetze, statt zu löschen:

Wie du vor dem Deploy jede Aufrufstelle findest

Durchsuche deine Codebasis nach den Parameternamen, statt der Konfigurationsschicht zu vertrauen, denn diese Werte werden meist an mehreren Stellen von verschiedenen Leuten gesetzt:

# Gemini-native und OpenAI-kompatible Schreibweisen sowie die Konfigurationsobjekte, die sie tragen
grep -rn "temperature\|top_p\|topP\|top_k\|topK\|candidate_count\|candidateCount" \
  --include="*.py" --include="*.ts" --include="*.js" --include="*.go" --include="*.java" .

# Die Wrapper, die sie verstecken
grep -rn "generation_config\|generationConfig\|GenerateContentConfig\|thinking_budget\|thinkingBudget" .

Prüfe die Ergebnisse auch außerhalb des Anwendungscodes: YAML- und JSON-Konfiguration, Prompt-Management-Tools, Notebooks, Eval-Harnesses und jede Terraform- oder Admin-Konsole, die Modelleinstellungen speichert. Ein Regler, der vor einem halben Jahr in einem Dashboard gesetzt wurde, ist genau die Art von Sache, die ein Code-Review überlebt.

Die vier, die laut fehlschlagen

Diese sind einfacher, weil die API es dir sagt. Behebe sie in der Reihenfolge, in der deine Testsuite sie zutage fördert.

thinking_budget und thinking_level können nicht beide vorhanden sein

Zwei Defaults, die du bei der Wahl eines Werts kennen solltest, weil sie sich zwischen den beiden Modellen unterscheiden:

• gemini-3.6-flash hat den Default medium.
• gemini-3.5-flash-lite hat den Default minimal, der auf Durchsatz optimiert ist.

Du kannst einen Modell-Turn nicht mehr vorbefüllen

Beide Ziele wandern an dieselben zwei Stellen wie alles andere: eine System Instruction, die die Regel vorgibt, oder strukturierte Ausgaben, wenn du eine maschinell parsebare Form brauchst. Durchsuche deinen Code nach jedem Request-Builder, der eine finale Assistant- oder Model-Nachricht anhängt, besonders Retry- und Continuation-Logik, denn dort werden Prefills eher dynamisch erzeugt als wörtlich geschrieben.

Jede FunctionResponse braucht call_id und name

candidate_count ist weg

Vorher und nachher: ein Request, der sauber migriert

Hier ist ein Gemini-nativer Aufruf, der jedes veraltete Feld trägt, und die Version, die den Umzug überlebt.

# VORHER: funktioniert auf Modellen der 2.5-Ära, bricht auf 3.6 Flash oder verhält sich still fehlerhaft
config = {
    "temperature": 0,          # wird jetzt ignoriert, kein Fehler
    "top_p": 0.95,             # wird jetzt ignoriert, kein Fehler
    "top_k": 40,               # wird jetzt ignoriert, kein Fehler
    "candidate_count": 1,      # in Gemini 3.x nicht unterstützt
    "thinking_budget": 8192,   # 400, falls zusammen mit thinking_level gesendet
}

# NACHHER: Absicht von Sampling-Konstanten in Anweisungen verlagert
config = {
    "system_instruction": (
        "Antworte in höchstens drei Sätzen. Verwende einfache Aussagesätze. "
        "Füge keine Einleitung hinzu, wiederhole die Frage nicht und biete keine Rückfragen an. "
        "Wenn die Antwort unsicher ist, sage das in einem Satz."
    ),
    "thinking_level": "medium",
}

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EVOLINK_API_KEY"],
    base_url="https://api.evolink.ai/v1"
)

response = client.chat.completions.create(
    model="gemini-3.6-flash",
    messages=[
        {"role": "system", "content": "Antworte in höchstens drei Sätzen. Keine Einleitung."},
        {"role": "user", "content": "Fasse diesen Incident-Report zusammen."}
    ]
    # kein temperature, kein top_p: würden akzeptiert und dann stromabwärts ignoriert
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env["EVOLINK_API_KEY"],
  baseURL: "https://api.evolink.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gemini-3.6-flash",
  messages: [
    { role: "system", content: "Antworte in höchstens drei Sätzen. Keine Einleitung." },
    { role: "user", content: "Fasse diesen Incident-Report zusammen." },
  ],
  // kein temperature, kein top_p
});

console.log(response.choices[0].message.content);

Eine Migrationsreihenfolge, die den stillen Ausfall abfängt

Die Reihenfolge ist wichtig, denn die lauten Fehler sind einfach und der leise ist es nicht. Mach es in dieser Reihenfolge:

1. Zuerst inventarisieren. Führe die obigen Greps aus und liste jede Stelle auf, an der ein Sampling-Parameter gesetzt wird, einschließlich Config-Stores und Dashboards. Notiere, welches Verhalten jede einzelne geschützt hat.
2. Absicht übersetzen, nicht nur löschen. Entscheide für jede temperature, die du findest, wofür sie da war, und schreibe die äquivalente System Instruction. Löschen ohne Übersetzen ist der Weg, eine Qualitätsregression auszuliefern.
3. Die 400er beheben. Tausche thinking_budget gegen thinking_level, entferne candidate_count, entferne vorbefüllte Model-Turns, füge call_id und name zu jeder FunctionResponse hinzu.
4. Wähle bewusst ein Thinking-Level, besonders auf Flash-Lite, wo der minimal-Default für autonome mehrstufige Arbeit ungeeignet ist. Das ist auch der größte Kostenhebel der Migration: Auf unserem Aufgabenset kostete 3.6 Flash mit minimal 73.6% weniger pro Durchlauf als dasselbe Modell mit dem medium-Default, und Thinking-Tokens machten bei medium 85% der abgerechneten Ausgabe aus. Ob deine Last den Abfall übersteht, ist das, was zu testen ist, nicht ob die Ersparnis echt ist.
5. Setze deine Snapshot-Tests gegen das neue Modell neu auf, bevor du irgendetwas vergleichst. Alte Golden-Files wurden unter einem Parameter erzeugt, der nicht mehr gilt, also sind sie kein gültiger Referenzpunkt.
6. Führe deine Evals auf beiden Modellen über dasselbe Aufgabenset aus und vergleiche Ausgabeverteilungen, nicht nur Pass-Raten. Stille Verhaltensänderungen zeigen sich als Drift in Format, Länge und Ausführlichkeit, bevor sie sich als falsche Antworten zeigen.
7. Canary auf echtem Verkehr und beobachte nachgelagerte Parser, nicht nur die API-Fehlerrate. Wenn etwas leise kaputtgeht, geht es in dem Code kaputt, der die Modellausgabe konsumiert, nicht im Aufruf selbst.

Lass Googles Migrations-Skill den ersten Durchgang machen

npx skills add google-gemini/gemini-skills --skill gemini-interactions-api --global

Dann richte ihn in einem Coding-Agent auf dein Projekt:

Es lohnt sich, ihn laufen zu lassen. Er erledigt die mechanische Arbeit: veraltete Felder finden, die Request-Konstruktion umschreiben, Aufrufstellen aktualisieren, was den Großteil von Schritt 3 oben abdeckt.

Abschaltplan: wann die Entscheidung nicht mehr deine ist

Computer Use: vier offizielle Seiten, zwei Antworten

Eine Fähigkeitsfrage lässt sich derzeit nicht aus der Dokumentation klären. Ob diese Modelle Computer Use unterstützen, wird in Googles eigenem Material widersprüchlich angegeben:

• Die Gemini-API-Modelldokumentation markiert Computer Use als unterstützt (Preview) für 3.6 Flash, während die Enterprise-Plattform-Seite für dasselbe Modell es als nicht unterstützt aufführt.
• Für 3.5 Flash-Lite sagen die Modellseiten, es sei nicht unterstützt, während die Launch-Ankündigung und der Gemini 3 Entwicklerleitfaden sagen, es funktioniere.

Vier offizielle Seiten, zwei widersprüchliche Antworten, keine Möglichkeit, das durch Lesen aufzulösen. Wenn Computer Use auf deinem kritischen Pfad liegt, teste es mit deinem eigenen Konto und Endpoint, bevor du dich festlegst, und halte ein Fallback-Modell verdrahtet bereit. Dieser Abschnitt wird mit einer getesteten Antwort und dem Beobachtungsdatum aktualisiert. Jede andere Änderung in diesem Leitfaden ist konsistent dokumentiert; diese nicht.

Was das bedeutet, wenn du diese Woche einen Anbieter neu wählst

Eine Migration, die du nicht eingeplant hast, ist in deinem Sprint gelandet, und die Arbeit sind ein bis zwei Tage sorgfältiges Editieren statt eines Wochenend-Rewrites. Da du ohnehin schon jede Aufrufstelle anfasst, ist das ein natürlicher Moment, um zu betrachten, wie das Modell überhaupt zu dir gelangt.

Zwei Dinge lohnt es sich zu prüfen, während du gerade dabei bist:

• Kannst du die alten und neuen Modelle während der Umstellung nebeneinander laufen lassen? Schritt 6 oben verlangt es. Wenn dein Setup es umständlich macht, gemini-3.5-flash und gemini-3.6-flash gegen dasselbe Aufgabenset laufen zu lassen, wird diese Reibung auch bei der nächsten Migration da sein, und es wird eine nächste geben: Google hat gesagt, dass diese Regeln für jedes von nun an veröffentlichte Modell gelten.
• Wie schnell wird ein neues Modell für dich aufrufbar? gemini-3.6-flash erreichte am ersten Tag allgemeine Verfügbarkeit ohne Preview-Suffix. Die Lücke zwischen dem Erscheinen eines Modells und dem Moment, in dem dein Code es aufrufen kann, ist ein Preis, den du bei jedem Launch zahlst.

Häufige Fragen

Quellen

• Using the latest Gemini models (Google AI for Developers): veraltete Sampling-Parameter, thinking_level, candidate_count, Prefill-Einschränkung, FunctionResponse-Anforderungen, Migrations-Skill-Befehl
• Gemini deprecations (Google AI for Developers): Abschaltdaten und empfohlene Ersätze
• Gemini API models (Google AI for Developers): Modell-IDs, Fähigkeits-Support-Matrix
• Gemini 3 Entwicklerleitfaden (Google AI for Developers): Gemini 3 Request-Verhalten und Fähigkeiten
• Gemini 3.6 Flash auf der Gemini Enterprise Agent Platform (Google Cloud): Enterprise-Fähigkeitsliste und die auf der Seite angezeigten Parameter-Defaults
• Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber (Google): Launch-Ankündigung und Veröffentlichungsdatum
• google-gemini/gemini-skills (GitHub): der offizielle Migrations-Skill
• OpenRouter Models-Endpoint (OpenRouter): Gateway-Metadaten, die temperature, top_p und seed weiterhin als unterstützte Parameter für beide Modelle listen, beobachtet 2026-07-21
• EvoLink Modellkatalog, Gemini 3.6 Flash Release-Tracker, Vergleich 3.6 Flash und 3.5 Flash, Migrationsleitfaden Gemini 3.5 Flash gegen Gemini 3 Flash Preview, Gemini 3 Pro Deprecation-Leitfaden, EvoLink API-Basis-URL