Compare Modular and Realtime
Modular and Realtime can run the same business workflow, but they process a conversation differently. Choose the architecture before optimizing the model, voice, or prompt.
How each pipeline works
Modular
Caller audio → speech-to-text → text LLM → text-to-speech → caller audio
Each stage is selected or controlled separately. The language model receives a text transcript and streams a text response. Wirevox sends completed response segments to the configured speech provider.
This separation allows a model from one provider to be combined with a voice from another supported provider.
Realtime
Caller audio → provider realtime session → caller audio
The selected Realtime provider owns speech recognition, model inference, voice generation, and voice-activity detection inside one session. Wirevox still compiles the prompt, supplies available actions, manages call lifecycle behavior, and records the conversation.
Direct comparison
| Area | Modular | Realtime |
|---|---|---|
| Speech path | Separate STT, text model, and TTS stages. | One provider speech-to-speech session. |
| Model providers | OpenAI, Grok, and Gemini. | OpenAI Realtime, Grok Realtime, and Gemini Live. |
| Voice selection | Choose a supported modular voice independently from the LLM. | Choose a voice compatible with the realtime model's provider. |
| Secondary language and voice | Supported when configured with compatible recognition and voices. | Not currently executed; one provider voice is used for the session. |
| STT provider | Selectable. | Owned by the realtime provider. |
| Interruption word threshold | Executed by Wirevox. | Not used; interruption events are provider-native. |
| Filler-word filtering | Executed by Wirevox. | Not used by the realtime pipeline. |
| Turn-taking control | Uses modular STT patience rather than realtime VAD presets. | Responsive, Balanced, or Patient maps to provider VAD behavior. |
| Silence prompt | Wirevox lifecycle timer. | Native for OpenAI and Grok; Wirevox-managed for Gemini Live. |
| Knowledge and functions | Supported through the Wirevox runtime. | Supported through the Wirevox runtime and provider session. |
| Cost display | Combined estimate for platform, STT, LLM, and TTS. | Realtime pipeline estimate plus applicable platform costs. |
When Modular is usually the better starting point
Choose Modular when the workflow requires one or more of the following:
- a voice provider independent from the language-model provider;
- a separate secondary language and voice;
- selectable speech recognition;
- a configurable word threshold for interruptions;
- filler-word filtering; or
- controlled comparison of STT, LLM, and TTS costs.
Modular also makes it easier to isolate a failure. For example, you can determine whether a recognition error came from STT, an incorrect answer came from the LLM, or pronunciation came from TTS.
When Realtime is usually the better starting point
Choose Realtime when the workflow prioritizes:
- native speech-to-speech interaction;
- provider-managed voice activity and interruption handling;
- one model and voice provider for the live session; or
- realtime voice behavior that should be evaluated as a single system.
Realtime does not automatically mean that every call will be faster or better. Network conditions, model choice, prompt complexity, action use, caller speech, and provider behavior all affect the experience.
Controls shared by both architectures
Both architectures support the main Wirevox agent policy and lifecycle controls, including:
- system prompt and optional custom greeting;
- primary language and compatible primary voice;
- speaking-speed behavior where supported;
- silence and auto-hangup lifecycle;
- maximum call duration;
- attached knowledge base and retrieval threshold;
- during-call functions and post-call behavior; and
- audio environment.
The executor can differ. A control may be native to the provider, enforced by Wirevox, or expressed as model guidance. Review configuration compatibility before relying on a specific behavior.
What happens when you switch
In Configuration → Pipeline Architecture, selecting the other architecture activates its saved model and voice pair. When the new realtime model belongs to a different provider, the editor selects a compatible default realtime voice for that provider.
Settings from the inactive architecture can remain in the draft but are not necessarily executed. For example:
- a secondary language and voice remain stored but are inactive in Realtime;
- modular STT patience does not control Realtime turn-taking;
- interruption word count and filler filtering do not run in Realtime; and
- Realtime turn-taking presets do not control Modular STT.
The editor and publish validation can show informational or blocking diagnostics for unsupported combinations.
Migration checklist
When moving an agent between architectures:
- Select the architecture and intended model.
- Confirm that the voice remains compatible and sounds appropriate.
- Review language and secondary-language behavior.
- Review interruption, turn-taking, silence, and speaking-speed controls.
- Rewrite only prompt instructions that assume the old speech path.
- Check the draft cost breakdown.
- Test recognition, interruptions, silence, actions, and failure handling.
- Publish a new version; switching the draft alone does not change live calls.