We built voice, measured it on a cheap GPU, and left it switched off

Voice notes are near the top of every AI companion feature list, ours included. We built the whole path — model, endpoint, gating, playback, an audition page in the admin — and then didn't turn it on.

Here are the measurements that decided it, because “we decided not to ship voice” is not useful to anyone without them.

The setup

VoxCPM-0.5B, a small open-weights text-to-speech model, wrapped in an OpenAI-compatible endpoint so the app talks to a self-hosted box and a cloud vendor through exactly the same code path. Hardware: an RTX 3050, which is a deliberately unglamorous card — roughly what you get from the cheap end of GPU hosting, and the honest test of whether a feature works at a price a pre-revenue product can pay.

The number that matters for speech is real-time factor: seconds of compute per second of audio produced. Below 1.0 means faster than real time. Above 1.0 means the user waits.

The numbers

RTF 1.6 means a twelve-second voice note takes about twenty seconds to produce. The reference figure of 0.17 on a 4090 is real; it's also a card that costs more than this entire product has spent on everything.

VRAM at 5490 of 6144 is the more quietly alarming line. There is no room on that card for anything else, which means voice can't share a box with anything, which means it isn't a feature you add — it's a second machine you rent, running whether or not anyone presses play.

The 46% is the part that actually killed it

Latency is a cost. Inconsistency is a different kind of problem.

Without a reference clip to condition on, the model produces a plausible voice — a different plausible voice each time. We synthesised the same line twice for the same character and got 8.4 seconds and 12.2 seconds. Not the same delivery at different speeds: a different reading, a different rhythm, arguably a different person.

Which means the thing we would have shipped isn't “her voice.” It's a voice, freshly invented per message. For a product whose entire proposition is that this character is a consistent someone, a voice that changes between messages is worse than no voice at all — it actively contradicts the thing we're asking people to believe.

What we shipped instead of shipping it

The code is all there, behind a runtime switch that's currently off. Three things fall out of that decision:

• A character with no reference clip gets no voice button rather than a stranger's voice. Missing is a legal state throughout — the same way a character with no portrait falls back to a letter rather than someone else's face.
• The engine is a switch, not a rewrite. Browser speech synthesis (free, instant, generic system voice) and the server engine (real character voice, real GPU cost) are the same code path with a different base URL.
• The real-time call feature is off the roadmap for this hardware, not postponed. At RTF 1.6 a conversation isn't slow, it's impossible. Asynchronous voice notes are fine at 1.6 — they were always going to arrive a moment later. A call is not.

The general version

The temptation with a finished feature is to ship it and iterate. That's usually right. It's wrong when the first version teaches the user something false about the product — here, that this character's voice is arbitrary — because you don't get to un-teach it later with a patch note.

The cost of measuring was an afternoon. The cost of not measuring would have been a launch, a wave of “why does she sound different every time,” and a feature we'd have had to withdraw from people who'd already started using it. Withdrawing a feature from a companion product is not a neutral act — it's the thing this category is worst at.

Meanwhile the feature that actually decides whether any of this is worth anything on day thirty is memory, which costs no GPU at all. Voice is what people ask for. Memory is what makes them stay.