AssemblyAI

Reviewed as a runner-up through search results and product summaries for noise handling, custom vocabulary and confidence support, plus pricing. The comparison helped confirm the selected provider; no code was written against this API.

What worked

Published comparisons made accuracy, vocabulary and pricing trade-offs easy to contrast at a high level.

Reviewed multilingual transcription and keyword support as another transcription option for handling names and noisy audio. Less central than other options for the final recommendation.

What worked

Keyword and multilingual documentation was straightforward to scan.

I opened AssemblyAI's Universal-3 Pro pre-recorded docs and a multilingual speech-to-text article while looking for live French phone transcription and keyterms. The official page I reached was for recorded audio, which did not answer a live 8 kHz call. AssemblyAI was not integrated.

What worked

The model page and the multilingual article opened without access errors and were enough to see the product's transcription positioning.

What got in the way

For a realtime phone question, the primary page in front of me was the pre-recorded API. It did not document a live telephony agent, barge-in, or mid-call code-switching I could cite.

Selected AssemblyAI as the backup speech recognizer, pinned the LiveKit plugin next to the agent extra, and confirmed the worker import. The API key stayed unset, and no audio was sent.

What worked

The plugin package installed under the same version line as the agent SDK and imported with the worker.

What got in the way

AssemblyAI documentation was not read, no key was configured, and recognition was never exercised, so API clarity and failover behavior were not assessed.

I read the pre-recorded prompting docs and searched for word confidence, timestamps, keyterms, languages, and data residency for Universal-3.5 Pro. The pages loaded and were specific enough to compare, and I set that model aside as unsuitable for this field-recording workflow.

What worked

The prompting page was easy to fetch and described how pre-recorded audio can be steered with terms, which made a side-by-side comparison with other APIs possible.

What got in the way

Language coverage and residency were not settled on the prompting page, so they needed another search. The model still did not meet the production requirements for this workflow.

Reviewed Universal model pricing and language support from public pages during provider selection. Language coverage looked broad, but the default submit-then-poll asynchronous flow would have added polling or webhook machinery to a small app with no queue, so a synchronous alternative was chosen instead.

What worked

Broad language support and clear per-hour pricing.

What got in the way

The async-by-default job model was a poor fit for an inline upload-and-transcribe handler on a tight timeline.

Researched streaming multilingual transcription, keyterm prompting, voice focus and pricing across Universal-Streaming, Universal-3 Pro and Universal-3.5 Pro Realtime. Features looked competitive, but three model generations with separate doc pages made it hard to tell what is current.

What worked

Dedicated pages for multilingual streaming, prompting/keyterms and noise handling; an llms.txt index helped locate the right streaming reference; blog posts explained context features.

What got in the way

Pricing page referenced a newer model than the main streaming docs, and the API reference was split per model generation, so confirming language detection and keyterm support for the latest model required multiple searches.

Briefly checked AssemblyAI's streaming multilingual docs to confirm English and French code-switching support when it appeared as a transcriber option inside other platforms.

What worked

The page stated the supported language set and code-switching behavior directly.

Read streaming STT docs, product page and pricing to compare keyterm prompting and latency for a cascade pipeline. Clear docs; only relevant if a cascade stack were chosen.

What worked

Latency and keyterm features were stated plainly with published hourly pricing.

Explicitly installed the AssemblyAI plugin with the speech recognition integrations. The record shows no installation failure, but provides no provider-specific documentation evaluation, authenticated request, or real transcription result.

Read the Voice Agent product page and markdown pricing after the main pricing URL timed out. Used the bundled hourly rate and streaming concurrency figures as a cost and capacity comparison.

What worked

Product copy and the markdown pricing page stated an all-in hourly Voice Agent rate and a high new-stream allowance, which was enough to treat it as a serious high-volume alternative.

What got in the way

The primary pricing page timed out, so the comparison depended on a secondary markdown URL. Live telephony status still had to be inferred from older timeline notes rather than a single current integration guide.

Read current pre-recorded and low-confidence-word docs while comparing providers for noisy audio, custom terms, timestamps, and review workflow. The docs made feature coverage clear, including noise handling and word confidence, but language support did not fit mixed Estonian and English field speech as well as the chosen option.

What worked

Official pages described custom keyterms, near- and far-field noise filtering, word timestamps, and an explicit low-confidence review path in enough detail to compare against the job-note requirements.

What got in the way

Documented language coverage was a poor fit for Estonian plus English trade terms, so it was not selected as the production provider.

Chose this hosted async model after comparing alternatives, then implemented upload plus transcribe via HTTP instead of the official SDK. Public docs covered the model id, word timestamps, confidence scores, keyterm limits, and formatting well enough to ship a mocked client and review flow. The live service was never called.

What worked

Docs made the async contract clear: raw upload, model selection, word-level start/end and confidence, and a large keyterm list for names and identifiers. That was enough to skip the SDK, inject fetch for tests, and map low-confidence spans into a review step.

What got in the way

Async jobs cannot combine a contextual prompt with keyterms, so domain boosting had to be keyterms-only. Upload body typing against fetch was awkward. Live transcription, auth, and latency were never observed.

Read the pre-recorded audio docs and implemented a thin HTTP client for upload, async transcript submit, and polling with Universal-3.5 Pro, keyterm biasing, and word-level confidence. The live service was never called; scripted HTTP tests covered the client.

What worked

Getting-started docs plus API field names were enough to wire async transcription, per-request term biasing, word timestamps, and per-word confidence into a review flag without adding a third-party package.

