Short answer: Choose the speech-to-text API that produces the lowest cost per accepted transcript on your startup's own EU workload. Don't select from a headline per-minute rate: run a fixed audio corpus, enforce one quality bar, verify regional and retention requirements, and reconcile actual billable units before making the call.
That's the shortest defensible answer. A public price is an input, not a result.
The practical data flow is straightforward: an immutable audio manifest enters a thin provider adapter, each raw response is archived, a normalizer emits one internal transcript shape, and an evaluator scores delivery, quality, latency, and cost. The application sees only that internal shape. This keeps a notebook experiment useful when the integration moves into production, and it prevents a provider-specific response field from becoming architecture.
How should an EU startup compare speech-to-text API per-minute pricing?
Start by making every candidate solve the same job. OpenAI, Deepgram, AssemblyAI, and Google Cloud appear in the buying question, but their names don't define comparable configurations. Batch and streaming modes solve different latency problems; language, channel handling, diarization, data location, retention, and commercial terms can change the relevant offer. Record the exact mode and EU configuration beside the quote date. Never place a batch rate from one service next to a streaming rate from another and call the table done.
The decision unit should be an accepted transcript, not a submitted minute. Define acceptance before running anything: the transcript was delivered, required domain terms survived, and the artifact meets the downstream task's needs. Captions may care about timestamps. Support triage may care about product names and ticket numbers. A RAG index can look healthy while retrieval fails because the rare terms carrying the query intent were transcribed incorrectly.
I prefer an eval contract with six fields: fixture ID, audio duration, expected terms, delivery evidence, billable quantity, and latency. It's small enough for a notebook, but explicit enough to become a scheduled regression test. I'm not sure a universal word-error-rate threshold would tell you much across these applications; a labeled corpus and downstream retrieval eval would resolve that uncertainty for your workload.
EU eligibility is a gate, not a score. Write down the required processing location, retention period, deletion behavior, and any legal review outcome. If a candidate can't meet a mandatory requirement, a lower rate doesn't rescue it.
Run the comparison before reading the trade-offs
The following standard-library Python example evaluates normalized results. It deliberately accepts billing units and rates as data. That matters because this article has no verified, like-for-like regional quotes, and embedding a guessed rate in code would turn a useful harness into stale misinformation.
from dataclasses import dataclass
from decimal import Decimal
from typing import Callable
@dataclass(frozen=True)
class AudioFixture:
fixture_id: str
duration_seconds: Decimal
expected_terms: frozenset[str]
@dataclass(frozen=True)
class TranscriptResult:
fixture_id: str
text: str
delivered: bool
latency_seconds: Decimal
billed_units: Decimal
def term_recall(fixture: AudioFixture, result: TranscriptResult) -> Decimal:
if not fixture.expected_terms:
return Decimal("1")
words = set(result.text.casefold().split())
matches = sum(term.casefold() in words for term in fixture.expected_terms)
return Decimal(matches) / Decimal(len(fixture.expected_terms))
def evaluate_candidate(
fixtures: list[AudioFixture],
transcribe: Callable[[AudioFixture], TranscriptResult],
rate_per_billing_unit: Decimal,
minimum_term_recall: Decimal,
) -> dict[str, Decimal | int]:
results = [transcribe(fixture) for fixture in fixtures]
accepted = [
result
for fixture, result in zip(fixtures, results, strict=True)
if result.delivered
and term_recall(fixture, result) >= minimum_term_recall
]
total_cost = sum(
(result.billed_units * rate_per_billing_unit for result in results),
start=Decimal("0"),
)
accepted_seconds = sum(
(
fixture.duration_seconds
for fixture, result in zip(fixtures, results, strict=True)
if result in accepted
),
start=Decimal("0"),
)
return {
"submitted": len(results),
"accepted": len(accepted),
"accepted_audio_seconds": accepted_seconds,
"total_cost": total_cost,
"cost_per_accepted_transcript": (
total_cost / Decimal(len(accepted))
if accepted
else Decimal("Infinity")
),
}
Each adapter is responsible for submitting one fixture and returning the normalized fields. Keep authentication, upload mechanics, polling, and vendor response parsing inside that adapter. Keep scoring outside. With that boundary, changing a provider or service mode doesn't change the acceptance logic, and changing the scorer doesn't require another transcription run if raw responses were retained under the permitted data policy.
Use Decimal, not binary floating point, for rates and totals. Capture the currency and the rate's effective date in the experiment record even though the compact example omits them. If billing uses rounded intervals or another unit, the adapter should report the actual billable quantity rather than deriving it from file duration. Then reconcile the aggregate against the invoice or usage export.
One subtle failure deserves a test of its own. I've had a notebook count an HTTP 200 as completion, only to find the downstream index empty 4 hours later. A 200 proves that a request completed; it doesn't necessarily prove that an asynchronous transcript reached a terminal state and can be retrieved. Model submission and delivery separately — this distinction is tiny, but operationally important. For synchronous calls, a normalized transcript can be delivery evidence. For asynchronous jobs, require the terminal state and retrievable artifact. For callbacks, store an idempotency key before counting the fixture as accepted.
Short version: verify the side effect.
Retries belong in the cost ledger too. Preserve every attempt and its usage metadata, while deduplicating accepted output by your fixture ID. Otherwise a retry can vanish from cost while a duplicate callback inflates successful output. A 429 response is a capacity signal for the client path, not permission to erase an attempt; use bounded backoff, retain request identifiers, and let the experiment show the latency and usage actually observed.
The denominator changes the cheapest answer
Suppose candidate A has a lower advertised rate but misses the required terminology more often. Candidate B has a higher input rate yet clears the fixed acceptance threshold on more files. Comparing submitted minutes favors A; comparing accepted transcripts may favor B. The point isn't that B always wins. The point is that the denominator must represent usable output.
Keep the arithmetic auditable:
| Measure | Calculation | Why it exists |
|---|---|---|
| Acceptance rate | accepted fixtures / submitted fixtures | exposes unusable output |
| Cost per accepted transcript | all observed transcription cost / accepted fixtures | connects spend to delivery |
| Cost per accepted audio hour | all observed transcription cost / accepted audio hours | compares corpora of different sizes |
| Downstream token usage | tokenizer count by pipeline stage | catches cleanup and summarization cost |
| Latency distribution | observed completion times | prevents a cheap but unusable SLO |
Do not fold taxes, free allowances, commitments, currency conversion, and minimum charges into one unexplained “effective rate.” Give each a column, with the conversion timestamp where relevant. Run low, expected, and high volume scenarios rather than averaging them. Your mileage may vary as the audio mix and account terms change.
Prompt cost sits downstream of transcription but still belongs in the system budget. Cleanup, summarization, evaluation, and RAG ingestion can consume tokens even when the audio API does not. Count each stage with the tokenizer appropriate to that model. The official tiktoken library supports BPE tokenization for compatible OpenAI models, while LangChain's ChatOpenAI integration documents one Python integration surface; neither source establishes speech pricing, so don't use either as a proxy for it.
This is also why I wouldn't publish a numeric winner from the available evidence. No current rates, matching service modes, EU configurations, account terms, or corpus results are established here. The honest output is a method that produces a local answer after those inputs are captured.
Where this method stops being enough
The catch is speed. A controlled corpus, privacy review, invoice reconciliation, and downstream eval take longer than sorting four rows on pricing pages. This method is not suitable when you need a disposable prototype and the transcript has no material quality, retention, or delivery constraints; in that case, use the simplest eligible integration and postpone procurement work until the workload exists.
It also won't make a single provider optimal for every path. A live assistant and an overnight archive have different latency budgets. If one internal interface cannot express both without hiding material behavior, keep separate adapters or even separate service selections. Portability is useful, but a lowest-common-denominator abstraction can erase streaming events, speaker information, or usage evidence that the product genuinely needs.
Avoid oversized abstractions early. The stable application contract usually needs four operations: submit audio, observe status, retrieve normalized text, and read usage metadata. Archive raw payloads only as long as policy allows. Add fields when an eval or operational requirement demands them, not because every candidate exposes them.
Operate the choice as a regression test
Move the notebook into a scheduled Python job before the chosen path becomes invisible infrastructure. Version the fixture manifest, adapter, normalizer, and scorer. Record configuration, quote date, region, retention setting, raw billable units, latency, and artifact hashes. Monitor delivery rate, acceptance rate, cost per accepted transcript, and latency percentiles; averages alone can hide the language or audio condition your users depend on.
The operational checklist is a sequence, not a wall of boxes. First, confirm consent plus processing, retention, and deletion requirements with the people who own privacy decisions. Next, freeze a representative corpus and acceptance rules, then capture current comparable offers for the exact service modes. Run every eligible adapter against identical fixtures, reconcile usage, and inspect false passes and false failures. Finally, select against the predeclared gates, launch with a limited cohort where policy permits, and rerun the harness whenever models, language mix, product requirements, or commercial terms change.
No single metric gets veto power over reality.
The resulting decision may be less exciting than a “cheapest API” leaderboard, but it is reproducible. More importantly, it survives the trip from notebook to production without asking the application team to reinvent evaluation, billing reconciliation, and delivery observability for every integration.
Top comments (1)
For speech-to-text, cost per minute is only half the decision. I would also track correction time, language/domain accuracy, data residency, and whether timestamps are good enough for the downstream workflow.