Short answer: an EU startup should choose the speech-to-text API with the lowest invoiced cost per accepted minute, not the lowest number on a public rate card.
That answer is less tidy than a four-column price comparison. It is also the only comparison I would trust. A posted rate does not tell me whether a transcript passes the product's quality bar, whether retries multiply spend, or whether the approved data-handling setup is the one being priced. I want a test I can rerun, a bill I can reconcile, and one thin application contract. I don't want a spreadsheet pretending those details are equal.
The deciding constraint is acceptance. Price comes later.
Can an EU startup find the cheapest speech-to-text API from per-minute pricing?
No. Per-minute pricing can identify candidates for a test, but it cannot identify the cheapest deployable choice by itself. The useful denominator is accepted source minutes: audio minutes that produce text good enough for the actual task under the deployment and data-handling setup the team has approved.
Define “good enough” before making the first call. For captions, timing and omitted words may matter. A workflow that extracts order numbers may care more about names, digits, and negation. The threshold is product-specific, so I am not sure one universal accuracy score would settle either case. Your mileage may vary. What should not vary is the rule during a comparison; changing it after seeing results turns a benchmark into a preference generator.
This is where the procurement question changes shape. The team is no longer asking which vendor prints the smallest minute rate. It is asking which candidate clears four gates on the same corpus:
| Gate | Evidence to keep | Failure means |
|---|---|---|
| Transcript | Frozen, task-specific acceptance result | The minute is rejected |
| Execution | Non-empty text tied to a job ID | The task did not complete |
| Operations | Latency samples, attempt count, and final state | The path is not operable yet |
| Data handling | An approved account and processing setup | The candidate is not deployable |
Cost is calculated only across candidates that pass. For each one, divide the invoiced amount for the controlled run by accepted source minutes and report the rejection count beside it. Never hide the rejects. A system that needs more reruns or manual repair can look cheap only while those consequences live outside the denominator.
I learned the execution distinction from a sharp little failure: a call returned 200, the runner marked the job complete, and the intended side effect had not happened. A customer exposed it 6 hours later. That experience is why an HTTP status is evidence of transport, not evidence of a usable transcript. The harness must inspect the result, record a correlation identifier, and preserve enough metadata to replay the test without placing spoken content in ordinary logs.
Start with consented or synthetic fixtures. Give them opaque IDs, measured durations, checksums, and labels for the conditions the product expects: clean and noisy recordings, short and long files, relevant accents or languages, realistic silence, and actual channel layouts. The point is not a huge academic corpus. It is a small versioned corpus that can catch a purchasing mistake. If a fixture or acceptance rule changes, bump its version and rerun every candidate.
For an EU deployment, do not treat “EU” as a decorative region selector. The owner of privacy and security should approve the intended account configuration, processing location, retention behavior, deletion path, and fixture consent before production-like audio enters the test. This article cannot decide which evidence a particular startup needs. It can insist that the same approved assumptions apply to every candidate.
No shortcuts here.
The constraint that changed the build
My first instinct with a developer tool is to benchmark time-to-first-call. I build CLIs and SDKs, so I count setup steps, configuration keys, mapping code, and the amount of glue left for the next engineer. Speech work makes that instinct incomplete. A five-minute demo proves that credentials, upload, and response parsing line up once. It says little about acceptance, timeout behavior, repeated work, invoice reconciliation, or the operational state a user sees.
The build therefore starts with an application-owned contract rather than a provider-shaped client. Each candidate adapter accepts the same fixture and returns a narrow result: text, a stable job identifier, attempt count, and elapsed time. Credentials and native response mapping stay behind the adapter boundary. The benchmark never invents a vendor URL, method, model, or billing rule. Those values belong in adapter contract tests and in the account-specific evidence gathered on the day of the run.
This boundary is deliberately boring — which is praise in CLI work. It also exposes config bloat early. Every native toggle that escapes into the benchmark becomes another flag, validation branch, snapshot, and support question. I add one only when a fixture demonstrates that it changes a product outcome.
Rate cards still belong in the research folder, but they are inputs rather than verdicts. Verify the current rate for the actual account, processing setup, model or tier, and workload. Record how that offer treats rounding, channels, silence, asynchronous jobs, and repeated attempts. Then reconcile the controlled run against the resulting invoice or billing export. I would not publish a numeric winner without that current evidence, and the sources available here do not establish speech pricing or EU processing terms.
Invoices win.
The smallest working TypeScript measurement
The core measurement does not need any vendor SDK. It needs normalized run records and an invoice total. Keeping network calls out of this script is intentional: adapters can be tested separately, while this calculation remains identical for every candidate.
type Run = {
fixtureId: string;
sourceSeconds: number;
accepted: boolean;
attempts: number;
elapsedMs: number;
};
type Summary = {
totalRuns: number;
rejectedRuns: number;
acceptedMinutes: number;
invoiceAmount: number;
costPerAcceptedMinute: number;
};
function summarize(runs: Run[], invoiceAmount: number): Summary {
if (!Number.isFinite(invoiceAmount) || invoiceAmount < 0) {
throw new Error("invoiceAmount must be a non-negative number");
}
for (const run of runs) {
if (!run.fixtureId || !Number.isFinite(run.sourceSeconds) || run.sourceSeconds <= 0) {
throw new Error("each run needs an ID and a positive source duration");
}
if (!Number.isInteger(run.attempts) || run.attempts < 1) {
throw new Error("attempts must be a positive integer");
}
if (!Number.isFinite(run.elapsedMs) || run.elapsedMs < 0) {
throw new Error("elapsedMs must be non-negative");
}
}
const accepted = runs.filter((run) => run.accepted);
const acceptedMinutes = accepted.reduce(
(total, run) => total + run.sourceSeconds / 60,
0,
);
if (acceptedMinutes === 0) {
throw new Error("cannot price a candidate with zero accepted minutes");
}
return {
totalRuns: runs.length,
rejectedRuns: runs.length - accepted.length,
acceptedMinutes,
invoiceAmount,
costPerAcceptedMinute: invoiceAmount / acceptedMinutes,
};
}
Feed it one record per final fixture run and the billed amount attributable to that controlled batch. Keep raw latency and attempt samples beside the summary instead of compressing everything into a pleasant average. Averages conceal the slow calls users remember, and a total attempt count makes retry amplification visible without claiming a billing rule that has not been verified.
The accepted boolean must come from the frozen evaluator, not from non-empty text alone. Non-empty text is a useful execution assertion; it is a terrible accuracy metric. The evaluator might compare a reviewed reference, require critical terms, or apply another rubric tied to the product. The harness should store the evaluator version with each result so that two runs remain comparable.
One more trap: do not estimate duration from transcript length. Measure the audio. Text tokenization and chat-model integration are different concerns, and their tooling does not establish how an audio service bills a minute. Mixing those units creates a precise-looking number with no procurement value.
What I would change at scale, and where this method stops
After the prototype, I would put a queue between upload and transcription, create application-owned idempotency keys, cap attempts, apply jittered backoff, and route exhausted work to review. User-visible states should distinguish uploaded, processing, completed, and failed. Operational measurements should cover queue delay, transcription latency, attempts, empty-output rejection, accepted minutes, and reconciled cost. Contract tests can replay a tiny consented fixture against every enabled adapter in staging, while a scheduled run uses the larger corpus to reveal changes in quality, latency, or effective cost. Transcript bodies stay out of default logs; correlation metadata is usually enough to trace the flow. This is the long paragraph because operations are where a neat purchasing table meets reality, and because every missing state eventually becomes glue in a CLI, a dashboard, or an on-call note.
The catch is that the common adapter erases specialized controls. It is not suitable when streaming behavior, speaker separation, timestamps, or another native capability defines the product. In that case, keep the native interface and accept the coupling; forcing it through the narrow contract would make the benchmark easier while making the product worse.
The full comparison is also poor value for a low-volume internal tool whose transcription spend is immaterial. Pick any candidate that clears the quality and data-handling gates, keep the boundary replaceable, and revisit the decision if volume or requirements change. For a latency-sensitive live experience, accepted cost per minute is still useful, but it cannot overrule a latency objective. For a team without an approved way to test production-like audio, stop and fix fixture governance first.
There is no permanent cheapest provider in this method. There is a reproducible decision: among candidates that pass the same acceptance, operations, and EU data-handling gates, select the lowest reconciled cost per accepted minute, then record the adapter complexity the team has agreed to own. That's less exciting than a leaderboard. It is much harder to fool.
References
These sources cover text tokenization and a chat-model integration. They do not substantiate speech-to-text rates, billing units, or EU deployment terms, which is why this article makes no numeric vendor-price claim.
Top comments (0)