### Answer --- Retell does support an auto-reconnect mechanism for the custom LLM WebSocket. [(1) ]() How it works: When you send a config event at connection open with

auto_reconnect

set to

true

, Retell will send

ping_pong

events to your server every 2 seconds and expect them back. If there's no ping_pong event for 5 seconds, Retell will close the current connection and restart a new connection to your server for up to 2 times.

json
{
  "response_type": "config",
  "config": {
    "auto_reconnect": true
  }
}

Your server also needs to send

ping_pong

events back:

json
{
  "response_type": "ping_pong",
  "timestamp": 1234567890
}

Important limitations: - Based on community discussion, if the WebSocket drops without auto-reconnect enabled, **it doesn't automatically reconnect**—you'd need to initiate another call. [(2) ]() - If your custom LLM server takes too long (more than 4–5 seconds) before sending data, Retell closes idle connections. [(3) ]() Disconnection handling: If the LLM WebSocket connection breaks during a call, you'll see

error_llm_websocket_lost_connection

as the disconnection reason. [(4) ]() If your server sends a closing signal other than

1000

, you'll see

error_llm_websocket_runtime

. Recommendations: 1. Enable

auto_reconnect

in your config event and implement ping_pong handling [(1) ]() 2. Stream partial responses early to avoid idle timeouts [(3) ]() 3. Ensure your server supports persistent WebSockets (serverless with short timeouts may cause issues) 4. For zero-downtime deployments, consider draining connections gracefully before shutting down instances, as the reconnect mechanism only attempts up to 2 retries [(1) ]()

