Gemini 3.8 Live or Extended Thinking in Famulor?

On September 15, 2026, Google introduced two new speech-to-speech models: Gemini 3.8 Live for fluid, low-latency dialogue and Gemini 3.8 Live Extended Thinking for more complex, multi-step tasks. According to the Famulor changelog dated September 17, 2026, both models are now part of Famulor's Realtime model selection.

The useful question is not which model is universally “better.” It is: Which kind of delay and failure is less acceptable in your call? Extra reasoning may unnecessarily slow a short appointment qualification flow. In a multi-step rescheduling process with rules and tool calls, too little reasoning may make process errors more likely.

Key takeaways

• Gemini 3.8 Live is the starting point for fast, frequent conversation steps.
• Extended Thinking belongs in tests with genuinely multi-step tasks, not in every call by default.
• Famulor says manual model selection is visible with the Fallbacks & Guardrails add-on; otherwise Famulor uses its recommended automatic selection.
• Decide with identical tests over the real phone path, not provider benchmarks alone.

What is new in Gemini 3.8 Live?

Google's September 15, 2026 announcement describes both as native Live models that process speech directly and can execute tools asynchronously while the conversation continues. Google positions the standard model for scale and fluid dialogue, while Extended Thinking adds more background reasoning for complex tasks.

The technical model pages draw a clearer boundary:

• Gemini 3.8 Live is Google's default recommendation for low-latency voice-agent experiences without reasoning-induced delays. It supports asynchronous function calling and interleaved reasoning.
• Gemini 3.8 Live Extended Thinking targets complex, multi-step tasks that need stronger background reasoning. Google also notes that asynchronous processing can continue after what appears to be the end of a conversational turn.

These are Google product descriptions, not independent performance evidence for your phone use case. Google's published benchmark results were not measured with your phone number, prompt, tools or caller profiles. They can shape a test hypothesis, but they should not replace a production acceptance test.

How are the models exposed in Famulor?

Famulor describes Realtime as an engine mode in which one model listens and speaks. According to the current Models & Voices documentation, Famulor selects the models used by default. A compatible model catalog becomes visible, and manual selection becomes available, when Fallbacks & Guardrails is included in the active workspace.

The Gemini 3.8 changelog entry highlights four practical points:

1. Both 3.8 Live variants are part of the Realtime selection.
2. Without the add-on, Famulor retains its recommended automatic selection.
3. Extended Thinking can help with more demanding questions but may feel slower.
4. Realtime improvements also cover tool execution, complete word endings and silent stretches of audio.

Always verify actual availability in the active workspace under Settings → Plan. This article does not promise a specific plan entitlement or permanent model availability.

When is Gemini 3.8 Live the better starting point?

Start with Gemini 3.8 Live when the call consists of short, repetitive decisions and conversational rhythm matters most. Typical examples include:

• opening hours, status checks and simple FAQs;
• lead qualification with a few clear criteria;
• appointment requests with a small set of required fields;
• routing by intent, language or location;
• short tool calls whose results can be confirmed immediately.

“Fast” should not be turned into an invented millisecond threshold. What matters is whether the experience feels natural to callers: Does the assistant acknowledge the request early enough, avoid talking over the caller and remain clear after a tool call?

The standard model is also sensible when complex cases are handed to a human or a specialized assistant. In that design, every simple call does not have to carry the cost of deeper reasoning.

When should you test Extended Thinking?

Extended Thinking deserves a separate test path when several steps depend on each other and a premature intermediate decision would be costly or difficult to correct. Examples include:

• rescheduling that combines availability, rate rules and customer constraints;
• a service case with diagnostic questions, knowledge retrieval and ticket creation;
• a win-back offer with exclusions and approval rules;
• a booking flow with several asynchronous tool calls;
• a process in which the assistant should explain progress while background work continues.

More reasoning is not permission for unlimited autonomy. Continue to define allowed tools, mandatory confirmations, stop conditions and handoffs explicitly. Payments, contract changes, medical information and other consequential actions should retain appropriate confirmation or human approval in the workflow.

Decision matrix: conversational flow or reasoning depth?

This matrix is a starting point, not a vendor ranking. If your scenario lands in both columns, split the flow: route simple requests through the fast path and complex requests through a bounded path with more reasoning or a human handoff.

How to run a fair A/B test in Famulor

1. Keep the conversation design constant

Use the same system prompt, tools, knowledge sources, voice and test intents for both variants. Change only the model selection. Otherwise, you cannot reliably attribute an improvement.

The current Famulor engine-mode overview also marks an important boundary: Realtime exposes fewer component-level controls than a pipeline composed of STT, LLM and TTS. If you need a specific brand or cloned voice, first confirm that Realtime is the right architecture. Famulor already has a separate Realtime versus pipeline architecture guide; this article focuses only on choosing between the new Gemini 3.8 Live models.

2. Define a small, demanding test suite

