Why we started with push-to-talk
A small interaction boundary makes dictation more predictable, more private and easier to fit into the applications people already use.
Voice software often begins by asking for a destination: open this editor, start a new note, organise the result here. We started with a smaller job. Hold a key, speak, release it, and put the cleaned-up text wherever the cursor already is.
That boundary defines Capstan. It is not trying to become the place where writing lives. It is an input instrument for the software a person has already chosen.
A keypress makes intent explicit
Continuous listening creates difficult questions. When does an utterance begin? Which speech is directed at the computer? What should happen to audio that was captured but not intended as input?
Push-to-talk replaces inference with a physical signal. The key going down begins the capture. The key coming up ends it. The person can see and feel the boundary, and the product does not need to monitor the room while waiting to guess.
That explicit interval is useful for privacy as well as control. Audio only needs to exist for the requested operation. The latest dictation can be held briefly for a correction or replay without turning every recording into a permanent archive.
The destination already has context
Text fields know where the words belong. A reply box has the conversation around it. A document has its formatting and history. A task manager has the project and due date. Rebuilding those contexts inside a dictation product would create another inbox and another place to organise.
Inserting at the current cursor lets voice behave more like a keyboard. The dictation layer can focus on capture, transcription and cleanup while the destination remains responsible for the work itself.
This also keeps the product honest. A focused tool should be able to complete its job and get out of the way.
Small interactions still cross deep systems
The visible gesture is simple, but it passes through global keyboard events, microphone permissions, audio conversion, speech recognition, text cleanup, accessibility APIs and the focus model of another application. Each boundary has platform-specific behaviour, and some cannot be proved by unit tests alone.
The macOS implementation is used in real work. The Windows implementation is complete through its platform-neutral layers, CI tests and published self-test, but it still needs its first physical keyboard, microphone and foreground-application pass on real Windows hardware. That distinction matters: a build can prove structure without proving the final human interaction.
Starting with push-to-talk keeps that interaction testable. There is a definite input, a visible state change and a concrete output destination. It gives us a narrow path to make reliable before expanding what voice can do after capture.