Trying to wire in local Qwen TTS
Goal: Route OpenClaw voice-call TTS to local qwen3-tts-api via Caddy while keeping everything else on OpenAI. Twilio inbound works. Streaming works. TTS currently still using OpenAI instead of Qwen.
Twilio → public DNS → Caddy → openclaw-gateway:3334
Internal OpenAI base URL intended to be http://caddy
Voice plugin:
plugins.entries["voice-call"].config.tts.provider = "openai"
We are intentionally keeping provider=openai and using Caddy to route /v1/audio/* to Qwen.
Current Caddyfile (relevant block)
http://caddy {
respond /healthz 200
handle /v1/audio/* {
reverse_proxy http://qwen3-tts-api:8880
}
handle {
reverse_proxy https://api.openai.com {
header_up Host api.openai.com
header_up Authorization {header.Authorization}
header_up OpenAI-Organization {header.OpenAI-Organization}
header_up OpenAI-Project {header.OpenAI-Project}
}
}
}
Voice-call config (current)
"tts": {
"provider": "openai",
"openai": {
"apiKey": "${OPENAI_API_KEY}",
"model": "gpt-4o-mini-tts",
"voice": "nova"
}
}
Twilio webhook: OK
/voice/webhook → openclaw-gateway:3334: OK
WebSocket /voice/stream: OK
STT realtime: OK
TTS plays correctly when using OpenAI
Qwen container shows no logs during voice TTS playback.
Either /v1/audio/* is not being called
Or OpenAI base URL is not http://caddy
Or voice-call plugin is hitting a different endpoint than /v1/audio/speech
In voice-call plugin, what exact endpoint is used for OpenAI TTS?
/v1/audio/speech?
/v1/responses?
How do I confirm what base URL the OpenAI client inside OpenClaw is actually using?
Is OPENAI_BASE_URL required?
Or is it derived from gateway config?
Is Caddy handle /v1/audio/* sufficient, or should I use @matcher path /v1/audio/speech instead?
Does voice-call bypass OPENAI_BASE_URL and use direct SDK defaults?
Intended
voice-call TTS still configured as "provider": "openai"
Caddy intercepts /v1/audio/speech
Qwen returns WAV/PCM
telephony-tts.ts converts to μ-law 8k
Twilio → public DNS → Caddy → openclaw-gateway:3334
Internal OpenAI base URL intended to be http://caddy
Voice plugin:
plugins.entries["voice-call"].config.tts.provider = "openai"
We are intentionally keeping provider=openai and using Caddy to route /v1/audio/* to Qwen.
Current Caddyfile (relevant block)
http://caddy {
respond /healthz 200
handle /v1/audio/* {
reverse_proxy http://qwen3-tts-api:8880
}
handle {
reverse_proxy https://api.openai.com {
header_up Host api.openai.com
header_up Authorization {header.Authorization}
header_up OpenAI-Organization {header.OpenAI-Organization}
header_up OpenAI-Project {header.OpenAI-Project}
}
}
}
Voice-call config (current)
"tts": {
"provider": "openai",
"openai": {
"apiKey": "${OPENAI_API_KEY}",
"model": "gpt-4o-mini-tts",
"voice": "nova"
}
}
Twilio webhook: OK
/voice/webhook → openclaw-gateway:3334: OK
WebSocket /voice/stream: OK
STT realtime: OK
TTS plays correctly when using OpenAI
Qwen container shows no logs during voice TTS playback.
Either /v1/audio/* is not being called
Or OpenAI base URL is not http://caddy
Or voice-call plugin is hitting a different endpoint than /v1/audio/speech
In voice-call plugin, what exact endpoint is used for OpenAI TTS?
/v1/audio/speech?
/v1/responses?
How do I confirm what base URL the OpenAI client inside OpenClaw is actually using?
Is OPENAI_BASE_URL required?
Or is it derived from gateway config?
Is Caddy handle /v1/audio/* sufficient, or should I use @matcher path /v1/audio/speech instead?
Does voice-call bypass OPENAI_BASE_URL and use direct SDK defaults?
Intended
voice-call TTS still configured as "provider": "openai"
Caddy intercepts /v1/audio/speech
Qwen returns WAV/PCM
telephony-tts.ts converts to μ-law 8k
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
131,281Members
Resources
Similar Threads
Was this page helpful?
