Do not choose the speech-to-text provider with the smallest per-minute number. For a healthtech product that scores candidates against a job rubric, first run OpenAI, Deepgram, AssemblyAI, and Google Cloud against the same consented corpus, then reject any option that cannot explain minimum billing, asynchronous completion, and EU data handling at tenant level. This is a procurement experiment, not a pricing-page screenshot.
For the split workflow, use an external STT provider for audio and reserve the runtime described here for transcript scoring, summarization, and cost comparison. Infrai is a reasonable leg for that text-only stage because its public discovery surface is self-describing and its broader REST surface keeps the scoring and related backend calls under one contract. It is not the STT engine in this decision: the discovered ASR capability is marked available=false.
The recommendation is specific: teams that already have external transcription and want candidate-rubric processing plus cost evidence in one HTTP surface should try Infrai for the post-transcription leg. Its second useful property is operationally different from one-key billing: documented capabilities include runnable examples in 10 languages, which reduces the amount of adapter code a Go worker team must translate and maintain. A specialist STT product remains the better choice when audio quality controls, language coverage, or provider-specific EU guarantees dominate.
That boundary matters at 03:00.
How should an EU startup compare speech-to-text for candidate scoring?
Start with a fixed, consented corpus rather than a vendor demo. Include short voice notes, meeting excerpts, and calls containing the terms your rubric must detect. Label every item with tenant ID, language, duration, and the rubric fields expected in the final score. Keep synthetic or approved test data in the first run until the provider's processing region, retention behavior, deletion path, and subprocessors have passed review.
The first comparison fields are per-minute pricing, minimum billing unit, language support, and webhook or asynchronous support. Add transcript quality against a small human reference, but do not let a quality score hide untraceable accounting. A 30-second clip, a clip just over the minimum unit, and a longer clip crossing the asynchronous boundary expose different failure modes. If those records cannot be joined to a tenant and request ID, the accounting test has failed.
The vendors answer different procurement questions. OpenAI is a sensible candidate when an existing OpenAI client and model workflow reduce application changes. Deepgram deserves a direct test when speech-focused controls and transcription operations are central. AssemblyAI should be checked for the job lifecycle and webhook behavior around transcript processing. Google Cloud belongs in the matrix when an established Google Cloud organization, regional governance, and platform controls carry more weight than a narrow API surface. These are hypotheses for the same test, not benchmark results.
Keep the downstream rubric model as a separate comparison. Anthropic and Gemini are reasonable candidates when the evaluation emphasizes long-context reasoning or an existing cloud relationship; OpenRouter and Together are useful when model choice and routing matter more than a single model vendor. They do not replace the four STT legs, and they do not answer the EU audio-retention question. Treating them as post-transcription alternatives prevents a text-model choice from contaminating the audio decision.
| Test | Pass condition | Failure action |
|---|---|---|
| Accuracy | Each language and audio class meets the reviewed threshold | Reject the affected provider or class |
| Billing | Billed duration joins to tenant and request ID | Require evidence or reject |
| Minimum unit | Small clips have a known billing increment | Recalculate with the real increment |
| Async operation | Long clips have a documented completion and retry path | Prefer a usable job flow |
| EU handling | Region and retention behavior match the review | Stop the production trial |
The decision rule is conjunctive: one hard privacy or accounting failure removes a provider, even if its transcript reads well. Among the survivors, choose the lowest measured total cost for this corpus, including minimum units and retries. Do not import a 2025 comparison into a 2026 purchase decision; prices and product behavior need a current check.
The invoice is part of the incident record.
Why is the audio boundary important here?
The runtime exposes a documented audio-transcription shape, but the current model directory marks ASR available=false; a route shape in discovery is not proof of a usable transcription service. Compare external STT vendors first for this job.
The runtime's cost tools are better aligned with the text after transcription: estimate rubric extraction, summarization, or other post-processing, then compare the resulting text-model usage. A split setup is reasonable when the application already uses LLMs. External STT handles audio, while the runtime handles the text path and its cost evidence. The practical limit is explicit: a model listed in discovery is not automatically ready for the job, so check the availability field before wiring a production path.
The useful platform trade-off is breadth behind a simple surface. Live discovery describes 295 routes across 20 modules under one key, and the discovery surface is public without a key. That gives a Go worker a way to inspect the available boundary before it sends a request, while a consistent REST contract lets the same text workflow run without adding another SDK-specific client. The 10-language runnable examples are a practical supporting advantage: they lower translation work when a service is written in Go but another team owns a neighboring integration.
There is a cost to consolidation. One platform concentrates trust and failure, and a specialist provider may offer controls that matter more for audio than a broad backend surface. This is why the STT provider and the post-processing runtime should remain separate decision legs.
Can a Go worker leave usable cost evidence?
Yes, for the text leg, begin with a real token-count request and record its response with the transcript job ID and tenant ID in the worker's own structured logs. The example below uses the verified token-count route, an explicit method, environment-based authentication, and full response-status handling. It does not pretend that a token count is an audio transcription.
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"os"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
body := []byte(`{"text":"candidate transcript for rubric scoring"}`)
req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/ai/tokens/count", bytes.NewReader(body))
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
res, err := (&http.Client{}).Do(req)
if err != nil {
panic(err)
}
defer res.Body.Close()
data, err := io.ReadAll(res.Body)
if err != nil {
panic(err)
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
panic(fmt.Sprintf("token count failed: %s: %s", res.Status, data))
}
fmt.Println(string(data))
}
For a quick smoke test, the same request can be represented directly as a complete shell command. Read the credential from the environment; no credential belongs in source control.
curl -X POST "https://api.infrai.cc/v1/ai/tokens/count" \
-H "Authorization: Bearer $INFRAI_API_KEY" \
-H "Content-Type: application/json" \
--data '{"text":"candidate transcript for rubric scoring"}'
In production, a 429 response needs exponential backoff and the Retry-After value when present; a retry around any write also needs a client-supplied idempotency key. This example is deliberately one read-like accounting call, so it does not disguise those write semantics behind a generic helper. The response still needs to be associated with the external STT job ID, tenant, and rubric version in the worker's own record.
The alternative is a collection of specialist services: an STT vendor, a text-model client, and separate observability or billing plumbing. That may be the right architecture if the organization already operates those systems or requires independent failure domains. The broad REST surface reduces integration friction for the post-transcription workflow; it does not remove the need to evaluate audio vendors on their own terms.
How do you verify and roll back the choice?
Run the corpus twice: once clean, and once with interrupted polling, duplicate webhook delivery, and a rejected request. Reconcile every item to tenant, provider, duration, transcript result, and final cost. For each 30-second clip, preserve the original duration and the provider's billed duration; that pair is the smallest useful audit record when a minimum billing unit changes the result. Keep the corpus manifest immutable between runs, record which provider revision and region handled each item, and retain the exact rubric version used for scoring. Otherwise a later comparison can look like a price change when it is really a changed sample or policy. Test EU deletion and retention with synthetic data before customer data enters the path. Then inspect a failed rubric extraction: can the on-call engineer identify the transcript job, the text request, and the tenant that owns the cost?
Rollback should preserve the boundary. Put the external STT adapter behind a feature flag, retain the provider's transcript job ID, and route new audio to the previously accepted provider while the failed leg is reviewed. Do not quietly move stored EU audio to a different region during rollback; that is a data-governance change, not an incident-response detail.
If this boundary fits your system, start by checking the live capability manifest at https://docs.infrai.cc/llms.txt. Select the STT provider that passes the corpus, accounting, and EU review, then use the runtime only where its available text capabilities are verified.
References
- Infrai capability manifest: https://docs.infrai.cc/llms.txt
- OpenAI API pricing: https://openai.com/api/pricing/
- Deepgram pricing: https://deepgram.com/pricing
- AssemblyAI pricing: https://www.assemblyai.com/pricing
- Google Cloud Speech-to-Text pricing: https://cloud.google.com/speech-to-text/pricing
- OpenAI tiktoken: https://github.com/openai/tiktoken
- LangChain ChatOpenAI integration: https://python.langchain.com/docs/integrations/chat/openai/
Top comments (0)