Do not test only the happy path. A useful suite includes at least:

• a simple request without a tool;
• a successful tool call;
• a slow or failed tool call;
• a caller correction in the middle of the process;
• an ambiguous detail;
• a request outside allowed actions;
• a human handoff;
• a repeat call with a similar but non-identical intent.

Score task completion, captured-data accuracy, tool sequence, conversational flow, interruption handling and handoff quality separately. Avoid collapsing them into a single average too early.

3. Test over the real phone path

Browser demos and provider recordings do not show how your assistant behaves across phone numbers, networks and real devices. Repeat the same cases with typical mobile phones, background noise, speaking rates and accents. Log observable failures such as “tool fired twice,” “correction ignored” or “long silence before acknowledgement.”

4. Set stop and acceptance rules in advance

A model should not win because one impressive call sounds unusually good. Define P0 failures before testing, such as unconfirmed consequential actions, wrong tool parameters, missing required data or a failed handoff. A single P0 should not be offset by fluid prosody.

Practical example: service appointment rescheduling

A service company wants to automate inbound rescheduling calls. The assistant must capture the work-order number, retrieve the existing appointment, check available slots, consider technician coverage and create the new booking only after explicit confirmation.

For the straightforward case—a valid order number, one available slot and immediate confirmation—Gemini 3.8 Live is a plausible starting point. The conversation should stay short and the tool result should be confirmed directly.

For the difficult case—multiple orders, an ambiguous address, two calendar lookups and a rate rule—the team tests Extended Thinking. The assistant can announce intermediate steps, but it must summarize the date, time window and order before making a change. If a rule cannot be resolved confidently, it hands the call over instead of guessing.

This test does not assume that Extended Thinking automatically completes more reschedules correctly. It checks whether the added reasoning architecture produces measurably fewer process failures in this defined workflow without slowing the conversation beyond an acceptable level.

What does the practitioner community signal?

Community signal, not product evidence: In a Show HN post dated September 10, 2026, voice-AI developers say repeated manual test calls and unexpected production cases motivated them to build a simulation platform. The thread had limited engagement when reviewed. It proves neither the project's effectiveness nor any model's quality, but it supports a useful testing question: Is one good demo call enough, or is the workflow stable across many reproducible scenarios?

The distinction is deliberate: Google and Famulor support claims about product features and availability. Hacker News provides a practitioner signal about an operational concern. It cannot replace official documentation or your own evaluation.

Which limits should you document before rollout?

• No benchmark transfer: Google's scores are not automatically your production results.
• No availability guarantee: Plans, catalogs and automatic selection can change; check the active workspace.
• No automatic compliance: Model choice does not establish legal permissibility or replace privacy, recording and consent reviews.
• No unlimited autonomy: Tool permissions, confirmations and handoffs remain design decisions.
• No one-time test: Changes to prompts, tools, knowledge or models require regression testing.
• No substitute for architecture selection: If a specific TTS voice or component-level control is mandatory, pipeline or half-cascade may be more suitable.

Conclusion: Choose by task profile, not model name

Gemini 3.8 Live is the logical starting point for fluid, frequent realtime conversations. Extended Thinking is a targeted option when multi-step reasoning and asynchronous tools may deliver a real process benefit. “More thinking” is not a universal quality upgrade; it must be weighed against conversational flow, failure modes and escalation needs.

The cleanest decision comes from a controlled comparison with the same prompt, tools and reproducible phone scenarios. Only a variant that passes your predefined quality gates in your own workflow should reach production traffic.

Test both Realtime variants with the same call suite

First check whether manual model selection is available in your Famulor workspace. Then build one simple and one complex path and compare both variants through real test calls. Start with Famulor's Realtime documentation.

FAQ about Gemini 3.8 Live in Famulor

Can every Famulor workspace select Gemini 3.8 Live manually?

No. Famulor says model selection is visible when Fallbacks & Guardrails is included in the active workspace. Without the add-on, Famulor uses its recommended automatic selection. Check the current plan in your workspace.

Is Extended Thinking always more accurate?

That cannot be claimed universally. Google positions it for complex, multi-step tasks. Whether it makes your workflow more reliable must be tested with identical scenarios, tools and acceptance criteria.

Which model should I use for simple appointment qualification?

Gemini 3.8 Live is the natural starting point when you capture a few fields and confirm short tool calls. Still test interruptions, corrections and tool failures over the real phone path.

When should I test Extended Thinking?

When several rules, lookups or tools depend on each other and a wrong intermediate decision would be hard to correct. Continue to define clear confirmations, boundaries and handoffs.

Does Realtime replace an STT-LLM-TTS pipeline?

Not for every use case. Realtime provides an integrated conversation path with fewer component-level controls. If you must control components or a specific TTS voice separately, evaluate pipeline or half-cascade.

Is one successful test call enough for rollout?

No. Use reproducible normal, failure and edge cases, test real phone conditions and repeat the suite after relevant changes.