Thanks — I can see you’re hitting an APITimeoutError when the Google Cloud TTS plugin attempts to synthesize speech. I’ll help you diagnose and resolve it. I’ll first summarize what the trace shows, then suggest targeted checks and next steps. If you can share a couple quick details, I can give more specific guidance. Acknowledgement of the error • The agent raises:

livekit.agents._exceptions.APITimeoutError: Request timed out. (body=None, retryable=True)

. • The failure happens in the Google TTS plugin during streaming (

_run_stream

→

_run_segments

) and the agent already attempted a retry (

"attempt": 1

). What this usually means • The agent did not get a timely response from Google Cloud TTS. Common causes are network latency or routing to the TTS endpoint, large payloads, credentials/quota issues, or host-side throttling (CPU/IO). Please confirm these two quick details so I can narrow the advice: 1. Where is the agent deployed? (self-hosted, LiveKit Cloud, AWS region and instance type, GCP region, etc.) 2. How are you authenticating Google TTS? (

GOOGLE_APPLICATION_CREDENTIALS

file,

credentials_info

, or other) and whether you’ve recently hit quota limits. Immediate checks you can run now 1. Verify credentials and quota ◦ Confirm the service account key is valid and has the TTS role. Test with: ▪︎

gcloud auth application-default print-access-token

(to ensure credentials are valid). ▪︎ Make a one-off TTS request from the same host (curl or a small script) to see if the request times out outside the agent. 1. Test network / region proximity ◦ Ensure your agent is in a region close to the Google TTS endpoint you call. Cross-region traffic can add latency and timeouts. ◦ If self-hosted on AWS, check whether the agent and GCP endpoint are in geographically close regions. 1. Reduce TTS payload size ◦ Break large text into sentences/chunks and synthesize each chunk (shorter requests are less likely to time out). 1. Inspect host resource limits ◦ If on burstable AWS instances (t3/t4), confirm CPU credits are available. Throttling can cause long delays even at low apparent CPU usage. 1. Check logs for repeated retries ◦ Look for multiple

"attempt": n

entries. If attempts keep increasing, it’s persistent and not a single transient failure. 1. Enable more detailed debug logging ◦ Turn on debug-level logs in the agent to capture request/response timing around the TTS calls. Tuning options and alternatives • Increase or wrap a custom retry/timeout if you need more resilience. Adding a small exponential-backoff retry wrapper around TTS calls can help for transient network blips. • Consider using LiveKit Inference-hosted TTS models (for example

tts="cartesia/sonic-3"

or

tts="elevenlabs/model"

) to avoid external API timeouts and credential issues. If you want, I can provide: • A short example retry wrapper (Python) to add around the TTS call. • A small test curl/python snippet to test Google TTS from your host. • Advice tuned to your deployment (tell me your environment and auth method). Which of these would you like next, and can you share the deployment environment and authentication method? Sources: How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit | Google Cloud TTS integration guide | LiveKit Documentation | Live Conversations with AI using ChatGPT and WebRTC | server-sdk-go | livekit/livekit_composite | DeepWiki | Troubleshooting Latency and Timeout Errors with Turn Detection on AWS