A 500ms-Latency 3D Storyteller That Kids Can Interrupt
Most AI storytelling tools are one-way text-to-speech pipelines. This build demonstrates that sub-second latency and true interruptibility—not just smarter models—are what make an AI feel present and responsive to a child, and the same interaction logic ports directly to physical robots.
A new open-source project combines a large language model with a 3D embodied avatar SDK to build a real-time storytelling companion for children. The frontend, built with Vue 3 and Vite, uses Trae Work for AI-assisted scaffolding and integrates DeepSeek or Tongyi Qianwen as the story-generation brain. The Mofa Nebula XmovAvatar SDK handles the avatar's lip-sync, facial expressions, and body movements, driven by a parameter-stream architecture that keeps end-to-end latency around 500ms.
A standout feature is real-time interruptibility: the `speakWithInterrupt` method lets a child cut off a story mid-sentence to ask a question, and the avatar responds immediately instead of finishing the old narration. The project also includes multi-avatar switching, child-friendly UI copy that hides technical jargon, and a mobile-responsive layout that auto-collapses the chat panel to keep focus on the avatar.
One integration pitfall involved a Tongyi Qianwen model returning empty `content` fields while hiding the actual story inside a `reasoning` field, requiring a custom extraction function to parse out the Chinese text. The entire codebase is designed to be reusable beyond the browser, targeting future deployment on humanoid service robots.
Real-time interruptibility, not model intelligence, is the feature that makes an AI companion feel present to a child—latency and the ability to stop mid-sentence matter more than story quality.
The gap between a text chatbot and an embodied agent is a standardized SDK that handles lip-sync, expressions, and body movement; Mofa Nebula's parameter-stream approach avoids the cost and rigidity of pre-rendered video.
AI-assisted scaffolding tools like Trae Work are most useful for generating boilerplate and edge-case handling (browser compatibility, error states), not for the integration logic that requires reading third-party SDK documentation.
Model API inconsistencies—like a response format that buries the output in a `reasoning` field—are still a significant source of debugging time and are easy to misdiagnose as prompt engineering failures.