give the stt ,llm, tts fall back different options code

Thanks for reaching out, Laxman. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

python

Thanks — I’ll prepare Python examples that show fallback options for STT, LLM, and TTS. A couple quick clarifying questions so the examples fit your needs: 1. Which fallback style do you want? ◦ Model-level fallback (configure

fallback

lists so the runtime tries alternatives automatically) ◦ Runtime/event-based fallback (listen for errors/events and switch programmatically) ◦ Both 1. Which providers/models should I use (or use sensible defaults)? ◦ STT examples: Deepgram, AssemblyAI, Cartesia ◦ LLM examples: OpenAI (

gpt-4.1-mini

), Google, Cerebras ◦ TTS examples: Cartesia, ElevenLabs ◦ Or say “use defaults — Deepgram, OpenAI, Cartesia” 1. Do you want a full integrated

AgentSession

example with event handlers, or short isolated snippets that only show fallback logic? 2. Any additional constraints or preferences? ◦ Real-time streaming vs batch transcription ◦ Specific language/locale ◦ Preferred TTS voice ID ◦ Latency vs cost emphasis Answer those (short replies are fine) and I’ll return ready-to-run Python code for the exact combination you choose.

Which fallback style with options base

Thanks — I want to make sure I give you exactly what you need. You said “Which fallback style with options base” — I can provide Python examples, but I need one quick clarification so I produce the right code. Which of these do you mean by “options base”? Pick one: • A. Model-level fallback using a

fallback

list on each component (the runtime automatically tries the next model). • B. Runtime/event-based fallback where you catch errors or listen to events and programmatically switch providers/models. • C. Both A and B (show both styles). • D. An “options” builder-style API (e.g.,

.with_azure()

or other chainable configuration methods) — if this, please confirm which provider(s). Also tell me: • Use defaults (Deepgram for STT, OpenAI

gpt-4.1-mini

for LLM, Cartesia for TTS) or list specific providers/models you want? • Do you want a full integrated

AgentSession

example with event handlers, or small focused snippets just showing fallback config? Reply with the letter for style (A/B/C/D) and the provider choice + snippet type (full session or snippets). I’ll return copy‑pasteable Python code right away. Sources: examples/voice_agents | livekit/livekit_composite | DeepWiki

stt, deepgram n groq , llm --> gpt 4.1 mini , llama , tts-deepgram , cartesia

Thanks — I’ll provide a full Python AgentSession example that shows model-level fallback configuration (the runtime will try the primary model first, then the fallback list) for the exact providers you listed: • STT: Deepgram (primary) with Groq as fallback • LLM: OpenAI

gpt-4.1-mini

(primary) with LLaMA as fallback • TTS: Deepgram (primary) with Cartesia as fallback Below is a copy‑pasteable Python example that configures those fallbacks and includes simple event handlers showing how to react when transcriptions arrive and when you want to synthesize speech. Adjust API keys, model IDs, and voice IDs to match your account details.

# Example: AgentSession with model-level fallback for STT, LLM, and TTS (Python)

from livekit import voice, inference  # adjust imports to your SDK package layout

# Create an AgentSession with model-level fallback lists.
# The runtime will attempt the primary model first, then try each fallback in order.
session = voice.AgentSession(
    stt=inference.STT(
        model="deepgram/rt-large",           # Primary STT (Deepgram)
        fallback=["groq/streaming-1"]        # Fallback chain (Groq)
    ),
    llm=inference.LLM(
        model="openai/gpt-4.1-mini",         # Primary LLM (OpenAI)
        fallback=["meta/llama-2-13b"]        # Fallback LLM (LLaMA)
    ),
    tts=inference.TTS(
        model="deepgram/tts-1",              # Primary TTS (Deepgram)
        fallback=["cartesia/sonic-3"],       # Fallback TTS (Cartesia)
        voice="default"                      # Replace with specific voice ID if desired
    )
)

# Basic event handlers to demonstrate usage and inspect what model handled a step.
@session.on("user_input_transcribed")
def handle_transcript(event):
    # event typically contains fields like `transcript`, `is_final`, and metadata about the model used.
    print("Transcription event:", event)
    if getattr(event, "is_final", False):
        transcript_text = event.transcript
        print("Final transcript:", transcript_text)

        # Use the LLM to generate a response (the runtime will use the primary LLM, or fallback on failure)
        response = session.generate(transcript_text)   # hypothetical synchronous helper
        print("LLM response:", response)

        # Speak the LLM response using the configured TTS chain
        session.say(response)   # runtime selects primary TTS or fallbacks if needed

@session.on("stt_error")
def handle_stt_error(event):
    # This event can help you log if the runtime attempted fallback models.
    print("STT error:", event)
    # You can inspect event details to see which model failed and whether fallback was used.

@session.on("tts_error")
def handle_tts_error(event):
    print("TTS error:", event)

@session.on("llm_error")
def handle_llm_error(event):
    print("LLM error:", event)

# Start the session (adjust call to match your SDK; may be `session.start()` or similar)
session.start()

# Example usage: feed audio or start a call/room integration that streams audio into this session.
# The runtime will attempt the primary models first and move through fallback lists if the primary fails.
# For example, if Deepgram STT is unavailable, it will attempt Groq per the `fallback` list.

# When finished:
# session.stop()

Notes and adjustments: • Replace model IDs (e.g.,

"deepgram/rt-large"

,

"groq/streaming-1"

,

"meta/llama-2-13b"

,

"deepgram/tts-1"

,

"cartesia/sonic-3"

) and

voice

values with the exact IDs from your provider accounts. • The exact method names (

session.generate

,

session.say

,

session.start

, and event names) may differ slightly depending on the SDK version in your environment. The sample shows typical patterns: configuring

fallback

lists and handling events to observe behavior. • This example demonstrates model-level fallback only: the runtime will try each model in the provided

fallback

list until a successful result is returned or the list is exhausted. • If you’d like, I can also: ◦ Provide a version that logs which model actually handled each request (useful for debugging). ◦ Add runtime/event-based fallback snippets (programmatically switching models on errors). ◦ Convert this to a minimal focused snippet for embedding into an existing app. Which of those follow-ups would you like next?