Gemini 3.8 Live oder Extended Thinking in Famulor?

Google hat am 15. September 2026 zwei neue Speech-to-Speech-Modelle vorgestellt: Gemini 3.8 Live für flüssige, latenzarme Dialoge und Gemini 3.8 Live Extended Thinking für komplexere, mehrstufige Aufgaben. Seit dem Famulor-Changelog vom 17. September 2026 sind beide Modelle auch für Realtime-Assistenten in Famulor vorgesehen.

Die entscheidende Frage lautet nicht, welches Modell allgemein „besser“ ist. Sie lautet: Welche Art von Wartezeit und Fehler ist in Ihrem Anruf weniger problematisch? Für kurze Terminqualifizierung kann zusätzliches Nachdenken den Gesprächsfluss unnötig bremsen. Bei einer mehrstufigen Umbuchung mit Regeln und Tool-Aufrufen kann zu wenig Reasoning dagegen einen Prozessfehler wahrscheinlicher machen.

Das Wichtigste in Kürze

• Gemini 3.8 Live ist der Ausgangspunkt für schnelle, häufige Gesprächsschritte.
• Extended Thinking gehört in Tests mit wirklich mehrstufigen Aufgaben, nicht pauschal in jeden Anruf.
• Die Modellwahl ist laut Famulor nur mit dem Add-on Fallbacks & Guardrails sichtbar; sonst nutzt Famulor die empfohlene automatische Auswahl.
• Entscheiden Sie mit identischen Tests über den echten Telefonpfad – nicht mit Anbieter-Benchmarks allein.

Was ist neu an Gemini 3.8 Live?

In Googles Ankündigung vom 15. September 2026 werden beide Modelle als native Live-Modelle beschrieben, die Sprache direkt verarbeiten und während des Dialogs Werkzeuge asynchron ausführen können. Google positioniert die Standardvariante für Skalierung und flüssige Gespräche; Extended Thinking soll mehr Hintergrund-Reasoning für komplexe Aufgaben bereitstellen.

Die technischen Modellseiten ziehen die Grenze noch klarer:

• Gemini 3.8 Live ist Googles Standardempfehlung für latenzarme Voice-Agent-Erlebnisse ohne reasoning-bedingte Verzögerungen. Es unterstützt unter anderem asynchrone Funktionsaufrufe und interleaved reasoning.
• Gemini 3.8 Live Extended Thinking ist für komplexe, mehrstufige Aufgaben mit stärkerem Hintergrund-Reasoning gedacht. Google weist zugleich darauf hin, dass asynchrone Verarbeitung über ein scheinbares Gesprächsende hinaus weiterlaufen kann.

Diese Aussagen sind Google-Produktbeschreibungen, keine unabhängigen Leistungsnachweise für Ihren Telefon-Use-Case. Googles veröffentlichte Benchmarkwerte wurden nicht unter Ihrer Rufnummer, Ihrem Prompt, Ihren Tools oder Ihren Anruferprofilen gemessen. Deshalb sollten sie eine Testhypothese liefern, aber keine produktive Freigabe ersetzen.

Wie sind die Modelle in Famulor eingebunden?

Famulor beschreibt Realtime als Engine-Modus, in dem ein Modell zuhört und spricht. Laut aktueller Dokumentation zu Modellen und Stimmen wählt Famulor die eingesetzten Modelle standardmäßig automatisch. Nur wenn Fallbacks & Guardrails im aktiven Workspace enthalten ist, wird der kompatible Modellkatalog sichtbar und die Auswahl kann getrennt vorgenommen werden.

Für Gemini 3.8 nennt das Changelog vier praktische Punkte:

1. Beide 3.8-Live-Varianten sind Teil der Realtime-Auswahl.
2. Ohne das Add-on bleibt die automatische, von Famulor empfohlene Auswahl aktiv.
3. Extended Thinking kann bei anspruchsvolleren Fragen nützlich sein, kann sich aber langsamer anfühlen.
4. Realtime-Verbesserungen betreffen außerdem Tool-Ausführung, vollständige Wortenden und die Verarbeitung stiller Audioabschnitte.

Prüfen Sie die tatsächliche Verfügbarkeit immer im aktiven Workspace unter Settings → Plan. Dieser Beitrag verspricht weder einen bestimmten Planumfang noch eine dauerhafte Modellverfügbarkeit.

