Skip to content
SpeakribeGet Speakribe
Use case

Dictation for Claude

Claude rewards context. The more of the situation you give it, the better the answer. That makes prompt length the bottleneck, and prompt length is exactly what dictation fixes.

Why it helps here

You know the background that would make the answer good: the constraints, what you already tried, why the obvious approach is wrong. Typing all of it is a paragraph of work before you get anything back, so most prompts get sent underspecified.

Context becomes cheap

A spoken paragraph takes about fifteen seconds. Once background costs that little, you stop rationing it, and the answers improve accordingly.

Edit before you send

Text lands in the prompt box, so you can restructure or trim it, unlike a spoken conversation, which commits you to your first phrasing.

The transcription step is local

Your prompt is turned into text on your Mac. What you send onward is your decision.

Things people say into Claude

  • Here's the situation, then I'll ask the question. We have a monorepo with two apps sharing a component library, and the build is getting slow.
  • Review this plan and tell me what I'm missing, especially anything that would only show up at scale.
  • Rewrite this in a plainer register, keep the structure, and don't lose the caveat in the third paragraph.
  • I've tried two approaches and both failed for different reasons. Let me describe both, then suggest a third.

Questions people actually ask

Does it work in the Claude desktop app and browser?
Both. Speakribe types into the focused field, so it does not care which.
Can it keep up with a long, rambling prompt?
Yes. It is built for continuous natural speech and adds punctuation as it goes, so a long thought comes out as readable paragraphs.
Does it work in Claude Code in the terminal?
Yes. Speakribe types wherever the cursor is, terminal included.

Ready to stop typing?

One payment. Every future update included.