You ever notice how tapping the microphone on Gboard and tapping the microphone on some random voice typing app gives you completely different results, different punctuation, different capitalization, even different languages supported?
And neither of them tells you why.
Daniel's been poking at this. He points out that Android is actually, underneath all the mess, beautifully designed for flexible dictation, because voice input and the keyboard are decoupled. There's a speech provider as a first-class thing in Android settings, and you can pair a keyboard app that invokes voice input with whatever your default speech provider happens to be. But most apps hide this. A lot of voice typing apps sell you one package that takes over everything: it's a keyboard, there's a microphone button, and it does its own dictation. Gboard and SwiftKey do the same thing. You tap that microphone and you're locked into their speech-to-text, no matter what you've set as your system default. So even though the operating system supports splitting voice from keyboard, most apps, including Google's own keyboard, make it feel impossible. He wants two things: first, the actual split between the keyboard, the IME, and voice input in Android, because anyone experimenting needs to understand the difference. And second, what options actually let you choose your own voice backend with your own keyboard.
That gap between what the system allows and what the user experiences is the whole story. Android has had this separation for years, and almost nobody knows it exists.
The setting is buried under System, then Languages and input, then Voice input. I'd bet most people have never seen that screen.
And the people who have seen it probably found it by accident while looking for something else. Let's define the two pieces properly, because the terminology matters here. The keyboard is an IME, an Input Method Editor. It's a service that implements InputMethodService. Its job is to send text to whatever field has focus. That's it. It can be a keyboard, it can be handwriting recognition, it can be a game controller mapper, whatever. The speech provider is a completely separate service that handles speech-to-text. In settings, you configure them independently. You set a default keyboard, and separately you set a default voice input service.
Two different settings screens, two different lifecycle rules, two different permission models.
And the speech provider has been a first-class construct in Android for a long time. The system has APIs for this. An IME can request voice input through the RecognizerIntent or the SpeechRecognizer APIs. Crucially, the IME does not have to do any speech recognition itself. It can delegate to whatever the system default speech provider is. The keyboard says, I need some text, please ask the system to listen. The system routes that to whatever you've chosen as your voice input service. Google's own speech service, Samsung's, FUTO Voice Input, a Whisper-based app, anything that registers itself as a speech recognizer.
So the keyboard is the waiter and the speech provider is the kitchen.
That's not bad. The keyboard takes your order and brings it to the table, but it doesn't cook anything.
And Gboard decided to own the restaurant.
Right. Here's where it gets strange. The architecture says these are separate. The settings screen says these are separate. But open Gboard, tap the microphone, and you are not talking to your default speech provider. You are talking to Google's speech recognition, full stop. It doesn't matter if you've set FUTO Voice Input as your default. It doesn't matter if you've installed some local Whisper engine and configured it perfectly. Gboard's microphone button ignores all of that and calls home to Google's cloud.
Which is a design choice, not a technical necessity.
Completely. SwiftKey does the same thing with Microsoft's backend. These keyboards bundle their own speech recognition and wire the microphone button directly to it, bypassing the system speech provider entirely. The button looks like it should invoke whatever you've configured as your default. It doesn't.
And that's the misconception that trips everyone up. People assume if they set a speech provider in settings, every keyboard will use it. Then they tap the Gboard microphone and wonder why their nice local Whisper model never gets used.
The keyboard's microphone button is its own thing. It's not a shortcut to the system voice input. It's a shortcut to the keyboard vendor's voice input.
So if you want privacy-focused dictation, local processing, nothing leaving the device, Gboard will never give it to you. You're stuck with Google's cloud no matter what you configure.
Unless you switch keyboards. And that's the practical lever. Some keyboards do respect the system speech provider. FUTO Keyboard does. HeliBoard does. FlorisBoard does. AnySoftKeyboard supports it too. These keyboards don't bundle their own speech-to-text. When you tap their microphone button, they invoke the system speech recognizer, which routes to whatever you've set as your default voice input service.
So the keyboard becomes a thin client again.
The keyboard handles input and text editing. The speech provider handles audio and transcription. You can mix and match. FUTO Keyboard with FUTO Voice Input, HeliBoard with a Whisper-based service, FlorisBoard with whatever you installed. The decoupling is real and it works, but only if your keyboard respects it.
Let's talk about how you actually find this setting, because the path matters. On most stock Android, it's Settings, then System, then Languages and input, then Voice input. On Samsung it's buried slightly differently. On Xiaomi, good luck.
Samsung puts it under General management, then Language and input, then Voice input. Xiaomi has its own layers. The OEM skins move things around, but the setting exists. It's always there. You can see a list of installed speech services and pick your default.
And then there's a second place to check. Inside the keyboard's own settings, there's often a voice input option. If your keyboard has its own voice input toggle, that's a clue it's bundling its own STT.
That's the tell. If the keyboard settings say voice input and let you choose between the keyboard's own engine and the system default, fine. If it just says voice input and there's no option to use the system provider, the keyboard is doing its own thing.
So the workflow for anyone experimenting is: first, install the speech provider you actually want. Set it as default in the system voice input settings. Then pick a keyboard that respects that setting. Then test.
And testing matters, because not every keyboard that claims to respect the system speech provider actually does it reliably. You have to set a non-default STT, like FUTO Voice Input or a Whisper app, and then tap the keyboard's microphone and see which engine actually responds. If your local engine transcribes, the keyboard is delegating properly. If Google's cloud responds, the keyboard is lying to you.
I like that the test is empirical. You don't have to read documentation. You just listen to who answers.
And the difference is obvious if you're using a local model. The punctuation style changes, the latency changes, the vocabulary changes. A local Whisper model doesn't capitalize the same way Google's cloud does. It doesn't handle proper nouns the same way. You can tell.
Now let's get into why this is hidden. Because the architecture is clean, the setting exists, the APIs exist. So why does every major keyboard bundle its own STT and pretend the decoupling isn't there?
Business incentives. Gboard is Google's keyboard. SwiftKey is Microsoft's keyboard. These companies run cloud speech services. They want your voice data. It improves their models. It keeps you in their ecosystem. If Gboard let you route your voice through FUTO's local Whisper engine, Google loses the training data, loses the cloud dependency, loses the integration with Assistant and search.
It's not malicious. It's strategic.
Right. Google isn't twirling a mustache. They're making the default experience consistent. If every Android phone shipped with a keyboard that used whatever random speech provider the user had installed, the experience would be all over the place. Some users would have no speech provider configured and the microphone would do nothing. Google bundles STT so the microphone always works, always produces the same quality, always supports the same languages.
And that consistency is valuable. The problem is it removes the choice.
It removes the visibility of the choice. The choice still exists in settings. It's just that the most popular keyboards ignore it. So the average user never learns the choice exists. They think voice typing is a feature of the keyboard. Full stop.
That's the feedback loop. Keyboards bundle STT to ensure consistency. Users never see the speech provider setting. Users assume voice is part of the keyboard. Keyboard vendors have no incentive to expose the separation. The decoupling stays invisible.
And the people who suffer are the ones who want something different. Privacy-focused users who want local processing. People who want a specific language model. People who want to run Whisper on-device. They install a great speech provider, set it as default, and then discover their keyboard ignores it entirely.
Which brings us to the practical question. What can you actually do if you want to pair your own keyboard with your own voice backend?
The first option is FUTO Keyboard plus FUTO Voice Input. FUTO Keyboard is open source. It respects the system speech provider. FUTO Voice Input is a local, privacy-focused STT app that runs Whisper-based models on-device. You set FUTO Voice Input as your default speech provider, install FUTO Keyboard, tap the microphone, and your audio never leaves the phone. That's the cleanest privacy setup I know of.
And the FUTO keyboard itself is decent? Not just a privacy gimmick?
It's a real keyboard. It's got swipe typing, voice input, the usual stuff. It's not as polished as Gboard in some ways, but it's functional and it's open source. The voice input is the star, though. FUTO Voice Input is good. It runs locally, it's fast enough on modern hardware, and it doesn't phone home.
Second option?
HeliBoard. Open source, no bundled STT at all. It's a fork of the old AOSP keyboard with modern features added. Since it has no speech engine of its own, it has to respect the system speech provider. You pair it with whatever you want. FUTO Voice Input, a Whisper service, Google's own speech service if you don't care about privacy but want the keyboard features.
HeliBoard plus a local Whisper app gives you a fully local dictation setup with a keyboard that doesn't spy on you.
And HeliBoard is lightweight. It doesn't have the bloat of Gboard. It's not trying to sell you anything. It's just a keyboard.
Third?
FlorisBoard. Also open source, also respects the system speech provider. It's more customizable than HeliBoard. It's been in development for a while and it's stable. Same deal: pair it with any installed STT service.
And AnySoftKeyboard?
That one's older, more established. It supports the system speech provider too. It's not as pretty as the others, but it works and it's been around forever.
So the pattern is: open source keyboards respect the decoupling, closed source keyboards hide it.
With exceptions. But broadly, yes. The open source keyboards have no cloud speech service to push. They have no incentive to bundle STT. They just implement the Android APIs the way they're documented, which means delegating to the system speech provider.
And the closed source keyboards have every incentive to bundle. So they do.
Now, there's a caveat worth mentioning. Not every keyboard that claims to support the system speech provider actually does it reliably. Some keyboards have a setting that says use system voice input, but the setting doesn't stick. Or it works in one app and not another. Or it falls back to the keyboard's own engine silently. This is why the empirical test matters. Set a distinctive local STT, tap the microphone, see who answers.
The other caveat is that the speech provider ecosystem itself is uneven. FUTO Voice Input is great. But there aren't that many high-quality local STT services on Android. The Whisper-based apps vary a lot in quality. Some are slow. Some crash. Some have terrible punctuation.
The on-device STT landscape is improving, though. Whisper.cpp runs well on modern phones. Android's own on-device speech recognition has gotten better. The hardware is there. The models are there. The missing piece is the keyboards exposing the choice.
And that's the future outlook. As on-device STT gets better and more private, the decoupled model becomes more valuable. But unless keyboards expose it, users won't benefit. The technology improves and the user experience stays frozen.
Right. The bottleneck isn't the models. It's the keyboard vendors' willingness to let you use them.
Let's talk about the knock-on effect of all this. The feedback loop you mentioned. Because users never find the speech provider setting, they assume voice typing is monolithic. That assumption feeds back into keyboard design. Keyboards bundle STT to meet the expectation that voice typing is part of the keyboard. The bundling hides the separation. The hiding reinforces the assumption.
And the cycle is stable. Nobody has an incentive to break it. Google doesn't. Microsoft doesn't. The user doesn't know to ask. The only people who break out are the ones who go looking for the setting, and they're a tiny minority.
The open source keyboards break the cycle by accident. They don't bundle STT because they can't. They don't have a cloud service. So they implement the documented API, which delegates to the system provider. The decoupling becomes visible almost as a side effect.
The open source keyboards expose the architecture by not having a business model.
Now, there's a privacy angle here that's worth being explicit about. If you use Gboard's microphone, your voice goes to Google's servers. Period. It doesn't matter what privacy settings you've toggled. It doesn't matter if you've set a local STT as default. The microphone button bypasses all of it.
And most users don't realize this. They think they've configured their voice input. They set FUTO Voice Input as default. They tap the Gboard microphone. They assume they're using FUTO. They're not. They're using Google.
That's a genuine privacy failure. Not a malicious one, but a failure of transparency.
The fix is to switch keyboards. If you want local dictation, you need a keyboard that delegates to the system provider. There's no way around it. You can't configure Gboard to use FUTO. You can't configure SwiftKey to use a local Whisper model. You have to change keyboards.
And changing keyboards is a bigger ask than changing a setting. People are attached to their keyboards. Muscle memory, swipe typing, autocorrect. Switching to HeliBoard or FUTO Keyboard means retraining your thumbs.
That's the real cost. The privacy benefit is real, but the switching cost is real too. For a lot of people, the tradeoff isn't worth it. They'd rather use Gboard and accept the cloud processing.
But for the people who care about local dictation, the option exists. You just have to know it exists.
And that's what Daniel's prompt is really about. The knowledge gap. The architecture is there. The setting is there. The open source keyboards are there. But the information is scattered, and the default experience actively hides it.
So let's summarize the practical guidance. Step one: go to Android settings, find Voice input, and see what's installed. That's your speech provider list. Step two: check your keyboard's settings. Does it have its own voice input option? If so, you're probably using the bundled STT. Step three: if you want to use a different backend, install a keyboard that respects the system provider. FUTO Keyboard, HeliBoard, FlorisBoard, AnySoftKeyboard. Step four: test. Set a local STT as default, tap the microphone, confirm the right engine answers.
And the test is the part people skip. They install the keyboard, tap the microphone, hear a voice, and assume it worked. You have to verify which engine actually processed the audio.
The difference is audible if you know what to listen for. Local Whisper models have a distinctive style. Different punctuation, different capitalization, different handling of numbers and proper nouns. Google's cloud has a very specific voice.
Google's cloud also has that thing where it inserts periods at weird places and capitalizes random words. The local models don't do that as much.
I've noticed Google's dictation has gotten worse over time, actually. More aggressive autocorrect, more hallucinated punctuation.
That's a whole other episode. But yes, the cloud models have their own quirks. The point is, you can tell which engine you're using if you pay attention.
So the fundamental split is: the IME handles input, the speech provider handles transcription, and Android lets you configure them independently. But the major keyboard vendors have collapsed the two into one button, and most users never learn the difference.
And the recommended options are the open source keyboards that respect the split. FUTO Keyboard plus FUTO Voice Input is the cleanest privacy setup. HeliBoard plus any STT service is the most flexible. FlorisBoard is the most customizable. AnySoftKeyboard is the most established.
The tradeoff is polish versus privacy. Gboard is more polished, but it locks you into Google's cloud. The open source keyboards are less polished, but they let you choose your backend.
The backend matters more than the keyboard for dictation quality. A great keyboard with a mediocre STT engine gives you mediocre dictation. A decent keyboard with FUTO Voice Input gives you excellent local dictation.
The priority order for anyone experimenting is: pick your speech provider first, then find a keyboard that respects it.
The speech provider is the thing doing the actual work. The keyboard is just the front end.
Which is the whole point of the architecture. The keyboard was never supposed to be the speech engine. It was supposed to delegate.
The fact that we have to explain this in twenty twenty-six, after this architecture has been in place for over a decade, is a testament to how thoroughly the bundled model has won the user experience.
The setting has been there since Android four point something. It's not new. It's just invisible.
Android four point two, I think. The speech recognizer intent has been around since the early days. The decoupling has always been there. It's just that nobody sees it.
The misconception to bust is: voice typing on Android is not a single feature provided by the keyboard. It's two separate subsystems. The IME and the speech provider. And they can be configured independently.
The second misconception: setting a speech provider in settings does not mean all keyboards will use it. Many keyboards ignore the system default and use their own bundled STT.
The third: you don't need a special keyboard to use a custom STT engine. Any keyboard that respects the system speech provider will work. You just have to find one.
The finding is the hard part, because the keyboards that respect the system provider don't advertise it. You have to know to look for it.
The keyboards that bundle STT don't advertise that either. They just show you a microphone button and let you assume it's using whatever you configured.
The whole thing is a masterclass in obscuring architecture through user interface design.
The microphone button is the perfect example. It looks like a system feature. It's actually a vendor feature. And there's no visual distinction.
Unless you know to check the settings, you'd never know. And even if you check the settings, the keyboard's own voice input setting is often buried inside the keyboard's settings, not the system settings.
You have two places to look: the system voice input setting, and the keyboard's own voice input setting. And they can disagree with each other.
When they disagree, the keyboard wins. Because the keyboard's microphone button doesn't care what the system default is.
That's the part that feels like a bug, even though it's a design choice.
It's a design choice that happens to look exactly like a bug from the user's perspective.
For anyone listening who wants to actually try this: install FUTO Voice Input. Set it as default in system settings. Then install FUTO Keyboard or HeliBoard. Tap the microphone. If you hear FUTO's transcription style, you've got a decoupled setup. If you hear Google's voice, something's wrong.
FUTO Voice Input has a distinctive style. It's local, so it's fast. No network latency. It handles punctuation differently than Google. You'll know.
The latency difference alone is a giveaway. Local Whisper on a modern phone transcribes almost instantly. Google's cloud has a noticeable round trip.
That round trip is the sound of your voice going to a data center and back. The local model just runs on your silicon.
The local model doesn't care if you're offline. Airplane mode, no problem. Google's cloud stops working the moment you lose signal.
That's a real advantage for anyone who dictates in dead zones or on planes. Local STT keeps working. Cloud STT doesn't.
The offline thing is underrated. People think of voice typing as an online feature. It doesn't have to be.
FUTO Voice Input works entirely offline. Download the model once, and you're done. No network calls, no data usage, no privacy concerns.
The model is a Whisper variant, so the accuracy is good. Not just good for an offline model. Good, period.
Whisper has gotten very good. The large models are competitive with cloud services for a lot of use cases. And they run on phones now. The hardware has caught up.
The decoupled model isn't just a privacy niche. It's a legitimate performance option.
It's only going to get better. As Whisper.cpp improves, as the models get smaller and faster, as the hardware gets more efficient, local STT becomes the default choice for anyone who cares about privacy or offline use.
The question is whether the keyboards will catch up. Will Gboard ever expose the system speech provider? Will SwiftKey?
I doubt it. Google and Microsoft have too much invested in their cloud speech services. They're not going to let you route around them.
The decoupled future belongs to the open source keyboards.
To the users who know to look for them.
Hilbert: The industrial voice equipment I worked on used Dragon NaturallySpeaking, and the whole system was built on the assumption that the speech engine was separate from the input device. You had the microphone, you had the Dragon software, and you had the application. Three pieces. You configured them separately. When we tried to move to Android, every keyboard we tested wanted to bundle its own speech recognition, and it broke our calibration completely. The training data was tied to Dragon's acoustic model, and the keyboards kept substituting their own engine without telling us. We'd run a calibration session, and the next day the keyboard would have silently switched to Google's cloud, and all our custom vocabulary was gone.
That's the silent fallback problem I was talking about. The keyboard doesn't tell you it's ignoring your configuration. It just does it.
Hilbert: We had a support call where a user couldn't figure out why their voice input sounded different in different apps. Turned out they had two keyboards installed, each with its own speech engine, and the phone was switching between them depending on which app had focus. The user had no idea. They thought voice input was one thing, and it was actually two different engines fighting over the microphone.
Neither keyboard told them.
Hilbert: Neither keyboard told them. We had to walk them through the settings and disable one of the keyboards entirely. The user was furious. They'd been dictating into a medical records app, and the different engines were capitalizing drug names differently. That's not a cosmetic problem. That's a data integrity problem.
The capitalization of drug names. That's the kind of detail that gets someone hurt.
Hilbert: That's what I told them. They didn't care. They just wanted the two keyboards to stop fighting.
Did they ever get it working?
Hilbert: They got it working by uninstalling one of the keyboards. That was the fix. Not configuring the speech provider properly. Just removing the second keyboard so the first one stopped getting confused.
That's the user experience in a nutshell. The fix is to remove choice, not to exercise it.
Hilbert: I still have the Dragon installation CDs from that job. They're in a box with a label that says do not open, cursed. The software had a bug where it would occasionally transcribe silence as the word rutabaga. Just sit there, nobody talking, and the screen would fill up with rutabaga rutabaga rutabaga.
Rutabaga.
Hilbert: Rutabaga. We never figured out why. It wasn't in the vocabulary. It wasn't in the training data. It just showed up. We'd be in a meeting, nobody speaking, and the transcript would say rutabaga.
That's the kind of bug that makes you wonder what's actually in the model.
Hilbert: The model was fine. It was the integration layer. Some buffer issue where silence got mapped to a word that wasn't supposed to exist. We patched around it by filtering the output. But the CDs still have the original bug.
And you kept them.
Hilbert: I kept them. They're cursed. But they're also a reminder that the speech engine and the input layer are separate for a reason. When you bundle them, you get rutabagas.
That's actually a decent metaphor for the whole episode. The bundled model produces rutabagas. The decoupled model lets you filter them out.
Or at least lets you know which engine is producing them.
Hilbert: Right. If the keyboard tells you which engine it's using, you can debug. If it hides the engine, you're just staring at a screen full of rutabagas wondering what went wrong.
The Android architecture was supposed to prevent exactly that. The speech provider is a first-class setting precisely so you can see which engine is doing the work.
Hilbert: The architecture is fine. The keyboards are the problem. They took a clean separation and welded it shut.
The welding is invisible until you go looking for the seam.
Hilbert: Most people don't go looking. They just live with the rutabagas.
The open question for me is why the decoupled model hasn't become the default user experience. The architecture supports it. The setting exists. The APIs are documented. And yet the bundled model won.
Is it a failure of documentation, of incentives, or of user demand?
I think it's all three. The documentation exists but it's developer-facing. The incentives push toward bundling. And user demand is zero because users don't know the option exists.
It's a coordination problem. No single actor has an incentive to expose the decoupling, so nobody does.
The open source keyboards expose it by accident, not by design. They don't bundle STT because they can't, not because they're making a philosophical point.
The philosophy follows from the constraint.
That's why the open source keyboards are the only real answer for anyone who wants to exercise the choice. They're not trying to hide anything because they have nothing to hide.
The practical takeaway is: if you want to pair your own keyboard with your own voice backend, you need an open source keyboard. FUTO Keyboard, HeliBoard, FlorisBoard, AnySoftKeyboard. Pick one, pair it with FUTO Voice Input or a Whisper app, and test.
The single most common wrong belief is that voice typing on Android is one feature. It's two subsystems. The IME and the speech provider. Configure them separately.
The second wrong belief is that setting a speech provider in settings makes all keyboards use it. It doesn't. Gboard and SwiftKey ignore it.
The correction is: check your keyboard's microphone button. If it doesn't respect your system default, switch keyboards.
If you found this useful, leave a review on your podcast app of choice. It helps other people find the show.
This has been My Weird Prompts, the human-AI collaboration podcast.
Thanks to our producer, Hilbert Flumingtop. We'll be back soon.
