← BlogFor developers

Why word caps exist, and why they don't have to

The design document is half-finished. You have forty minutes before it needs to go to the architect. Your hands are moving faster by voice, the thinking is flowing, and then, the dictation tool cuts off mid-paragraph. You hit the word limit. Now you're switching back to typing, the context breaks, and the clean prose becomes a fragmented outline you'll polish tomorrow morning. Tomorrow never comes.

Word caps are not technical limits. They are business decisions. Understanding the difference changes which tool you choose.

How voice tools make their money

The voice-to-text space has converged on a simple model: charge per transcription, cap the free tier, and hope the paid tier converts enough users to cover the infrastructure cost. Wispr Flow charges $14 per month with a 600-word free tier. Willow sets its free users at 10,000 words per month. Superwhisper, built by an indie developer, charges $8.49 one-time and still limits free transcription to prevent abuse.

The economic logic is sound if the transcription runs in the cloud. Every second of audio that gets sent to a remote server costs compute. You pay the LLM API, the hosting, the bandwidth. The overhead is real, and it scales. The only way to protect margin is to ration usage.

This is not a flaw in those products. This is how they chose to operate.

The architectural choice Recitey makes

Recitey runs Whisper, the OpenAI speech-to-text model, locally on your device. No audio leaves your machine. No variable cost per transcription. Whisper-large-v3 runs on standard GPU VRAM; the compute is a fixed cost built into the application, not a metered service.

This creates a structural difference: there is no economic reason to cap the free tier.

The word limit on Wispr exists because the ninth user transcribing a five-thousand-word design document costs them money. That user generates a fixed liability regardless of whether they upgrade or leave. The cap is a defense mechanism against arithmetic.

On Recitey, that same user running the same transcription costs nothing incremental. The infrastructure has already been paid. The free tier is not artificially limited; it is unlimited because there is no variable cost to meter.

This distinction is invisible to non-technical users. It becomes obvious to developers the moment you look at the pricing page.

What this means in practice

Marcus is a backend engineer at a Series B fintech in Stockholm. He writes design documents at 11pm, when everyone else is offline and thinking is clearest. His workflow is Cursor, Slack, Linear, and a Notion doc where design decisions accumulate. He has tried Wispr Flow. It works until the edge cases: a thirty-minute voice memo about payment settlement logic hits the 600-word cap twenty minutes in. He switches back to typing. The momentum is gone.

He considered Willow next. Same problem, different numbers. The cap is higher, but his longest design documents are 5,000 words. Willow's monthly allocation would require budgeting for design time, tracking usage, and rationing when he is in flow state. He stopped using it.

Marcus uses Cursor specifically because Cursor's tab-complete reduces the number of times he has to rewrite a prompt. He also refuses cloud-based transcription for code-related work. IP concerns. His settlement logic sits in design docs and PR descriptions, and it is not going to a third-party server.

Recitey's uncapped local transcription aligns with his actual constraints. No word counter in his head. No cloud handoff on sensitive context.

The hidden contract in pricing

When a tool caps your free tier, it is not just rationing a resource. It is saying: this resource is expensive, and we need to control who uses it freely. That statement is true or false depending on the architecture underneath.

Whisper is a 774-million-parameter model trained on 680,000 hours of multilingual audio. Running it locally is computationally expensive. But expensive does not mean it costs money every time you use it. The cost is paid once, upfront, in the application. After that, every transcription is free.

Knowing which tools have which architecture changes how you evaluate them. Wispr Flow caps because it is billing per transcription. That is not a bug; it is a business model. Willow's caps reflect the same structure. If you need unlimited transcription without monthly bills, those tools might not be your answer, regardless of how good they are.

This is not a Recitey-exclusive insight. Talon Voice, a dictation tool for developers and gamers, also runs locally and has no word limit. But Talon is built for a niche (voice coding communities, accessibility users), and the learning curve is steep. Recitey is built specifically for the developer-plus-writing workflow, and it runs on Windows.

Who this actually applies to

Developers and builders who voice-dictate long-form writing, design docs, architecture decisions, PR descriptions, Slack explanations of debugging process, benefit from uncapped transcription. The rhythm of voice writing requires flow state. A word cap breaks that rhythm.

If you are writing two hundred words per day in voice, the cap may never matter. Most SaaS pricing is built for that user.

If you are writing two thousand words per day in voice, you will hit it, and you will resent the tool for it.

Recitey is built for the second group. Not as a moral statement. As an architectural one.

The local architecture is also why there is no credit card required, no usage metering, no slow-down as you near your limit. The cost structure is different, so the user experience is different.

The tradeoff

Local transcription is not objectively better than cloud transcription in all cases. Cloud systems can offer real-time editing, multi-language support that improves over time as the model retrains, and higher accuracy on out-of-domain audio because the model is always learning.

Recitey chose local. That means accuracy is fixed. The model is Whisper-large-v3, which hits 96.3% word accuracy on LibriSpeech, the standard industry benchmark. It is very good and it does not improve. The tradeoff is: latency and privacy in exchange for a model that stops learning.

This tradeoff is the right one for developers who voice-dictate technical writing. You need predictable latency, not cloud round-trips. You need code IP to stay on your machine. Accuracy at 96% is sufficient; accuracy at 97% from retraining on your code documents is not worth the architectural change.

The closing point

The free tier without a word counter is not a marketing gesture. It is a statement about what the product is. It is local. It is offline. It has zero variable cost per use. Everything else follows from that choice.

When you see pricing that does not make immediate sense, uncapped, no metering, no monthly limits, look at the architecture. The pricing is telling you something about how the product actually works.

More posts
Keep reading

More like this.

  1. For developers

    Stop Hitting Word Caps in Your Design Docs

    Marcus is spending 11pm writing a design doc about payment settlement for a new feature. He's speaking clearly, the tool's...

  2. For developers

    The design doc that never got written

    It's 11 PM. Marcus, a backend engineer at a fintech in Stockholm, is voice-dictating a design doc for a new payment settlement...

  3. For developers

    Local transcription changes what you can dictate

    You wrote the design doc perfectly on voice, then scrolled up and realized 1400 words in, you'd stopped mid-sentence. Not...

All posts →