Google hat zwei Gemini Flash API-Slugs veraltet und leitet den Datenverkehr automatisch von jedem alten Namen zu einem neueren Ersatz um, wodurch eine kleine Änderung des Modellkatalogs mit größeren Konsequenzen für Gateways, Analysen und Kundenberichte entsteht.

Laut den Gemini API-Versionshinweisen von Google vom 8. Oktober 2026 ist gemini-3.7-flash veraltet und wird durch gemini-3.8-flash ersetzt. An den veralteten 3.7 Flash-Slug gesendete Anfragen werden automatisch an 3.8 Flash weitergeleitet. Google hat auch gemini-3.5-flash als veraltet markiert und durch gemini-3.6-flash und das gleiche automatische Umleitungsverhalten ersetzt.

Das Unternehmen hat auch deep-research-pro-preview-12-2025 abgelehnt und erklärt, dass der Deep Research-Agent am 23. Oktober 2026 abgeschaltet wird, mit Migrationspfaden zu neueren Deep Research-Agenten. Das gibt den Teams ein kurzes Zeitfenster, um die Produktionsnutzung zu identifizieren, angeheftete IDs zu ändern und das Ausgabeverhalten zu überprüfen, bevor der alte Vorschau-Endpunkt verschwindet.

Was sich im Gemini API

geändert hat

Die unmittelbare betriebliche Änderung ist unkompliziert: Eine Anfrage kann ein Modell benennen, während Google ein anderes bedient. Das ist nicht dasselbe, als würde ein Entwickler eine Anwendung absichtlich von gemini-3.7-flash bis gemini-3.8-flash bearbeiten. Es handelt sich um eine anbieterseitige Substitution.

Bei einfachen Anwendungen kann der Unterschied unsichtbar sein, wenn die Antworten akzeptabel bleiben. Für Teams, die Evaluierungen, kundenorientierte Analysen, regulierte Arbeitsabläufe oder Kostenzuordnung durchführen, ist es wichtig. Ein Protokolleintrag, der nur das angeforderte Modell aufzeichnet, kann den Eindruck erwecken, als würde ein veraltetes Modell immer noch Datenverkehr verarbeiten. Ein Dashboard, das nur das bediente Modell aufzeichnet, kann die Tatsache verbergen, dass Kunden immer noch eine alte Schlampe anrufen. Beide Ansichten sind unvollständig.

Hier werden KI-Modellaliase zu mehr als nur Entwicklerfreundlichkeit. Gateways müssen mindestens drei Fälle unterscheiden: einen stabilen, von der Plattform erstellten Kundenalias, einen absichtlich schwebenden Anbieteralias und eine veraltete Route des Anbieters, die stillschweigend eine alte öffentliche Modell-ID einer neuen zuordnet. Die Behandlung aller drei als dasselbe Feld führt zu mehrdeutigen Analysen.

Warum die automatische Umleitung nützlich, aber riskant ist

Automatische Umleitung reduziert sofortige Schäden. Wenn ein Kunde gemini-3.7-flash fest codiert hat, kann die Ersatzroute von Google die Anfragen weiterführen, während das Team die Konfiguration aktualisiert. Dies ist eine praktische Wahl für die Servicekontinuität, insbesondere für Anwendungen, bei denen Modell-IDs über Skripte, Partnerintegrationen, Eingabeaufforderungen oder Kundeneinstellungen verteilt sind.

Der Kompromiss ist der Verlust der expliziten Kontrolle. Ein Modellaustausch kann Latenz, Ausgabestil, Sicherheitsverhalten, Werkzeugnutzungsmuster oder Randfallzuverlässigkeit ändern, selbst wenn der API-Aufruf immer noch erfolgreich ist. Entwickler bemerken die Änderung möglicherweise erst, wenn eine Bewertung abweicht, sich eine Eingabeaufforderung anders verhält oder ein Kunde fragt, warum die gemeldete Nutzung nicht mehr mit der Dokumentation übereinstimmt.

