VoiceBud
When this site answers out loud, it isn't an off-the-shelf synthetic voice: it's mine. VoiceBud is a clone trained on my own voice, bilingual — the English carrying my real accent, from my own reference, not a neutral English speaker.
It has been in production since 30 August 2026. Turn on voice mode in the chat bar and you'll hear it.
A provider behind a contract
VoiceBud is not a standalone product. SiteVox does not know VoiceBud: it knows a contract, VoiceProvider, of which VoiceBud is one implementation among others — neural synthetic voices are another. Switching provider, in either direction, is a configuration change, not a rewrite.
That detail matters: it is what makes experimentation possible. A voice can be wired in, judged, then unplugged, without ever touching the site.
The real problem was never the voice, it was the wait
A voice clone starting from cold makes people wait. And a perfect answer that arrives ten seconds late is a bad answer.
Two countermeasures, neither of which involves making the model faster:
- The prelude. An opening sentence pre-recorded in my voice, in French and English, played on the session's first answer. Sound starts immediately, asking nothing of the infrastructure.
- The pre-wake. On the first gesture that signals a spoken conversation — focusing the chat, a keystroke, the mic — the browser quietly wakes the engine in the background. Never on page load: you don't wake a machine for someone who is passing through.
How it runs
On a scale-to-zero GPU behind a private endpoint: nothing runs until somebody speaks, and the container shuts itself down. The recordings carrying my voice are mounted read-only and live outside the code repository — neither versioned nor logged.
It is a frugal architecture by construction: a voice nobody uses costs nothing.
What it taught me
- Defining the interface before the implementation pays off. The
VoiceProvidercontract was written before there was any clone to wire into it. That is what allowed switching providers, both ways, without ever rewriting the site. - When latency blocks you, hide it before trying to reduce it. The prelude doesn't make the model faster: it removes the perceived wait. The prelude and the pre-wake are what made the clone usable, not a performance gain.
That is exactly the reasoning I apply for a client: a visitor doesn't judge your architecture, they judge the delay before the first answer.