Wann ist Gemini 3.8 Live die bessere Ausgangswahl?

Beginnen Sie mit Gemini 3.8 Live, wenn der Anruf aus kurzen, häufig wiederkehrenden Entscheidungen besteht und der Gesprächsrhythmus besonders wichtig ist. Typische Beispiele sind:

• Öffnungszeiten, Status und einfache FAQ;
• Lead-Qualifizierung mit wenigen klaren Kriterien;
• Terminwünsche mit überschaubaren Pflichtangaben;
• Routing nach Anliegen, Sprache oder Standort;
• kurze Tool-Aufrufe, deren Ergebnis direkt bestätigt wird.

„Schnell“ sollte dabei nicht mit einer erfundenen Millisekunden-Grenze gleichgesetzt werden. Entscheidend ist, ob der Ablauf für Anrufende natürlich wirkt: Bestätigt der Assistent früh genug, spricht er nicht über den Menschen hinweg und bleibt nach einem Tool-Aufruf klar?

Die Standardvariante ist außerdem sinnvoll, wenn komplexe Fälle ohnehin an einen Menschen oder einen spezialisierten Assistenten übergeben werden. Dann muss nicht jeder einfache Anruf die höhere Reasoning-Tiefe tragen.

Wann lohnt sich ein Test mit Extended Thinking?

Extended Thinking verdient einen eigenen Testpfad, wenn die Aufgabe mehrere voneinander abhängige Schritte enthält und ein voreiliger Zwischenabschluss teuer oder schwer korrigierbar wäre. Beispiele:

• eine Umbuchung, bei der Verfügbarkeit, Tarifregel und Kundenvorgabe zusammenpassen müssen;
• ein Servicefall mit Diagnosefragen, Wissensabfrage und anschließendem Ticket;
• ein Rückgewinnungsangebot, das Ausschlüsse und Freigaben berücksichtigen muss;
• eine Buchung mit mehreren asynchronen Tool-Aufrufen;
• ein Prozess, in dem der Assistent Zwischenergebnisse erklären soll, während im Hintergrund weitergearbeitet wird.

Die zusätzliche Reasoning-Tiefe ist kein Freibrief für autonome Entscheidungen. Definieren Sie erlaubte Tools, Pflichtbestätigungen, Abbruchbedingungen und Übergaben weiterhin explizit. Besonders bei Zahlungen, Vertragsänderungen, medizinischen Informationen oder anderen folgenreichen Aktionen sollte eine geeignete Bestätigung beziehungsweise menschliche Freigabe Teil des Workflows bleiben.

Entscheidungsmatrix: Gesprächsfluss oder Reasoning-Tiefe?

Die Matrix ist ein Startpunkt, kein Hersteller-Ranking. Wenn Ihr Szenario in beiden Spalten landet, teilen Sie den Prozess auf: einfache Anliegen in der schnellen Route, komplexe Anliegen in einer klar abgegrenzten Route mit mehr Reasoning oder menschlicher Übergabe.

So richten Sie einen fairen A/B-Test in Famulor ein

1. Halten Sie den Gesprächsablauf konstant

Verwenden Sie für beide Varianten denselben System-Prompt, dieselben Tools, dieselben Wissensquellen, dieselbe Stimme und dieselben Testanliegen. Ändern Sie nur die Modellwahl. Sonst lässt sich eine Verbesserung nicht eindeutig zuordnen.

Die aktuelle Famulor-Übersicht der Engine-Modi erinnert an eine wichtige Grenze: Realtime hat weniger einzelne Stellschrauben als eine Pipeline aus STT, LLM und TTS. Wer eine bestimmte Marken- oder Klonstimme benötigt, sollte prüfen, ob Realtime überhaupt die passende Architektur ist. Dafür existiert bereits der separate Architektur-Guide zu Realtime und Pipeline; hier geht es ausschließlich um die Wahl innerhalb der neuen Gemini-3.8-Live-Modelle.

2. Definieren Sie einen kleinen, harten Testsatz

Testen Sie nicht nur den Idealablauf. Ein belastbarer Satz enthält mindestens:

