Why the speech model runs on the phone

It’s easy to say “runs on-device.” It’s a different thing to earn that sentence. Before it goes anywhere near an app listing, it has to survive contact with the phone someone in India actually owns — not a flagship on a lab bench, and not a laptop with memory to spare.

The starting point is a broadly multilingual on-device speech model. It’s a reasonable baseline, but out of the box it’s tuned for the languages with the most training data online, and Hindi — let alone Hinglish, the way most of our users actually speak — isn’t at the front of that queue. Generic models land somewhere around 20% word-error rate on Hindi, and worse on lower-resource Indian languages. That’s the number the Indic tuning work has to beat, not a marketing footnote.

So the design has two halves. The first is fit: retuning the recognizer with Indic-focused training data so it stops treating Hindi and code-switched speech as an edge case. The second is discipline: building the whole pipeline so that tuning doesn’t quietly assume a device most of our users don’t own.

That discipline shows up as a few concrete decisions, not a promise. Betterflo tiers what it runs by what the device can actually do — RAM and CPU headroom — instead of assuming everyone carries this year’s flagship. On the tier that matters most for reach, the model is quantized down to a footprint small enough to load, stay resident, and respond fast on a phone with only a few gigabytes of RAM to share across the OS, betterflo, and whatever else is open. None of that is free — a smaller, quantized model is a real trade against raw accuracy — which is exactly why it can’t be a trade we make and then forget to check.

That’s the bar we hold ourselves to: a capability doesn’t count as “on-device” for our users until it’s been measured on the hardware they actually carry, not just the hardware we wish they had. At the time of writing, that measurement — accuracy and load time on a real budget-tier phone — was still open work, not a finished result. It was the gate the project had to clear before this became a claim on the pricing page, and we weren’t going to round “designed for” up to “proven on” to make the sentence sound better sooner.

Update: that gate has since been cleared. Device tiers are live, measured on real hardware — see /devices for the honest, tier-by-tier picture.

This is also why we’re careful with how we phrase things publicly in general. “Runs on-device” is a testable claim, and we intend to test it before we lean on it. It is not the same claim as “your voice never goes anywhere, ever” — that’s a stronger, absolute promise we don’t make, because an opt-in cloud tier for extra quality is on the roadmap, clearly marked as planned and not shipped. What’s true today is narrower and more useful: by default, speech becomes text on your device, with no server round-trip required to get a result — and the architecture is built, tier by tier, specifically so that stays true on modest hardware, not just capable hardware.

At the time, there was more tuning ahead — Hindi and Hinglish first, the rest of the eleven once each was tuned for real, everyday speech, not before. The standard didn’t move: we don’t publish a capability as proven until we’ve watched it work on the hardware our users actually have.

Update: that tuning is done — all eleven languages have since shipped; see /languages for the full roster.