### Answer This matches a case seen with a custom LLM/deployment where the model provider fails to return a first token in time. In a similar Discord thread, a user hit "Failed to get response from any LLM provider: Operation timed out," and Retell staff traced it to prompt size — the call had 75k tokens total (35k of that just the system prompt) , which was double the token limit of around 32k [(1) ]() . Since your timeouts are all "3000ms timeout reached for first token" across multiple provider/model deployment fallbacks, the pattern is consistent with the model taking too long to start streaming a response, rather than a Retell-side outage. Worth checking: - Total prompt/context size for this agent — if it's pushing close to or over the token limit, generation latency (and time-to-first-token) increases significantly, as seen in the referenced case . - Whether the same issue reproduces consistently for one agent config vs. being a one-off. If you want it checked further, providing the specific call IDs would let it be traced the way it was in that Discord case, where Retell staff asked for call IDs before finding the token count issue .

​ To learn more, see the sources I considered: [[1] [CRITICAL] Inbound calls failing due to LLM timeout(Failed to get response from any LLM provider)](https://discord.com/channels/1186424376300679209/1467752537988796437) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

@AI Evy I've counted and system prompt is lenght less then 1600 token

### Answer With a system prompt under 1600 tokens, prompt size isn't the likely cause of the "3000ms timeout reached for first token" errors you're seeing. This differs from the earlier scenario referenced, where prompt size was the driver. Given the errors show multiple provider/deployment fallbacks all failing with the same first-token timeout (

llm-deployment:anthropic-default:claude-4.5-haiku

,

llm-deployment:vertex-anthropic-global:claude-4.5-haiku

,

llm-deployment:bedrock-runtime-claude-us:claude-4.5-haiku

) , this points to the underlying model provider(s) being slow or unresponsive at the time of the call, rather than something in your agent configuration. None of the information sources available to me document specific causes or fixes for first-token timeout errors when prompt size isn't the factor, so I can't give you a definitive root cause from documentation alone. To get this properly traced, sharing the specific call IDs where these errors occurred would help — that's consistent with how similar timeout issues have been diagnosed before. Check out these potentially useful sources: [Get Retell LLM]() , [LLM WebSocket]() , [Custom LLM overview]() Would you like me to give a general answer based on my own knowledge instead, beyond what's in these sources?

message has been deleted

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer None of the available sources document root causes or fixes for first-token timeout errors when prompt size isn't the driver, and none of them address why this would be isolated to a single agent specifically. Since this is agent-specific and persists after reducing the prompt, the most direct path is to get it traced by support with the specific call IDs where the errors occurred, as that's the approach used to diagnose similar timeout issues. Check out these potentially useful sources: [Get Retell LLM]() , [LLM WebSocket]() [(1) ]() , [Custom LLM overview]() [(2) ]() Would you like a general answer based on my own knowledge instead of what's documented in these sources?

​ To learn more, see the sources I considered: [[1] LLM WebSocket](https://docs.retellai.com/api-references/llm-websocket) [[2] Custom LLM overview](https://docs.retellai.com/integrate-llm/overview) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.