Das Risiko ist höher für Plattformen, die Google Modelle über ein Multimodell-APIGateway für Teams bereitstellen. Diese Produkte stehen zwischen dem Anbieter und dem Endbenutzer und müssen daher entscheiden, wie viel vom Routing-Verhalten des Anbieters ans Licht kommt. Ein Gateway, das einfach den alten Slug weiterleitet und den resultierenden Anruf wie gewohnt abrechnet, mag zwar die Kompatibilität wahren, hinterlässt aber für Support- und Finanzteams einen schwachen Prüfpfad.

Welche Gateways und Reseller-Plattformen aufzeichnen sollten

Das sauberste Muster besteht darin, das angeforderte Modell, das aufgelöste Anbietermodell und die Aliasregel, die die Auflösung verursacht hat, zu speichern. Für die Flash-Änderung Gemini bedeutet das, dass ein Nutzungsdatensatz zeigen sollte, dass der Kunde gemini-3.7-flash angefordert hat, Google gemini-3.8-flash bedient hat und der Grund die veraltete Umleitung von Google und nicht eine vom Kunden definierte Fallback-Regel war.

Diese Unterscheidung wirkt sich auf die Abrechnungsunterstützung, die Migrationsplanung und das Produktvertrauen aus. Wenn ein Kunde fragt, ob seine Anwendung immer noch ein veraltetes Modell verwendet, sollte die Antwort keine manuelle Protokollarchäologie erfordern. Wenn ein Wiederverkäufer nachgelagerte Konten benachrichtigen muss, sollte er in der Lage sein, nach angefordertem Legacy-Slug zu segmentieren. Wenn eine interne Evaluierungssuite fehlschlägt, sollten Ingenieure in der Lage sein, die Ergebnisse vor und nach der Änderung des bereitgestellten Modells zu vergleichen, ohne zu erraten, wann sich der Datenverkehr verlagert hat.

Bei Produkten im Model Gate-Stil liegt die praktische Arbeit in der Nutzungsanalyse und Kundenberichterstattung. Ein Nutzungsanalyse-Dashboard sollte vermeiden, dass das angeforderte und das bereitgestellte Modell in einem Label zusammengefasst werden. Außerdem sollten veraltete IDs so sichtbar sein, dass Kontoinhaber Migrationen vorantreiben können, bevor der Anbietersupport endet.

Die Abschaltung des Deep Research-Agenten führt zu einer zweiten Art von Frist. Im Gegensatz zu einer Flash-Umleitung sagt Google, dass deep-research-pro-preview-12-2025 am 23. Oktober 2026 heruntergefahren wird. Teams, die diesen Vorschau-Agenten verwenden, müssen migrieren, anstatt sich auf eine unbestimmte Kompatibilitätsweiterleitung zu verlassen. Da Deep Research-Workflows möglicherweise in länger laufende Forschungs- oder Automatisierungspipelines eingebettet sind, sollte die Migrationsprüfung Eingabeaufforderungen, Toolannahmen, Ausgabeformate und alle gespeicherten Modellzulassungslisten umfassen.

Was bleibt ungewiss

In den Versionshinweisen von

Google werden die veralteten Slugs, Ersetzungen und Umleitungsverhalten aufgeführt, aber sie klären nicht alle Betriebsfragen für Downstream-Plattformen. Die Hinweise bieten keinen umfassenden Verhaltensvergleich zwischen den alten und den Ersatz-Flash-Modellen im zitierten Änderungsprotokolleintrag. Sie geben auch kein Abschaltdatum für die veralteten Flash-Slugs an, wie dies für den Vorschau-Agenten von Deep Research der Fall ist.

Das stellt Teams vor ein bekanntes API-Verwaltungsproblem: Die Kompatibilität kann vorerst bestehen bleiben, aber der stabile Zustand ist immer noch die Migration. Entwickler sollten explizite Modellauswahlen aktualisieren, kritische Auswertungen anhand der Ersatz-IDs erneut durchführen und sicherstellen, dass die Protokolle genügend Details enthalten, um zu erklären, was während des Übergangs passiert ist.

Die umfassendere Lektion ist, dass Modell-IDs keine einfachen Produktnamen mehr sind. Dabei kann es sich um stabile Releases, bewegliche Aliase, Kompatibilitäts-Shims oder Deprecation-Traps handeln. Gateways, die Kunden eine zuverlässige Kontrolle ermöglichen möchten, benötigen ein Datenmodell, das diese Unterschiede direkt darstellen kann.