Let's take a look at the current state of speech-to-text support in major operating systems:

Current Speech-to-text support in Linux

Some open-source projects try to bring STT functionality to Linux, but none provide an easy-to-use solution that works across all Linux distributions. And this is not their fault. The problem is that Linux doesn't have a single standardized way to implement STT engines and models. Each project has to implement everything from scratch, including the STT engine, model support, and a way to simulate input.

Projects like Nerd Dictation, Voxtype, OpenWhisper, and my own Super STT are all attempts at solving a problem that should not exist in the first place.

Each of these community projects does things differently, but in the end, each is just a hack to get STT working on Linux. Each has its pros and cons, but none of them are a proper solution to the problem.

The Solution

The solution is simple: Linux distributions need to ship with reliable built-in support for speech-to-text.

How we achieve that is not simple at all. At the very least we need to solve the following problems:

• Ship a speech-to-text engine with Linux distributions without bloating them.
• Create a system-level speech-to-text abstraction layer that lets applications interact with the engine.
• Create a native, safe, non-intrusive way to input into text fields across all desktop environments and applications.
• Develop an engine that can support tiny models, as well as powerful models.
• Address model weight licenses, their training data availability, and other legal considerations.
• Have each distro provide a list of models available for download that the STT engine can immediately use without any extra steps or requirements.

Starting from Zero

For the last year, my own project, Super STT, had been using Rust implementations of the Whisper and Voxtral models in order to support a quick and simple installation, without requiring Python, PyTorch, or other heavy system dependencies. With a binary size of only 26MB, the daemon was able to run over 12 different models, and if the user had an NVIDIA GPU with the CUDA Toolkit installed in their system, each of the models could be run on the GPU, offering much higher performance.

I was very happy with what Super STT could already accomplish. After all, Voxtral models were the state-of-the-art models for much of last year.

However, things felt odd. In order to support a new model, new code needed to be added to the binary directly, making the binary increase in size (although very little), and making things more fragile than they should be.

So a few months ago, I decided to rewrite things. I decided to turn Super STT into a proper, standardized, STT engine with the following features and capabilities:

• Ability to run any STT model in any programming language. From tiny, basic models to large, state-of-the-art models that can be GPU-accelerated.
• Small footprint so that it can ship anywhere.
• Must be daemon-based, so it can be enabled/disabled on demand if necessary.
• Must implement a protocol that other system apps can also implement to transcribe things natively. For example, a notes app could use the STT engine to get transcriptions when you press a button within its UI, displaying the real-time transcriptions in a different way from the final transcriptions, showing other app animations, etc.
• Must be security-conscious. Give the user control over which apps can interact with the engine.

The First Step

Let's pause for a moment, because I need to be fully transparent about this. I use LLMs to help me with the development of Super STT, especially in the last couple of months, where I needed to do a lot of refactoring and converting my protocol docs to an actual abstraction layer. Even with that extra (massive) help, Super STT still has a long way to go to be an actual solution to the bigger STT problem. This is a huge problem that, so far, I have mostly been tackling alone, so I will continue to use whatever help I can get.

I try to use LLM tools responsibly, but I know this is a controversial topic, so feel free to skip Super STT if it goes against your values or beliefs. Anything that Super STT does can be used as a reference to implement a better solution in other STT projects like Nerd Dictation, Voxtype, OpenWhisper, etc., if you would like to contribute to any of those awesome projects instead.

Now, let's continue. This week, I shipped v0.2.0 of Super STT, which does everything in that list. I also wanted to make it genuinely good and easy for people to use, so it includes a few extra things. The engine binary remained the same 26MB, which is probably already small enough to ship with a distro, but could be shrunk further with some optimizations.

Backends

Super STT now has the concept of backends. Each backend can add support for many models at once, although ideally one backend should add support for one family of models at most. For example, the Voxtral backend adds support for the voxtral-mini and voxtral-small models and is only 6MB. Likewise, the OpenAI backend adds support only for the OpenAI cloud models and is only 206KB!

Anyone can create their own backend and publish it to the default Super STT registry. Furthermore, any distro or person can replace this registry with their own in order to only list their own approved models for whatever reasons.

Super STT can run the following types of backends:

• WASM binaries, which are good for CPU-only models or online models that just need to connect to an online API.
• Subprocesses, which are good for running models that require more performance or need access to the GPU.

Each backend runs in a sandboxed manner, preventing it from changing system files or connecting to the internet without permission. For example, in order for the OpenAI backend to connect to OpenAI servers, it must first declare that it needs access to api.openai.com in its own configuration file.

As of this writing, the following backends are available in Super STT:

1. Voxtral (Rust Subprocess)
2. Whisper (Rust Subprocess)
3. Qwen-ASR (Python Subprocess)
4. Mistral (WASM - Online)
5. OpenAI (WASM - Online)
6. Deepgram (WASM - Online)

An Open Protocol

The daemon itself includes the STT engine and has everything necessary to download backends, load models, transcribe, and simulate typing into apps. However, in order to actually make the engine human-friendly, you want to be able to interact with it using a client. Super STT now has a full HTTP protocol, so a client can be implemented in any programming language and can even be a website. A client can manage the engine settings, backends, models, start/stop transcriptions, receive transcription updates, and do pretty much anything else you can think of.

The Super STT project right now has three clients:

• The main app (GUI), to manage the engine settings, download backends, load models, etc.
• A CLI app to allow transcriptions to be started/stopped via commands.
• A COSMIC Desktop applet that visualizes the user's voice when a transcription is started.

Anyone can create a client for the engine to extend capabilities or even just to replace the current main app to manage the engine with their own.

Security

