The WebSocket TTS endpoint buffers your input and only starts generating when the cumulative character thresholds in chunk_length_schedule are crossed. The default schedule is [120, 160, 250, 290]. When a threshold is reached, the server emits audio for part of the buffered text; any remaining text stays buffered until the next threshold is crossed or you explicitly flush/end. It does not guarantee voicing the entire payload of a single sendText in that first emission. (elevenlabs.io)
In your test (~200 chars), you crossed the 160 threshold, so audio began for an early portion of the buffer; the trailing part (after “Tomorrow brings …”) remained buffered because you didn’t send more text to reach the next threshold (250) or force a flush/end. (elevenlabs.io)
How to get the rest of the text to play
Send flush: true with your message to force-generate any buffered text immediately, or close the socket (sending an empty string) to automatically flush the buffer. (elevenlabs.io)
Alternatively, reduce the numbers in chunk_length_schedule so generation triggers sooner, or keep sending text until you cross the next threshold. (elevenlabs.io)
For full sentences/phrases you want rendered promptly without manual chunk management, you can set auto_mode: true, which disables the chunk schedule and buffers. (elevenlabs.io)
Reference background
The WebSocket endpoint is designed to start speaking from partial input and uses buffering/triggers to balance latency and quality. (help.elevenlabs.io)
If you need, share your current generation_config and message sequence and I can point to the exact trigger that caused the cut-off.
green bramble
shadow river