Thanks — I see two separate errors in your traces. I’ll explain what each one means, why it happens, and give clear steps to troubleshoot and fix them. 1) APIConnectionError: failed to generate LLM completion after 4 attempts (body=None, retryable=True) What this means • The agent tried to call your configured LLM provider but could not successfully complete the request after 4 retry attempts. • The error is connection-level (not a content error) and marked retryable, so retries were attempted but all failed. Likely causes to check • Network/connectivity issues between your service and the LLM provider (outbound HTTPS blocked, corporate proxy, firewall, or DPI like ZScaler). • The LLM provider endpoint is unavailable or temporarily down (provider outage or throttling). • Invalid, missing, or expired API credentials for the LLM provider. • Very long requests or timeouts causing the provider connection to fail. Actionable troubleshooting steps 1. Verify credentials and config ◦ Confirm the correct API key/env var is set (e.g.,

OPENAI_API_KEY

or provider equivalent) and not expired. 1. Test direct connectivity ◦ From the same environment where the agent runs, run a simple curl or Postman call to the provider endpoint (for example, `https://api.openai.com/...`) to confirm you can reach and authenticate the provider outside LiveKit. 1. Inspect network path ◦ Ensure outbound HTTPS (port 443) to the provider domain is allowed. ◦ If you’re behind corporate network controls, have the provider domain whitelisted or exempted from DPI. 1. Check provider status & rate limits ◦ Look at the provider’s status page and your account usage/limits to rule out outages or throttling. 1. Retry/timeout adjustments ◦ If connectivity is flaky, try again later. If failures are frequent, consider increasing timeouts or retry windows if configurable. 1. Collect logs ◦ Capture request attempts, timestamps, and any lower-level socket/timeouts — useful if you need to dig deeper. 2) AssertionError: only one message is allowed in a group (during chat context → provider format) What this means • When converting the internal ChatContext to an OpenAI-style request, the formatter groups items by tool_call_id and expects at most one assistant message per group. • A group contains more than one assistant/text message, which triggers the assertion. Why this happens • Your code or a node produced multiple assistant messages tied to the same tool call/grouping. Common situations: ◦ Calling multiple

say()

or

generate_reply()

(or equivalent) after a tool returns, within the same logical turn. ◦ Manually injecting multiple assistant messages into the ChatContext after a tool call. ◦ A tool or custom node emitting multiple textual outputs that get grouped under the same

tool_call_id

. How to fix it (concrete guidance) • Ensure one final assistant message per tool-call group: ◦ After a tool returns, only produce a single assistant reply. Avoid chaining multiple

say()

calls after the tool completes. • Prefer returning structured tool results and letting the LLM generate the reply: ◦ Return the result from the tool and call

session.generate_reply()

once (or let the standard flow generate the assistant message). • If you need interim messages, emit them before the tool returns (so they’re not grouped with the tool's result), or ensure interim messages are canceled/replaced and not left as multiple messages in the same group. • Review any custom

llm_node()

or overrides: ◦ Confirm they do not emit multiple `ChatChunk`/assistant messages without separating them into distinct logical turns. • Audit code paths that manipulate `chat_ctx`: ◦ Avoid calling

chat_ctx.add_message()

multiple times for assistant messages after a tool result. Minimal examples • Bad (multiple messages after tool):

# Do not do this after a tool finishes
await ctx.session.say("Part 1")
await ctx.session.say("Part 2")

• Good (single reply or return structured data):

# Return structured result and let the LLM generate the reply
return {"status": "ok", "summary": "..."}
# Or if you must speak, call generate_reply once:
await ctx.session.generate_reply(instructions="Give a short status message.")

Next steps I can help with • If you paste the code for the tool or node that runs around the failing tool-call (the function that runs the tool and any immediate

say()

/

generate_reply()

usage), I can point out the exact line causing multiple messages. • If you want, provide a short excerpt of how you call the LLM provider or the environment/network topology and I can help narrow down the APIConnectionError (for example, a curl result or provider response/timestamp). If you share the relevant snippets (tool function and where it returns/emits messages) I’ll review and give a specific change to make. Sources: Tool definition and use | LiveKit Documentation | Pipeline nodes and hooks | LiveKit Documentation