Cloud transcription would have cost $1,900. We spent $20.

We needed transcripts of an entire sales-call backlog so the rest of a larger project could read what actually gets said on calls. Not a sample. Every call of three minutes or longer across six months: 91,628 of them, about 12,588 hours.

The whole thing ran in one overnight pass, roughly nine hours, with zero failed calls, on ten ordinary CPU servers rented by the hour. The infrastructure bill came to about $20. The same work on Google's Gemini API, the default cloud choice, would have cost around $1,900. Cheaper cloud services and a rented GPU sit in between, but none came close to $20.

Two decisions got us there. Most calls were recorded on two separate channels, so splitting the channels told us who spoke without any speaker model. And a fast open-source Chinese model runs well on plain CPUs, so we skipped the GPU entirely.

The simplest path is a hosted speech-to-text API. Point it at each file, get a transcript back, pay per hour of audio. For a one-off job it is hard to beat on effort. The problem is only the price at this volume.

We priced it against Google's Gemini 2.5 Flash, the model most people reach for by default and the one that tops the public accuracy leaderboards. It is billed through the Gemini API at $1.00 per million tokens of audio input, and it turns about 32 tokens into every second of sound. That makes the archive roughly 1.45 billion input tokens, near $1,450, before the model writes a word back. Add the transcript it returns, at $2.50 per million output tokens, and the bill lands around $1,900.

There is a catch the leaderboards hide: they are English. On Chinese, the language of these calls, Gemini is one of the weakest engines rather than one of the strongest. An independent per-language benchmark scores it around 19 on Chinese character-error-rate, against roughly 4 for the best dedicated engines; the open-source Chinese model we used sits in that same low-single-digit range. So the default cloud model was not only the priciest option here, it was also one of the least accurate on the audio we actually had.

Gemini is also one of the pricier options, and cheaper sticker prices exist. Hosted Whisper on Groq lists at about $0.04 an hour, which would come to about $500 for the archive. You cannot actually get there, though: Groq's self-serve tiers are rate-limited, and a job this size needs an enterprise agreement. The cheapest cloud we could realistically have run at this volume was Gemini's own asynchronous batch API, about $0.07 an hour, or roughly $900. Either way, we kept going. This was a one-off, offline job with no real deadline, and even $900 of cloud felt like paying for convenience we did not need. We benchmarked renting a GPU and running the models ourselves, a few hundred dollars, cheaper still, but not the floor.

A transcript is not much use if you cannot tell the two speakers apart. Working out who spoke when is a separate job from turning speech into text. It is called speaker diarization, and it is often the expensive half: the models that do it well are heavier, slower, and happiest on a GPU.

The lucky break was in the recordings themselves. Most of the calls were saved in stereo, with the two sides of the conversation on separate channels: one voice on the left, the other on the right. When the audio is already split like that, you do not need a model to guess who is talking. You split the file in two and transcribe each side on its own. The channel is the speaker label.

That covered about 96% of the archive. Only the mono calls, the ones recorded as a single mixed channel, needed a real diarization model to pull the voices apart. Shrinking the hard, GPU-friendly part of the problem from 100% of calls to 4% is most of why the whole thing fit on cheap hardware.

Before committing, we ran four open-source stacks against the same recording and measured them: a Chinese model called Paraformer paired with a speaker model called CAM++, and three combinations built on Whisper, Qwen3, and FireRed. We tested the hard case on purpose, a recording with six people talking where the model has to keep the voices apart, not the easy two-channel calls.

On accuracy they nearly tied: three of the four placed all six speakers correctly. Speed is where they split. Paraformer does transcription and speaker labeling in a single pass, while the others need two separate passes, so it finished the recording in about a third of the time. Same answer, third of the compute. Faster and cheaper, and it runs on CPU, so it won.

We also checked it against the cloud model on that same test. The cloud model was a little more accurate, 90% against 85% on speaker attribution. That is a real gap, and on a job where every transcript had to be trusted individually we might have paid for it. For a bulk archive, read once to find patterns across tens of thousands of calls, five points of speaker accuracy was not worth close to a hundred times the cost.

The setup was deliberately plain. A small coordinator server held a work queue: workers claimed calls, transcribed them, and reported back. If a worker died mid-call its claim expired and another worker picked the call up, so a machine could vanish without losing work. Ten boxes, six of them sixteen-core, chewed through the queue at eleven to thirteen thousand calls an hour. On the stereo calls that was about fourteen times faster than real time, which is how 12,588 hours of audio cleared in about nine.

The part worth telling is that we did not build this by hand. The coordinator, the workers, the queue, the channel-splitting, the retry logic: a coding model, Claude Fable 5, designed and wrote all of it. The same model ran the job, too. It launched the machines, watched the queue, and worked through the problems that came up overnight.

Ten servers for nine hours, billed by the hour, came to about $20. That is about a sixth of a cent per hour of audio.

Set the routes side by side and the gap is not subtle. The default cloud model runs about 95 times our bill. Even the cheapest cloud we could actually run at this volume is around 45 times it, and still more than renting a GPU. Splitting the channels and running on CPU beat every hosted option, speaker labels included.

If you have a large backlog of audio to transcribe, and you can read it overnight instead of in real time, the default cloud price is not the price you have to pay. The savings did not come from a secret model. They came from looking hard at the data before reaching for infrastructure: the recordings were already split by speaker, so the expensive part of the problem mostly did not exist, and once it was gone a cheap machine could do the rest.

The trades are real and worth saying plainly. A cloud API is less work, needs no servers to babysit, and was measurably more accurate at telling voices apart in the hardest case. Running it yourself means owning the operational surprises, and if your audio is a single mixed channel you are back to paying for diarization, which is exactly where a GPU starts to earn its keep. The lesson is not that open-source always wins. It is that the cheapest option is often sitting in the shape of your own data, if you check before you buy.

It is also why we are not sharing the code. It would not help you much. There is not a lot of it, and it is the kind of thing a capable model will write again, correctly, from a clear brief. A model built and ran this one. The reusable part is not a repository, it is knowing what you want and having a plan to get there: split the channels, drop the model you do not need, rent cheap machines by the hour, run overnight. Give a model that, and it builds and runs the rest.