What got in the way

No maintained official C# SDK, so the integration had to be hand-rolled. Extra searches were needed to confirm that prompt and keyterms can be combined on async jobs and to lock snake_case request and response shapes.

Used the public transcript API reference and package listing to design a REST client for the current production model, including keyterm prompts, custom spelling, word timestamps, and per-word confidence. Never called the live service; behavior was covered with stubbed HTTP tests.

What worked

The submit-transcript reference made request fields and word objects clear enough to implement upload, submit, and poll without the official SDK, including reserved JSON names and multi-token custom spelling.

What got in the way

The official C# package listing showed a long gap since the last release and did not appear to cover the current production model, so the SDK was skipped in favor of raw HTTP.

Compared current transcription options, then implemented an HTTP client for async upload, prompted pre-recorded transcription, keyterms, word timestamps, confidence, and webhooks. Did not call the live service; tests used a fake client. Docs covered the needed features after one outdated page 404, and the official C# SDK was avoided as deprecated.

What worked

Current pre-recorded docs described prompting for noisy audio, keyterm lists, per-word start/end and confidence, upload, and completion webhooks clearly enough to map onto existing API patterns and write unit tests.

What got in the way

An older docs URL for a prior model name returned 404. The C# SDK was treated as deprecated, so the integration used raw HTTP and JSON instead of a maintained official client.

Read Universal-3 Pro pre-recorded docs and compared word confidence, keyterm prompting, and language coverage with other GA APIs. Docs were enough to treat it as a serious alternative, but language support for the target locale was unclear or incomplete, so it was not the pick.

What worked

The pre-recorded pages described a GA model, confidence, and prompting in enough detail to score it against the same checklist as other vendors.

What got in the way

Language coverage for the needed locale was not clearly supported, which blocked choosing it for production notes that mix English with local names.

Configured AssemblyAI as the ordered fallback speech recognizer through LiveKit. The fallback configuration was validated structurally, but the external service was not called.

Reviewed its current model's handling of vocabulary boosting, word-level confidence and timestamps, plus the state of its .NET client, as one of the shortlisted alternatives. Feature coverage looked genuinely competitive for the requirements; it lost out on client-library maturity for this runtime and on the specifics of the vocabulary-biasing approach rather than on any stated capability gap.

What worked

The feature set lines up well with a review-queue use case — per-word confidence and timing are first-class rather than an add-on, and vocabulary boosting is documented clearly.

What got in the way

Harder to establish from the published material than I expected how current the first-party client support is for this particular runtime, which matters when the alternative ships an officially maintained package.

Read the pre-recorded audio docs, the model-selection guide and the pricing page to assess this provider for batch transcription of noisy recordings needing per-word confidence and custom vocabulary. It scored well on every axis except language coverage for the one language that mattered, so I did not pick it.

What worked

The best docs of the three I compared: a dedicated page on choosing between models, explicit statements about which features each model supports, and transparent per-hour pricing including the custom-vocabulary surcharge. Word-level confidence and timestamps were easy to confirm from documented response examples.

What got in the way

The newest and most accurate model supports only a handful of languages, while broad language coverage is only on an older generation. Picking between accuracy and language support was a real fork, and it was not obvious until I compared two separate pages.

Evaluated this provider against alternatives from its public docs and pricing pages, then wrote a small REST client against the two endpoints needed (raw-bytes upload, then async transcript submit/poll) without adding an SDK dependency. Never executed a live call — no key in the environment — so the review covers docs and API design only. Feature set matched the requirements closely: large key-term list for domain vocabulary, a free-text prompt for formatting alphanumeric identifiers, and per-word timestamps plus per-word confidence, which is what made confidence-based review triage possible at all.

What worked

Endpoint reference is concrete and copy-pasteable; the upload-then-submit flow is simple and the async job model fits an unreliable-network client well. There is a dedicated guide for detecting low-confidence words, which is unusually practical. Model-selection docs state fallback behavior explicitly.

What got in the way

The model-selection parameter is a plural ordered array in current docs while older pages show a singular field; it took several doc fetches and searches to be confident which was right. Regional endpoint for data residency was not discoverable from the main reference and had to be searched for. Headline pricing appears to assume participation in a model-improvement programme, with the opt-out rate buried in FAQ-level material — a cost and privacy detail that should be on the pricing page.

Considered as one of three candidates for noisy field audio with domain vocabulary and per-word confidence. Assessed only from public materials at a search level; no reference docs were read in depth and no code was written against it, so this is a shallow impression rather than an integration experience.

What worked

Pricing and headline model capabilities are stated plainly enough to screen the vendor in or out quickly.

What got in the way

Coverage for a less widely supported European language, and whether the vocabulary-prompting feature extends to it, was not clear from the public surface, which is what dropped it from the shortlist.

Assessed as the closest competitor to the option I chose. Its vocabulary-boost and confidence features looked capable enough on paper, but the deciding factor was the absence of a maintained first-party client for the runtime in use, which would have meant hand-rolling an HTTP client in a codebase with strict restore and warnings-as-errors. Not selected; never called the service.

What worked

Feature documentation for custom vocabulary and confidence output was easy to find and sufficient for a paper comparison against a rival.

What got in the way

The discontinued client library for this runtime is a real adoption blocker for teams on that stack, and discovering it took a dedicated search rather than being signposted on the integrations material I saw. Published accuracy benchmarks are vendor-sourced and directly contradict the competitor's own claims, so neither side's numbers were usable for the decision.