What transcription really costs, and how to work it out before you sign

September 15, 2026

The question that always arrives is the same one, and it almost never has a clear answer on a provider's website: what is this going to cost me per month?

It can be estimated fairly precisely, and it's worth doing before signing anything.

First, the unit

Billing is per second of audio processed, not per request.

It sounds like a detail and it changes how you design the system. Ten six-second requests cost the same as one sixty-second request. There's no penalty for splitting, for retrying, or for making many small calls — and therefore no reason to contort your architecture to batch things that your business keeps separate.

The opposite model, charging per request, pushes you to accumulate work to "make the call worth it". That almost always means worse latency for your user and more complexity in your code, in exchange for nothing that benefits you.

How to estimate yours

The arithmetic is boring, which is why it works:

1. How many minutes of audio per month. Don't guess: pull them. If it's a phone system, they're in the call reports. If it's meetings, it's the calendar.
2. Which services over each minute. Just transcribe? Transcribe and summarize? Translate too? Each one consumes on its own account.
3. Multiply. There are no per-request minimums and no hidden rounding.

One detail people overlook: /v1/summarize moves several engines. It transcribes, analyzes tone, profiles the speaker and separates speakers, all over the same audio. It works out cheaper than asking for them separately, but it isn't "free with the transcription": it consumes what it consumes, and the response carries the breakdown by stage so you can see it.

The trick that saves you money before you send anything

Normalize the audio to 16 kHz mono before uploading it.

The engine is going to resample it to 16 kHz mono anyway. If you send a 48 kHz stereo WAV, you're paying bandwidth and upload time for information that's going to be thrown away — and you hit the maximum file size much sooner.

ffmpeg -i original.wav -ar 16000 -ac 1 -b:a 64k ready.mp3

Two hours of audio like that weighs about 58 MB. The same two hours as 48 kHz stereo WAV would be 1.3 GB. It doesn't change what we bill you — that goes by seconds — but it changes your transit bill, your upload time, and the odds of something dying halfway.

Don't wait for the end of the month to know where you stand

Every response tells you:

• X-Audio-Duration — the seconds billed for that request. It isn't in the body, only in the header.
• X-Credits-Used-Monthly and X-Credits-Remaining-Monthly — how your cycle allowance is doing.
• X-Credits-Overage — true if you've gone over: you keep being served, as billable overage.

With that you can chart your usage on your own dashboard from day one, without depending on us to show you a graph.

And a consequence of headers describing limits: a limit header only appears if there is a limit. On a plan with no allowance cap you won't see any of the credit ones. It isn't a bug — there's nothing to count.

And the way to really save

If your audio ends up feeding a language model from another provider, the big saving isn't in what you pay us: it's in what you pay them. Sending the summary instead of the transcript is twenty to thirty times fewer input tokens.

The prices and limits of each plan, with their equivalents in hours of audio, are in Plans — visible without signing up.

Anything to add or correct? Write to support@uttera.ai. If you correct us, we edit the post and credit you.

← All posts