​ To learn more, see the sources I considered: [[1] LLM WebSocket](https://docs.retellai.com/api-references/llm-websocket) [[2] Websocket reconnect for Cloud Run / Azure Container Apps?](https://discord.com/channels/1186424376300679209/1217936443167608832) [[3] Discord message from @trxgames9630 on 2026-01-07](https://discord.com/channels/1186424376300679209/1294891368505937952/1458452259615674389) [[4] Debug call disconnection](https://docs.retellai.com/reliability/debug-call-disconnect) ​

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

### Answer Yes,

auto_reconnect

allows **resuming the same call**—it does not require starting a new call. [(1) ]() When

auto_reconnect

is set to

true

in the config event, Retell sends

ping_pong

events every 2 seconds. If there's no ping_pong event for 5 seconds, Retell will close the current connection and restart a new connection to your server for up to 2 times. This means the ongoing call continues while Retell re-establishes the WebSocket connection to your custom LLM server. The call itself stays active—only the LLM WebSocket connection is reconnected. Config example:

json
{
  "response_type": "config",
  "config": {
    "auto_reconnect": true
  }
}

Key points: - The reconnect mechanism attempts up to 2 retries - Your server must respond to

ping_pong

events within the expected timeframe to keep the connection alive - If all reconnection attempts fail, the call would then disconnect

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

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

### Answer Based on the available documentation, the specific WebSocket close code to use when closing the LLM WebSocket connection is not explicitly documented in the sources I have access to. [(1) ]() However, the documentation does mention that if your server sends a closing signal other than

1000

, Retell will register the disconnection reason as

error_llm_websocket_runtime

. This implies that close code

1000

(normal closure) is the expected/proper code to use when gracefully closing the WebSocket connection from your server side. Summary: - Use WebSocket close code

1000

for a normal, graceful closure - Any other close code will be treated as a runtime error by Retell

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

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

### Answer Based on the available documentation, the behavior regarding

call_details

being re-sent on reconnect is not explicitly documented. [(1) ]() Here's what we know about how

call_details

works: - When you set

call_details

to

true

in the config event, Retell sends a call details event to your server right away at connection open. - The config event is sent by your server at connection open. Config example:

json
{
  "response_type": "config",
  "config": {
    "auto_reconnect": true,
    "call_details": true
  }
}

Since the connection flow starts with your server sending the config event and then Retell responding with call details if enabled, it's reasonable to expect that on a reconnect you would send the config event again, and Retell would respond accordingly. However, this specific reconnection behavior is not explicitly stated in the sources I have access to. Alternative approach: If you need call details during a reconnect, you can always retrieve them using the [Get Call API](/api-references/get-call) with the

call_id

. , [(2) ]()

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

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

### Answer Based on the sources I have access to, the specific behavior of WebSocket close code

1000

in relation to ending the call is not explicitly documented. What the documentation does state is that if your server sends a closing signal other than

1000

, Retell will register the disconnection reason as

error_llm_websocket_runtime

. This indicates that close code

1000

is treated as a normal/graceful closure and won't trigger a runtime error—but whether it tells Retell "this call is intentionally ended" versus simply closing the LLM WebSocket connection (while the call might continue or reconnect) is not explicitly clarified in my available sources. If you need to programmatically end the call from your agent logic, the documented approach is to use the End Call tool configured in your agent. [(1) ]() For definitive behavior on how close code

1000

affects the call state, I'd recommend: - [Contact Sales]() - [Retell AI GitHub]() Would you like me to try to answer this more generally based on my knowledge?

​ To learn more, see the sources I considered: [[1] End call](https://docs.retellai.com/build/single-multi-prompt/end-call) ​

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

### Answer --- Based on the available documentation, there isn't an explicit mechanism documented for telling Retell "close gracefully but reconnect to me." [(1) ]() The

auto_reconnect

feature works based on ping_pong timeout detection, not on specific close codes you send. Here's how it works: - When

auto_reconnect

is

true

, Retell sends

ping_pong

events every 2 seconds and expects them back - If there's no ping_pong event for 5 seconds, Retell closes the current connection and restarts a new connection to your server (up to 2 times) Practical approach for your use case: Rather than sending a specific close code, you could stop responding to ping_pong events before your deployment. This would trigger Retell's reconnection logic after the 5-second timeout, and it would attempt to connect to your (newly deployed) backend. What we know about close codes: - Close code

1000

is treated as normal closure (no

error_llm_websocket_runtime

) - Any close code other than

1000

triggers

error_llm_websocket_runtime

The documentation doesn't specify a close code that means "reconnect please." The reconnection behavior appears to be driven purely by the ping_pong timeout mechanism when

auto_reconnect

is enabled. For definitive guidance on this specific scenario, I'd recommend: - [Contact Sales]() - [Retell AI GitHub]()

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

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

### Answer Based on the available documentation, the only documented mechanism to trigger

auto_reconnect

is the ping_pong timeout. [(1) ]() When

auto_reconnect

is set to `true`: - Retell sends

ping_pong

events every 2 seconds - Retell expects

ping_pong

events back from your server - Once there's 5 seconds without a ping_pong event, Retell closes the current connection and restarts a new connection to your server for up to 2 times No alternative approach is documented for triggering reconnection. The documentation doesn't specify any WebSocket close code or explicit message you can send to signal "reconnect to me." Summary of your options: 1. Stop responding to ping_pong – Let the 5-second timeout trigger reconnection 2. Close with any code other than 1000 – This triggers

error_llm_websocket_runtime

, but the documentation doesn't confirm this triggers a reconnect attempt The ping_pong timeout appears to be the designed mechanism for this behavior. If you need more granular control over reconnection triggers, I'd recommend reaching out via: - [Contact Sales]() - [Retell AI GitHub]()

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

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

### Answer Retell initiates a WebSocket connection to your custom LLM server in these cases: 1. When a call starts [(1) ]() Retell will initiate the LLM WebSocket when starting the call, and your server should be prepared to handle it. 2. When auto_reconnect triggers a reconnection If

auto_reconnect

is set to

true

in the config event and there's 5 seconds without a ping_pong event, Retell will close the current connection and restart a new connection to your server for up to 2 times. WebSocket Endpoint format:

wss://{your-server-websocket-endpoint}/{call_id}

Connection flow: - Retell connects to your endpoint with the

call_id

as a path parameter - Your server sends an optional config event and a response event (the begin message) - Retell sends back a call details event if enabled in config - The conversation proceeds with Retell sending transcript updates and requesting responses Key points: - The connection happens at call initiation (inbound, outbound, or web call) [(2) ]() - Reconnection only happens if

auto_reconnect

is enabled AND the ping_pong timeout (5 seconds) is triggered [(1) ]() - Retell attempts up to 2 reconnections before giving up

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

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

### Answer When

call_details

is set to

true

in the config event, Retell will send a call details event to your server right away after the connection opens. [(1) ]() Config example:

json
{
  "response_type": "config",
  "config": {
    "auto_reconnect": true,
    "call_details": true
  }
}

What happens when enabled: - Retell sends call details over to your server immediately at connection open - This gives you access to call information (like caller details, agent configuration, etc.) at the start of the WebSocket session What happens if NOT configured (or set to false) : - Retell will not send the call details event automatically - You would need to retrieve call information through other means, such as the [Get Call API]() using the

call_id

that's already available as a path parameter in your WebSocket endpoint Event flow reference: The connection starts by your server sending an optional config event and a response event. Retell then sends back a call details event if that's enabled in config.

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

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