• eine einfache Anfrage ohne Tool;
• einen erfolgreichen Tool-Aufruf;
• einen langsamen oder fehlschlagenden Tool-Aufruf;
• eine Korrektur durch den Anrufenden mitten im Prozess;
• eine mehrdeutige Angabe;
• einen Wunsch außerhalb der erlaubten Aktionen;
• eine Übergabe an einen Menschen;
• einen Wiederanruf mit ähnlichem, aber nicht identischem Anliegen.

Bewerten Sie anschließend getrennt: Aufgabenabschluss, Richtigkeit der übernommenen Daten, Tool-Sequenz, Gesprächsfluss, Umgang mit Unterbrechungen und Qualität der Übergabe. Fassen Sie diese Werte nicht vorschnell zu einer einzigen Durchschnittsnote zusammen.

3. Testen Sie über den echten Telefonpfad

Browser-Demos und Herstelleraufnahmen zeigen nicht, wie sich Ihr Assistent über Rufnummer, Netz und reale Endgeräte verhält. Führen Sie dieselben Fälle mit typischen Mobiltelefonen, Hintergrundgeräuschen, Sprechgeschwindigkeiten und Akzenten durch. Protokollieren Sie beobachtbare Fehler wie „Tool zweimal ausgelöst“, „Korrektur ignoriert“ oder „lange Stille vor Bestätigung“.

4. Legen Sie vorher Abbruch- und Freigaberegeln fest

Ein Modell darf nicht deshalb gewinnen, weil ein spektakulärer Einzelfall besonders gut klingt. Definieren Sie vor dem Test P0-Fehler, beispielsweise unbestätigte folgenschwere Aktionen, falsche Tool-Parameter, verlorene Pflichtangaben oder fehlgeschlagene Übergaben. Ein einzelner P0-Fehler sollte nicht durch flüssige Prosodie ausgeglichen werden.

Praxisbeispiel: Terminumbuchung im Servicebetrieb

Ein Servicebetrieb möchte eingehende Anrufe zur Terminumbuchung automatisieren. Der Assistent muss die Auftragsnummer aufnehmen, den bestehenden Termin finden, verfügbare Zeitfenster prüfen, die Region des Technikers beachten und den neuen Termin erst nach ausdrücklicher Bestätigung buchen.

Für den einfachen Fall – gültige Auftragsnummer, ein freies Zeitfenster, sofortige Bestätigung – ist Gemini 3.8 Live ein plausibler Ausgangspunkt. Der Dialog sollte kurz bleiben und der Tool-Aufruf direkt bestätigt werden.

Für den schwierigen Fall – mehrere Aufträge, unklare Adresse, zwei Kalenderabfragen und eine Tarifregel – testet das Team Extended Thinking. Der Assistent darf Zwischenschritte ankündigen, muss aber vor der Änderung Datum, Zeitfenster und Auftrag zusammenfassen. Wenn eine Regel nicht eindeutig geklärt werden kann, folgt eine Übergabe statt einer Vermutung.

Der Test behauptet nicht, dass Extended Thinking automatisch mehr Termine korrekt umbucht. Er prüft, ob die zusätzliche Reasoning-Architektur in diesem definierten Ablauf messbar weniger Prozessfehler erzeugt, ohne den Dialog unvertretbar zu verlangsamen.

Was signalisiert die Practitioner-Community?

Community-Signal, kein Produktbeleg: In einem Show-HN-Beitrag vom 10. September 2026 beschreiben Voice-AI-Entwickler, dass wiederholte manuelle Testanrufe und unerwartete Produktionsfälle sie zum Aufbau einer Simulationsplattform motiviert haben. Der Thread hatte zum Prüfzeitpunkt nur begrenzte Resonanz. Er beweist weder die Wirksamkeit des Projekts noch die Qualität eines Modells, stützt aber eine sinnvolle Prüffrage: Reicht ein guter Demo-Anruf, oder ist der Ablauf über viele reproduzierbare Szenarien stabil?

Diese Trennung ist bewusst: Google und Famulor belegen Produktmerkmale und Verfügbarkeit. Hacker News liefert ein Practitioner-Signal dafür, welche Betriebsfrage Entwickler beschäftigt. Es ersetzt keine offizielle Dokumentation und keinen eigenen Test.

Welche Grenzen sollten Sie vor dem Rollout festhalten?

