Download Wisp and send me feedback, please.
I had already been thinking about how I wanted a speech-to-text app that was independent of other apps. I mostly used Codex for dictation, but I kept running into two problems. Its transcription is slow, and whenever the service hiccupped, everything I had just said disappeared. There was no retry and no history, so I would often lose several sentences—sometimes entire paragraphs—of thought.
I was fed up. I wanted a local tool without another subscription, and open speech-to-text models had become good enough to make one possible. That was the impetus for building Wisp.
Over the weekend, I had food poisoning and found myself with extra free time to do nothing but explore and build.
Coincidentally, OpenAI decided to reset Codex limits twice, giving me nearly unlimited usage while I built Wisp, a speech-to-text app.
Wisp showing the latest transcription and time-saving statistics
This is the first project where I never opened Xcode and I never looked at the code in an IDE. It seems to work just fine.
The biggest realization, and what has me switching from typing to dictation, is the time savings.1 Over a 12-hour workday, working on and off, I saved roughly two hours of typing by dictating instead. That is incredible, and one can only imagine how much it compounds over the course of a year.
Beyond the numerous learnings while building the app, I came across Phil's blog. It is a great resource for Apple development thinking.
Building the App
The app was built entirely using Codex, which at times called Opus for help with the UI. At the moment, it's quite clear that Anthropic has a monopoly on models that understand how to use and structure an interface.
I also made two custom sounds for Wisp: Wisp Engage when recording starts and Wisp Out when it finishes. Each began as a sample from a larger file in an open-source sound library, then was pitched and edited to feel like a sound coming in and a sound going out. Together, they create an audible metaphor for engaging with the transcription service, almost like sending and receiving a message.
ChatGPT comparing Parakeet with other speech-to-text models
Wisp uses an open-weights model from NVIDIA called Parakeet. At a little over 600 megabytes, it transforms audio into text nearly instantly on a modern MacBook Pro.
Wisp also uses a couple of small models to improve vocabulary and distinguish speech from noise. Text cleanup happens through a post-processing model, S1 Mini, provided as open weights by Superwhisper, a company that builds a competing product.
Standing on the Shoulders of Giants
All of this is possible because of three things.
First, OpenAI has created agents and a level of abundance that allow you to build software that matches your imagination. The main limitation is your own agency to see the work through. A year ago, frontier models were not able to produce working macOS software at this level in a single day.
Second, there is an open-weights ecosystem. Even companies with a vested interest in their own market still release models that anyone can build with and use. These models may lag the frontier, yet they are good enough to border on great.
Finally, Apple has quietly spent an enormous amount of time investing in operating-system-level accessibility. I think it may be the only company in the history of computer technology to make that investment at this scale. This accessibility framework allows apps like Wisp to listen for speech and insert the resulting text into other apps. You can select a field almost anywhere, speak, and have your words land inside it.
There are limitations. Password fields are off-limits, and some apps built on Chrome do not expose their accessibility tree to the operating system in the same way. Workarounds exist and are not especially difficult, though those apps require a different path.
macOS App Performance
I used Codex to drive a performance-improvement loop after several views began hanging for one to several seconds following a couple of days of use. We cut a number of things from the runtime path and ditched SwiftUI for the affected views, a familiar pattern among macOS developers.
Wisp view transitions improving from multi-second hangs to millisecond load times
Together, those changes produced speedups of more than 99%. Every view now loads in milliseconds, sometimes in less than a millisecond—fast enough that the instrumentation struggles to measure whether a change made any further improvement.
Footnotes
-
This article's content was dictated to Codex via Wisp. ↩