Rate limits are a cloud problem, not yours
Open the rate-limit table of any cloud AI provider and you find the same thing. A meter on everything. Requests per minute, requests per day, tokens per minute, tokens per day, and for speech-to-text even audio-seconds per hour.
It looks like a pricing detail. It is the shape of the whole arrangement. You are renting access to a machine you do not control, and the rent is metered in five different units at once. When you hit a ceiling, your work stops, and there is nothing you can do about it except wait or pay more.
The meter is the tax
A free or developer tier is generous enough to build a demo and tight enough that real use trips it. That is the point. The caps are not there to protect a server, they are there to move you up a plan. None of that is dishonest, it is just what renting looks like.
The part that gets missed is how much of your work never needed the cloud in the first place. Transcribing a voice note. Summarising a file. Refactoring a function. Translating a paragraph. A small local model handles all of that well, and a cloud provider would have metered every one of them.
Local-first changes what the meter applies to
Soriku runs on your own hardware first. A task that a local model can handle never touches a provider, so there is no requests-per-day ceiling and no tokens-per-minute throttle. The limit is your machine, and your machine does not bill you.
Speech-to-text is the clearest example. It runs locally on Whisper, so the audio-seconds-per-hour cap that a cloud provider puts on transcription simply does not exist here. See how local-first works for the longer version.
What this buys you
You stop planning your day around someone else’s ceiling. The heavy, mundane volume runs locally and for free, the cloud is there for the few things that need it, and you decide which is which. That is the whole idea behind smart routing.
Rate limits are real. They are just not your problem to carry, once most of the work runs on a machine you already own.