• Keine Benchmark-Übertragung: Google-Werte sind nicht automatisch Ihre Produktionswerte.
• Keine Verfügbarkeitsgarantie: Plan, Modellkatalog und automatische Auswahl können sich ändern; prüfen Sie den aktiven Workspace.
• Keine Compliance-Automatik: Die Modellwahl schafft keine rechtliche Zulässigkeit und ersetzt keine Datenschutz-, Aufzeichnungs- oder Einwilligungsprüfung.
• Keine unbegrenzte Autonomie: Tool-Berechtigungen, Bestätigungen und Übergaben bleiben Ihre Designentscheidung.
• Kein einmaliger Test: Prompt-, Tool-, Wissens- oder Modelländerungen benötigen Regressionstests.
• Kein Ersatz für Architekturwahl: Wenn eine bestimmte TTS-Stimme, isolierte Komponenten oder andere Kontrollpunkte zwingend sind, kann Pipeline oder Half-Cascade passender sein.

Fazit: Wählen Sie nach Aufgabenprofil, nicht nach Modellnamen

Gemini 3.8 Live ist der logische Startpunkt für flüssige, häufige Realtime-Dialoge. Extended Thinking ist eine gezielte Option für Anrufe, bei denen mehrstufiges Reasoning und asynchrone Werkzeuge einen echten Prozessvorteil liefern könnten. „Mehr Denken“ ist jedoch kein universeller Qualitätsgewinn: Es muss gegen Gesprächsfluss, Fehlerarten und Eskalationsbedarf getestet werden.

Die sauberste Entscheidung entsteht aus einem kontrollierten Vergleich mit identischem Prompt, identischen Tools und reproduzierbaren Telefonfällen. Erst wenn eine Variante im eigenen Ablauf die vorher definierten Qualitätsgates erfüllt, gehört sie in den produktiven Verkehr.

Testen Sie beide Realtime-Varianten mit demselben Anrufset

Prüfen Sie in Ihrem Famulor-Workspace zunächst, ob die manuelle Modellwahl verfügbar ist. Legen Sie danach einen einfachen und einen komplexen Gesprächspfad an und vergleichen Sie beide Varianten über echte Testanrufe. Starten Sie mit Famulors Realtime-Dokumentation.

FAQ zu Gemini 3.8 Live in Famulor

Ist Gemini 3.8 Live in jedem Famulor-Workspace manuell auswählbar?

Nein. Laut Famulor ist die Modellauswahl sichtbar, wenn Fallbacks & Guardrails im aktiven Workspace enthalten ist. Ohne das Add-on verwendet Famulor die empfohlene automatische Auswahl. Prüfen Sie den aktuellen Plan im Workspace.

Ist Extended Thinking immer genauer?

Das lässt sich nicht pauschal behaupten. Google positioniert es für komplexe, mehrstufige Aufgaben. Ob es Ihren Ablauf robuster macht, muss mit identischen Szenarien, Tools und Freigabekriterien geprüft werden.

Welches Modell eignet sich für einfache Terminqualifizierung?

Gemini 3.8 Live ist der naheliegende Ausgangspunkt, wenn wenige Angaben erfasst und kurze Tool-Aufrufe bestätigt werden. Testen Sie dennoch Unterbrechungen, Korrekturen und Tool-Fehler über den echten Telefonpfad.

Wann sollte ich Extended Thinking testen?

Wenn mehrere Regeln, Abfragen oder Tools voneinander abhängen und ein falscher Zwischenentscheid schwer korrigierbar ist. Definieren Sie weiterhin klare Bestätigungen, Grenzen und Übergaben.

Ersetzt Realtime eine Pipeline aus STT, LLM und TTS?

Nicht für jeden Use Case. Realtime bietet einen integrierten Dialogpfad mit weniger einzelnen Stellschrauben. Wenn Sie Komponenten oder eine bestimmte TTS-Stimme separat kontrollieren müssen, prüfen Sie Pipeline oder Half-Cascade.

Reicht ein erfolgreicher Testanruf für den Rollout?

Nein. Nutzen Sie reproduzierbare Normal-, Fehler- und Grenzfälle, testen Sie reale Telefonbedingungen und wiederholen Sie die Suite nach relevanten Änderungen.