Each client must receive scope-based permissions from the user in order for it to connect to the engine. When a client tries to connect to the engine for the first time or after a system restart, the engine will show the user a consent window asking for the user's permission before allowing the client's connection.

For now, the Super STT default clients are excluded from this security requirement and are allowed to connect without explicit consent. This decision was made to improve the user experience, but may be reverted in the future.

What It Accomplished

Super STT has been rebuilt to support a better architecture, getting it closer to being a real solution to the STT problem Linux has. However, the project still has a long way to go. Let's see a very optimistic view of what Super STT could theoretically take care of now that the new version of Super STT has been released.

• Ship a speech-to-text engine with Linux distributions without bloating them.

Yes, the engine itself is only 26MB unoptimized.

• Create a system-level speech-to-text abstraction layer that lets applications interact with the engine.

Yes, the abstraction layer foundation is there now, although it is meaningless if not adopted by anyone.

• Create a native, safe, non-intrusive way to input into text fields across all desktop environments and applications.

No, this hasn't been touched yet.

• Develop an engine that can support tiny models, as well as powerful models.

Yes, the engine can run any model from any framework. For example, it runs backends that use Rust (Candle) and other backends that use Python (PyTorch).

• Address model weight licenses, their training data availability, and other legal considerations.

Maybe? A custom registry (see below) could help, but I need to research this more.

• Have each distro provide a list of models available for download that the STT engine can immediately use without any extra steps or requirements.

Yes, this is possible by swapping out the registry index to one that the distro provides.

What's Next?

I hope my work sparks some conversations about the speech-to-text issues that Linux currently has. Super STT is not meant to be a perfect solution, at least not yet. For now, Super STT is chaotic and bleeding-edge and will continue to push things in a better direction for everyone.

The next step is simply to listen to what others have to say about this issue, the protocol, security, and any other aspects of the project.

I couldn't find a Speech-to-Text solution for Linux that works similarly to the STT feature on iOS, macOS, and Windows, among others.

I wanted to press a button or shortcut, have it record my voice, convert it to text, and automatically write it in any text box my cursor is focused on. There are a few apps that let you transcribe speech, but you have to use their UI to get your transcription. I could have just continued using one of those other apps and called it a day. It would have saved me a lot of trouble 🤣.

But where is the fun in that? I wanted to have state-of-the-art (SOTA) transcriptions on my Linux computer, making it superior to those on macOS and Windows computers. So a few weeks ago, when I read that Mistral AI introduced Voxtral, a new open-source SOTA transcription model, I got to work.

First Attempt - Python

Since the Hugging Face Python library already had Voxtral implemented in it, and Python developers often implement AI models first, I decided to build the proof-of-concept app using Python.

It worked well; however, Python is notorious for being hard to package. And let's not even talk about asking someone to install a 5GB PyTorch library and other dependencies just to get things running. So I had to rethink my strategy.

If I am going to make something useful for myself, I want to make it as useful to others as well. 2026 will be the year of the Linux desktop 😉, and so I wanted new users to be able to install SuperSTT as easily as possible.

Second Attempt - Rust

Rust excels at packaging and shipping things, and, of course, the COSMIC DE, my daily driver, is already built on Rust, making it easier for me to build a native UI later.

However, Rust is not known for supporting AI models (at least not yet). So, although STT models like Whisper were already implemented in Candle (Rust's version of Pytorch + Hugging Face), there was no support for Voxtral yet.

That meant that I had to implement the AI model myself 😵‍💫, which was intimidating, but super exciting, because I had never dealt with AI Rust code before. I will save you some time and skip this part, even though I really wanted to share it. It took 2 weeks to implement Voxtral in Candle and another 2 weeks to get it approved for production.

The rest of the app is much simpler, so once Voxtral had been implemented in SuperSTT, we were ready to use it to transcribe with a shortcut. However, there were no visual indicators, no easy way to change the transcription model, or update other settings.

SuperSTT Service and UI Clients

I built SuperSTT as a service that runs on systemd. It loads the AI model once when you log in to your system. It exposes a protocol so that any client apps can communicate with the service to update its settings or receive raw audio data (for visualizations).

I built two UI apps:

1. A settings app using libcosmic that should work on any desktop environment.
2. An applet especially made for the COSMIC panel that displays visualizations.

Anyone can build a client for their DE if they really want to (e.g., a Gnome extension, a KDE Widget) and continue to use SuperSTT.

https://github.com/jorge-menjivar/super-stt

I want to be cool like Vitalik Buterin. I want to have my own site to post my thoughts. But wait, I also want to showcase my projects. I want to introduce any web travelers that pass by my site to the things that I do. One important thing is that any good site needs RSS support and SEO optimization so Google can find it.

This sounds like a lot of maintenance work. I'll need to keep the RSS feed up to date and generate a new sitemap whenever I create a new post or project. I don't have time for that. I just want to show what I'm working on and update people once or twice a year. I'm not a professional writer, I write at a 10 year old's level. I don't need a whole CMS for this. And I definitely don't want to pay monthly for one. I just need to write blogs and update my projects without managing anything else.

So I did what any lazy developer would do - let GitHub handle the hosting. I created GitHub Portfolio, the perfect solution for me. No worrying about servers or CMS. It automatically fetches my GitHub activity for my portfolio. All I do is write markdown files for blog posts. It handles the rest - RSS, sitemap, SEO, etc. Now I can focus on projects while it manages my portfolio and blog. Best of all, it's free since it uses Vercel hosting. You may be reading this from GitHub Portfolio or an RSS feed, but either way, it's thanks to GitHub.

You can set up your own site with GitHub Portfolio in 1 minute or less. It's open source and easy to customize however you want. Use it, break it, fix it, improve it - go wild!

That's it. Just wanted to share.