> ## Documentation Index
> Fetch the complete documentation index at: https://docs.famulor.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Engine modes

> Pipeline, realtime, and half-cascade — how your assistant hears and speaks

The **mode** setting controls the audio architecture of the assistant. All three modes work with prompts and flows alike.

## Pipeline (default)

Classic three-stage architecture: **speech-to-text → LLM → text-to-speech**. Choose each stage from the models available to your workspace.

* Full control: pick STT, LLM, and TTS independently, including fallback chains per stage.
* Widest model and voice selection, best multilingual coverage.
* Turn detection via a semantic turn model or voice-activity detection (configurable).

**Use it when** you want maximum control over quality, cost, and language behavior. This is the right default for production telephony.

## Realtime

A single **speech-to-speech** model listens and speaks directly — no separate STT or TTS.

* Lowest latency and very natural prosody (laughter, hesitation, tone).
* Voice selection comes from the realtime model.
* Turn detection can be robust, semantic, or adaptive when the selected voice mode supports it. Other voice modes manage turn timing automatically.
* Fewer knobs: voice library and per-stage fallbacks do not apply.

**Use it when** conversational feel matters more than fine-grained control — demos, concierge experiences, voice-first products.

## Half-cascade

A hybrid: a realtime model does the **listening and thinking** (text-only), while a separate **TTS voice** does the speaking.

Half-cascade has its own text-capable realtime model selection, independent of
the full realtime selection. Changing it never changes the separate TTS voice.

* Realtime-grade understanding and turn taking, combined with your chosen TTS voice — including cloned or brand voices.
* Output voice is configured exactly like in pipeline mode.

**Use it when** you want realtime responsiveness but need a specific voice the realtime model doesn't offer.

## Realtime turn detection

For compatible realtime and half-cascade assistants, choose how the assistant decides that the caller has finished speaking:

* **Robust (VAD)** — responds after a clear pause. Fast and predictable.
* **Semantic** — waits until the caller seems to have completed their thought, even with a mid-sentence pause. **Response eagerness** controls how soon it answers.
* **Adaptive** — short acknowledgements such as "mhm" or "okay" do not stop the assistant, while a clear interruption lets the caller take over. You can also tune minimum silence, voice sensitivity, interruption duration, or disable interruptions.

Assistants that do not expose these choices continue to manage turn timing automatically. Existing assistants remain on **Robust (VAD)** until you select another mode.

## Reliability behavior

<Note>
  If the selected realtime or half-cascade setup is temporarily unavailable, the assistant uses a compatible fallback when possible so the live call can continue.
</Note>

## Quick comparison

|                        | Pipeline              | Realtime                 | Half-cascade                |
| ---------------------- | --------------------- | ------------------------ | --------------------------- |
| Latency                | Low                   | Lowest                   | Low                         |
| Voice selection        | Full library + clones | Model-native voices      | Full library + clones       |
| Per-stage fallbacks    | Yes                   | —                        | TTS side only               |
| Multilingual switching | Yes                   | Model-dependent          | Yes (output)                |
| Best for               | Production telephony  | Natural-feel experiences | Realtime feel + brand voice |

## Troubleshooting

### Losing context mid-call

The assistant asks for information already given, or seems to miss something said earlier. This is a comprehension issue, not an engine-mode dial. Keep the facts it needs in the [knowledge base](/assistants/knowledge-base) rather than only in the prompt, and in a flow, use `collect` nodes so captured answers become [call variables](/assistants/variables) the rest of the flow can reference instead of asking again. If your plan lets you pick the [language model](/assistants/models-and-voices) yourself, a stronger one also holds a long conversation together more reliably.

### Unnatural conversation flow

Awkward pauses, the assistant talking over the caller, or the exchange feeling robotic. Try Realtime or half-cascade for more natural prosody and turn-taking, tune [interruption handling and filler phrases](/assistants/conversation-quality) so waits get bridged instead of going silent, and revisit the turn-detection mode above if the assistant answers too early or too late.

### Repetitive responses

The assistant reuses the same phrasing or confirmation across a call. This comes from the prompt, not the engine mode — add an explicit instruction such as "vary your phrasing, don't repeat the same sentence twice" and test a few different conversation paths to see where it recurs.

<Tip>
  As a starting point: **Realtime** for fast sales or qualification calls, **Pipeline** for support and detailed troubleshooting, **Pipeline with a flow** for lead qualification that needs structured data capture.
</Tip>