I use voice-to-text constantly. I dictate prompts when working with AI, draft longer thoughts when typing feels too slow, and fire off messages to friends without forcing my thumbs through several paragraphs on a phone.

The technology for this is not new, but the experience has often felt strangely compromised. Many transcription tools want another subscription. Others send audio to a closed-model API, which introduces a recurring cost and means trusting yet another service with my voice recordings. Even when a product works well, I am usually adapting my workflow to whatever its developers decided to build.

Recently, I tried a different approach: I built the version I wanted for myself.

It runs locally on my Windows computer, activates from a keyboard shortcut, and all it uses is an NVIDIA RTX 4060 Ti with 8 GB of VRAM – no special Mac M5 chips or top of the line gaming cards. The everyday transcription path is fast enough that I barely think about it. When it makes a mistake, a second shortcut I’ve created reprocesses the saved audio with a more capable model and replaces the original text.

This article, fittingly, began as a voice transcription using that system.

The problem: I want to speak wherever I can type

Voice-to-text is most useful to me when it disappears into the background.

I do not want to open a dedicated application, press through several menus, export a file, and paste the result somewhere else. I want to place my cursor in any text box, press a shortcut, speak, press the shortcut again, and have the words appear.

There are two use cases where this makes an especially large difference for me.

The first is working with AI. A detailed prompt can take several minutes to type but may take less than a minute to explain aloud. Speaking also changes how I communicate. I tend to provide more context, explain the motivation behind a request, and describe the outcome I actually want instead of compressing everything into terse instructions.

The second is ordinary communication. Sometimes I want to send someone a thoughtful message without stopping to type it all on a phone or keyboard. Dictation makes that easy—as long as the delay between speaking and seeing the result is short enough.

That last requirement matters. A transcription tool can be technically impressive and still feel bad if every interaction ends with an awkward wait.

The inspiration: TypeWhisper on my Mac

TypeWhisper showed me how good this workflow could be. I have used it on my work MacBook, where local transcription fits naturally into a system-wide dictation experience. It was a major inspiration for this project and remains a great product.

My experience on my personal Windows computer was less satisfying. When I tried to reproduce the same workflow there, Windows support felt less mature and the time between finishing a recording and receiving the transcription was too long. That delay was enough to break the feeling of immediacy I wanted.

This was not really an indictment of TypeWhisper. Supporting different operating systems and hardware configurations is difficult, and a polished application has to make choices that work for many people.

But that was also the opportunity. I did not need a product that worked for everyone. I needed a tiny tool that worked for me, on one computer, with one graphics card, using two keyboard shortcuts.

Building the version I wanted with Codex

I brought the problem to Codex and asked whether we could prototype a local Windows dictation service.

The resulting system uses faster-whisper, an implementation of OpenAI’s Whisper speech-recognition models built on CTranslate2. Instead of sending recordings to an external transcription API, it loads the model directly onto my GPU and performs the work on my computer using CUDA.

The normal workflow is deliberately simple:

  1. I press Alt+Shift+Q to start recording.
  2. I press it again to stop.
  3. The audio is transcribed locally.
  4. A lightweight local punctuation pass cleans up sentence boundaries and capitalization.
  5. The result is typed into whichever application currently has focus.

The transcription model remains loaded in GPU memory, avoiding the delay of loading it again every time I speak. The punctuation model runs on the CPU and, once warm, adds only a few milliseconds of processing time.

The service also archives each recording as a WAV file for seven days. That archive became the key to making the system both fast and forgiving.

The smallest useful model beats the largest available model

My first instinct was predictable: use the largest and most capable model available. If large-v3-turbo produces better transcription, why not use it every time?

Because most of the time I do not need it.

We tested the much smaller English-only small.en model on real recordings. Across four clean dictations totalling almost two minutes, its output matched the archived Turbo results word-for-word while processing the audio at more than 70 times real time.

That changed the design. Instead of paying the latency cost of the large model on every interaction, the system now optimizes for the common case:

  • small.en is the default because it is fast and accurate for my normal dictation.
  • large-v3-turbo remains installed locally as the higher-effort fallback.
  • I decide when a recording deserves another pass.

If the first result is not good enough, I immediately press Ctrl+Alt+Shift+Q. The service retrieves the newest archived WAV file, retranscribes it with large-v3-turbo, and then runs the output through a tiny local Qwen3 model.

Qwen is not being asked to rewrite my ideas. Its job is narrow: restore punctuation and capitalization and fix obvious minor grammatical slips caused by stops, stutters, or corrections while I was speaking. Guardrails reject the cleanup if it changes protected details such as numbers, URLs, email addresses, or currencies, or if it rewrites too much of the original transcript. If the cleanup fails, the system falls back to the raw Turbo result.

Finally, the shortcut removes the original Small transcription and inserts the improved version. If I have changed applications while the slower pass is running, it safely copies the result to my clipboard instead of undoing text in the wrong window.

This gives me the interaction I actually want: speed by default, accuracy on demand.

A tool shaped around my actual use

The most satisfying part of the project is not that local transcription is possible. It is that the entire workflow reflects a set of small, personal preferences:

  • I prefer a toggle shortcut instead of holding a key while speaking.
  • I want the result inserted wherever my cursor already is.
  • I want recordings retained briefly so mistakes are recoverable, but not kept forever.
  • I want the fast model for ordinary speech and a deliberate escape hatch for difficult audio.
  • I want punctuation cleaned up locally without handing every transcript to a cloud language model.
  • I want failures to degrade gracefully instead of swallowing the transcription.

None of these choices is revolutionary. Together, however, they make the tool feel dramatically better because there is almost no distance between the problem I had and the software that solves it.

This is one of the most compelling things about coding with AI. I did not begin by evaluating which product had the closest feature matrix. I described the experience I wanted, worked through the technical constraints with Codex, tested the result, and refined the system around how I actually used it.

A relatively modest consumer GPU turned out to be more than capable. No recurring transcription bill was required. My recordings did not need to leave my computer. I did not need to wait for a company to prioritize my particular combination of Windows, NVIDIA hardware, preferred shortcuts, and tolerance for transcription errors.

What happens to software when everyone can build?

This experience leaves me wondering about the future of third-party applications.

Traditional software products are not going away. Most people will still value polish, reliability, support, synchronization across devices, thoughtful defaults, and the ability to install something without understanding how it works. Building and maintaining even a small personal tool still requires some technical comfort.

But the middle of the market may become much more difficult. A narrowly focused application that charges a subscription for wrapping an available model or external API will increasingly compete with users who can describe their needs to an AI coding agent and build a local alternative over an afternoon.

The most interesting outcome may not be millions of isolated personal applications. It may be what happens when those projects are published as open source.

Imagine thousands of people independently building their preferred version of the same small tool. One person solves low-latency transcription on Windows. Another designs a better safety check for AI cleanup. Someone else improves accessibility, multilingual support, or application-aware shortcuts. AI systems can help compare these implementations, identify recurring patterns, test competing approaches, and combine the best ideas into simpler shared architecture.

Personal software could become upstream research for public software.

That possibility feels optimistic to me. We may end up with more open-source tools, more software that runs locally, and more control over what our devices do with our data. The computer becomes less like a collection of products we rent and more like a machine we can continuously reshape around how we think and work.

I spend a lot of my life sitting at a computer. The idea that I can now explain a small frustration, collaborate with an AI to solve it, and end up with a tool tailored precisely to my habits feels like a meaningful change in what personal computing can be.