Gemini 3.8 Live ist allgemein verfügbar. Die Migration eines Sprachagenten beschränkt sich jedoch nicht auf einen neuen Modellnamen. Standardmäßig asynchrone Tools und der separate Interaktionslebenszyklus von Extended Thinking bedeuten: Eine beendete Äußerung beweist keinen abgeschlossenen Geschäftsvorgang. Trennen Sie vor der Anbindung schreibender Tools Audiowiedergabe, Modellaktivität und Backend-Transaktion. Testen Sie insbesondere, was passiert, wenn ein Nutzer nach dem Absenden einer Aktion „Stopp“ sagt.
Was sich mit Gemini 3.8 Live ändert
Am 15. September 2026 hat Google Gemini 3.8 Live und Gemini 3.8 Live Extended Thinking angekündigt. Die Release Notes der Gemini API kennzeichnen beide Audio-zu-Audio-Modelle als allgemein verfügbar. Die Ankündigung beschreibt visuellen Echtzeitkontext, Sprachwechsel und Tool-Ausführung im Hintergrund bei fortlaufendem Gespräch. Das sind vom Anbieter beschriebene Fähigkeiten, keine bestandene Produktionsabnahme für Ihren Prozess.
Die API-Kennungen lauten gemini-3.8-live und gemini-3.8-live-extended-thinking. Google positioniert das erste Modell für latenzarme Dialoge und das zweite für komplexeres Hintergrund-Reasoning. Dieser Artikel behandelt Entwicklerintegrationen. Er setzt nicht voraus, dass jedes Gemini-App- oder Workspace-Konto gleichzeitig dieselben Funktionen erhält.
Die betriebliche Änderung ist konkret: Laut Migrationsseite für 3.8 Live ist asynchrones Function Calling jetzt der Standard. Explizite BLOCKING-Deklarationen bleiben zur Kompatibilität möglich. Das unterscheidet sich vom ausschließlich sequenziellen Tool-Verhalten in der älteren Dokumentation zu 3.1 Live. Extended Thinking verlangt nicht blockierende Tools. Wenn Ihr Client Gesprächspausen bisher als groben Indikator für laufende Arbeit verwendet hat, benötigt er jetzt einen expliziten Zustandsvertrag.
Zugang, Preise und noch zu prüfende Grenzen
Der Entwicklerzugang erfolgt über die Gemini Live API; Google beschreibt außerdem die Einführung innerhalb seines Anwendungsökosystems. Die Liste verfügbarer Regionen enthält Deutschland. Länderzugang garantiert jedoch weder modellspezifische Kapazität in Ihrem Projekt noch bestimmte Enterprise-Vertragsbedingungen oder ausschließlich europäische Datenverarbeitung. Prüfen Sie Endpunkt, Kontoberechtigung, Kontingent und Datenverarbeitungsbedingungen für den tatsächlich vorgesehenen Bereitstellungsweg.
Beim direkten Abruf am 16. September 2026 führte die Preisseite der Developer API beide neuen Modelle in einem gemeinsamen Tarifabschnitt: Pro Million Token kosten Eingaben im bezahlten Tarif 0,75 US-Dollar für Text, 3,00 US-Dollar für Audio und 1,00 US-Dollar für Bild/Video. Ausgaben einschließlich Thinking-Token kosten 4,50 US-Dollar für Text und 12,00 US-Dollar für Audio. Google nennt außerdem Audioäquivalente von 0,005 US-Dollar je Eingabeminute und 0,018 US-Dollar je Ausgabeminute. Das sind Modalitätstarife, kein Festpreis pro verstrichener Gesprächsminute. Search Grounding und externe Dienste können zusätzliche Kosten verursachen. Bei der Datennutzung zur Produktverbesserung steht für den kostenlosen Tarif Ja und für den bezahlten Tarif Nein. Prüfen Sie die geltenden Bedingungen, statt einen kostenlosen Test als freigegebenen Datenverarbeitungsweg zu behandeln. Es handelt sich um gehostete Modelle, nicht um ein angekündigtes Open-Weight-Paket für den Eigenbetrieb.
Bewerten Sie die Kosten pro akzeptiertem Geschäftsergebnis einschließlich gesprochener Zwischenmeldungen, erfolgloser Sitzungen, Tool-Ausführung und menschlicher Übernahme. Eine kürzer wahrgenommene Antwortzeit kann mit einer längeren Transaktion und höheren Kosten einhergehen. Das ist eine Empfehlung für die Kostenrechnung, kein gemessener Kostenvergleich der beiden neuen Modelle.
Extended Thinking verändert die Bedeutung von „fertig“
Der Thinking-Leitfaden zur Live API unterscheidet ausdrücklich: Bei Standard-3.8-Live schließt turnComplete: true einen Turn ab. Bei Extended Thinking kann dieses Signal eine Zwischenäußerung beenden, während die Interaktion weiterhin IN_PROGRESS ist. Der Client muss interaction_status auswerten – in Protokollbeispielen als interactionStatus dargestellt – und die Gesprächsoberfläche erst bei IDLE in den Ruhezustand versetzen.
Keines dieser Signale sollte zum maßgeblichen Status Ihrer Geschäftstransaktion werden. „Ich prüfe das“ ist keine Buchungsbestätigung. Auch ein inaktives Modell ersetzt nicht den Nachweis des Zielsystems, dass eine Reservierung verbindlich gespeichert, abgelehnt oder storniert wurde. Speichern Sie eine Geschäftsvorgangskennung unabhängig von Audiositzung und Tool-Call-Kennung des Anbieters.
Eine geeignete Implementierung führt drei getrennte Zustandsnachweise. Die Wiedergabe unterscheidet gepufferte, laufende und unterbrochene Audioausgabe. Der Modellzustand folgt dem Interaktionslebenszyklus des Anbieters. Das Vorgangsprotokoll unterscheidet vorgeschlagen, wartet auf Freigabe, abgesendet, verbindlich gespeichert, Abbruch angefordert, abgebrochen und Ausgang unbekannt. Diese Vorgangszustände sind ein vorgeschlagenes Anwendungsdesign, keine Enum-Werte der Gemini API.
Beispiel: Ein Service-Desk-Assistent beginnt, einen Technikertermin zu buchen. Der Anrufer unterbricht: „Stopp, nehmen Sie den anderen Standort.“ Stoppen Sie veraltete Audioausgabe sofort. Melden Sie die Buchung aber nicht allein deshalb als storniert, weil die Generierung beendet wurde. Vor dem Absenden lässt sich der alte Vorschlag verwerfen. Danach müssen Sie das Buchungssystem abfragen, gegebenenfalls eine Stornierung anfordern und das Ergebnis dokumentieren, bevor Sie eine Ersatzbuchung vorbereiten. Andernfalls verdeckt ein flüssigeres Gespräch zwei gültige Buchungen.
Diese Migrationsdetails gehören in einen Vertragstest
Für Standard-3.8-Live verlangt Google, thinking_level beziehungsweise thinking_config wegzulassen; eine konfigurierbare Reasoning-Tiefe wird nicht unterstützt. Extended Thinking unterstützt low, medium und high, aber nicht MINIMAL. Seine Tools müssen ausdrücklich NON_BLOCKING verwenden. Laut Thinking-Leitfaden führen synchrone blockierende Deklarationen zu einem Fehler.
Die modellspezifische Migrationsseite erklärt außerdem, dass send_client_content während der gesamten Sitzung unterstützt wird und turn_complete=true die aktive Modellgenerierung unterbricht. Diese Aussage betrifft die Generierung, nicht ein dokumentiertes transaktionales Rollback Ihres externen Tools. Leiten Sie daraus keine Abbruchgarantie ab, die die Quelle nicht zusichert.
Weitere Konfigurationsänderungen sind für die Einführung relevant: Proaktives Audio ist dauerhaft aktiviert; proactive_audio: false führt zu einem Fehler. Die Konfiguration für affektiven Dialog wurde entfernt. Die standardmäßige Turn-Abdeckung berücksichtigt Videobilder; senden Sie diese nur bei Bedarf. Für Antworten verweist die Modellseite auf Audioausgabe und auf die Ausgabetranskription, falls ein Textprotokoll benötigt wird.
Die Dokumentation ist nicht vollständig synchronisiert. Einige für diese Prüfung abgerufene allgemeine Tool- und Capability-Seiten verglichen weiterhin 3.1 und 2.5 statt der neuen Modelle. Auch die neuere Modellseite und der Thinking-Leitfaden verwenden unterschiedliche Scheduling-Bezeichnungen. Kopieren Sie daher kein älteres Beispiel und raten Sie keinen Enum-Wert. Fixieren Sie die SDK-Version, prüfen Sie das tatsächliche modellspezifische Schema und sichern Sie vor dem Produktivbetrieb eine erfolgreiche Sitzungskonfiguration samt Tool-Response-Trace. Dieser Artikel behauptet keine ausgeführte Integration und keinen eigenen Benchmark.
Fünf Abnahmeprüfungen vor schreibenden Geschäftsaktionen
1. Beweisen Sie die Trennung von Äußerung und Transaktion
Erfassen Sie bei Extended Thinking eine Zwischenäußerung mit turnComplete, während die Interaktion noch läuft. Die Oberfläche darf weder „abgeschlossen“ anzeigen noch das Geschäftsticket schließen oder eine zweite widersprüchliche Schreibaktion freigeben. Als Nachweis dient eine geordnete Ereignisspur aus Anbietersignal, UI-Zustand und unverändertem Vorgangsstatus. Testen Sie das Standardmodell separat, statt ungeprüft denselben Abschluss-Handler zu verwenden.
2. Testen Sie Unterbrechungen vor und nach dem Absenden
Unterbrechen Sie vor dem Tool-Aufruf, während der Ausführung und nachdem das Backend gespeichert hat, aber bevor seine Antwort eintrifft. Fordern Sie entweder einen bestätigten Abbruch, das bestätigte gespeicherte Ergebnis oder einen ausdrücklich unbekannten Ausgang mit Übergabe an einen Menschen. Ein Stoppwunsch darf keinen erfundenen Erfolg erzeugen. Die Architektur für Freigabepunkte liefert die Autorisierungsgrenze; sie storniert nicht automatisch eine entfernte Schreibaktion.
3. Verhindern Sie eine zweite Buchung nach dem Wiederverbinden
Trennen Sie die Audiositzung nach dem Absenden und verbinden Sie sie für denselben Geschäftsvorgang erneut. Der Client muss den ersten Versuch abgleichen, bevor er einen weiteren sendet. Verwenden Sie eine stabile Idempotenzkennung, sofern die empfangende API dies unterstützt, und prüfen Sie Aufbewahrungsdauer sowie Regeln für identische Nutzdaten. Der Leitfaden zu Retry-Budgets erläutert, warum verlorene Bestätigungen einen Abgleich statt einer blinden Wiederholung verlangen. Hier prüfen Sie den neuen Sprachsitzungs-Lebenszyklus, nicht einen Ersatz für die übergreifende Retry-Regelung.
4. Trennen Sie alte Ergebnisse von neuen Anweisungen
Ändern Sie eine Adresse oder Anlagenkennung, während ein langsames Tool arbeitet. Binden Sie dessen Antwort an den Vorgang und die Eingaberevision, aus denen sie entstanden ist. Ein verspätetes Ergebnis darf weder den korrigierten Auftrag überschreiben noch unter neuer Freigabe eine Folgeaktion auslösen. Zeigen Sie dem Nutzer, was tatsächlich mit dem alten Vorgang geschehen ist. Diese Kontrolle verursacht zusätzlichen Zustands- und Koordinationsaufwand. Ein einfacherer Assistent mit rein lesendem Zugriff kann sinnvoller sein, wenn der Prozess diesen Aufwand nicht tragen kann.
5. Messen Sie wirksame Abschlüsse statt beruhigender Sprache
Prüfen Sie deutsche Äußerungen, deutsch-englische Sprachwechsel, überlappende Sprache, Hintergrundgeräusche und mehrdeutige Teilenummern gegen fachlich bewertete Ergebnisse. Messen Sie die erste hörbare Bestätigung getrennt von geprüftem Aufgabenabschluss, Abbruchergebnis und menschlicher Übernahme. Fordern Sie die vereinbarten Latenz- und Kostenbudgets, ohne Korrektheit dafür einzutauschen. Mit segmentspezifischen Release-Gates verhindern Sie, dass ein guter Durchschnitt schwache deutsche oder folgenreiche Fälle verdeckt. Leiten Sie Schwellen aus dem Geschäftsrisiko ab; einen universell sicheren Prozentsatz gibt es nicht.
Grenzen und die nächste Einführungsentscheidung
Die Benchmarkwerte der Ankündigung belegen weder Ihre Buchungsgenauigkeit noch Robustheit bei Produktionslärm oder eine sichere Abbruchrate. Die modellspezifischen Seiten nennen unter anderem keinen Structured-Output-Modus, keine integrierte Codeausführung und kein Context Caching. Function Calling benötigt weiterhin Schema-Prüfung, Autorisierung und fachliche Prüfungen in Ihrem Backend. Flüssige Sprache ersetzt diese Kontrollen nicht.
Beginnen Sie mit rein lesenden Statusabfragen. Ergänzen Sie erst nach bestandener Abnahme eine reversible, ausdrücklich freigegebene Aktion. Verwenden Sie Standard-3.8-Live, wenn direkte Dialoge und einfache Tools ausreichen. Prüfen Sie Extended Thinking, wenn die Aufgabe Hintergrund-Reasoning tatsächlich benötigt und der Client dessen Lebenszyklus darstellen kann. Keine Variante rechtfertigt unmittelbare Eingriffe in sicherheitskritische Anlagen. Fragen zu Aufzeichnung, Beschäftigtenüberwachung und Datenübermittlung gehören zu den zuständigen Datenschutz- und Rechtsverantwortlichen. Dies ist technische Orientierung, keine Rechtsberatung.
Bringen Sie zu einer Architekturprüfung Ihres Sprachagenten (englische Leistungsübersicht) einen aufgezeichneten Testablauf, den Abbruchvertrag des Tools und einen Fall mit verlorener Antwort mit. Das nützliche Ergebnis ist ein Zustandsübergangsvertrag samt Abnahmepaket, das klar trennt: Was hat der Assistent gesagt, und was hat das Geschäftssystem tatsächlich ausgeführt?
