just curious if anyone try this and have some example ![]()
Yes, I’ve seen quite a few do it. Probably the easiest thing to do is run the agent on the same machine as your openclaw runs on.
I’ve seen various ways to control OpenClaw. I tried this project recently that was shared in community slack show and tell:
I modified the example above and also used the LiveKit ESP32 library so I can talk to OpenClaw as I demonstrate a little in this video:
with a glance i think it will be better to implement an llm module with the openclaw message protocol so it will be easier to mount existing openclaw into livekit, will have a try later (or something already done it ![]()
OpenClaw supports OpenAI completions API. You can point the OpenAI plugin at it and it works (you will need to adjust some timeouts). That is a low-friction path. One tricky thing to manage is that OpenClaw can take a long time to respond. One other good thing about the completions API is that you can put the “channel” at the end to communicate across Open Claw channels.
Shayne on our team suggests the best way to integrate with openClaw is to have openClaw host an MCP server and point the agent to it. I’ve not tried this yet, but it seems pretty reasonable. I haven’t looked into whether/how openClaw hosts an MCP server.
I would love to hear what you find out.
You can make a continuity loader so that when asked to call you, the OpenClaw agent does a handoff to the LiveKit agent. And the LiveKit agent itself can run on anything - it has any STT, TTS, LLM stack or whatever real-time mode. You can even configure the bot to be able to switch stacks right in the middle of a conversation. That’s actually how I set it up. The combo is fire.
Hey Anton, i’m not sure to understand, do you have a working example / github repo ?
I was at a Machine Learning conference recently, and there was a conversation about how to voice-enable Claude. I put this tmux agent together that lets you voice-enable your shell and have multiple concurrent shells. With a few tweaks, this should work fine for OpenClaw, too, for CLI commands:
It has an iOS client to that does a local web proxy so you can test on your phone to a web server running on your Claude (or openClaw) machine.
Hey Gabin, yes — I extracted a sanitized example here:
It is not my private production stack, but it shows the integration shape I meant.
The basic idea is:
- LiveKit owns the realtime room/media path: WebRTC/SIP, token/dispatch, participants, call lifecycle.
- The voice worker loads a compact OpenClaw context packet when the call starts.
- Tools, memory lookup, delegation, and recap go through an OpenClaw-style adapter instead of the worker reaching directly into private OpenClaw internals.
- Provider stacks stay pluggable: native realtime, classic STT/LLM/TTS, or a hybrid handoff path.
- Slow work can be delegated out of the live call instead of producing dead air while the user waits.
So this is closer to a “voice engine + adapter seam” than a tiny one-file demo.
The part I find interesting is keeping LiveKit as the stable live-call layer, while OpenClaw acts as the continuity/tool/delegation layer behind an adapter. That makes it possible to experiment with different realtime models, STT/TTS providers, voice controls, and handoff strategies without making the OpenClaw side care too much about the audio stack.
The repo is intentionally sanitized, so it does not include my private production setup, secrets, logs, call history, or provider keys. But it should show the pattern well enough to discuss or build from.