Choosing a speech-to-text API affects more than transcript quality. Its turn signals shape how a voice agent responds, its language coverage changes with the model, and its billing unit determines what idle connections cost. Deepgram and AssemblyAI both handle live and recorded audio. The useful distinction is which model and operating contract fit your product, from a meeting-transcription pipeline to a real-time phone agent.
Deepgram vs AssemblyAI at a glance
Deepgram's main distinction is the choice between Flux for conversational turn detection and Nova-3 for general transcription. AssemblyAI combines promptable streaming recognition with a separate batch model and lower base batch rates. Both offer self-hosting. Neither company's overall language count describes every model.
For a voice agent, the decision turns on end-of-turn behavior, entity recognition and session economics. For recorded audio, it turns on transcription features, language routing and job throughput.
| Requirement | Deepgram | AssemblyAI |
|---|---|---|
| Conversational streaming | Flux, with integrated turn events | Universal-3.6 Pro Realtime, with content-aware endpointing |
| General transcription | Nova-3, streaming and pre-recorded | Universal-3.5 Pro for batch; Universal-2 for wider batch coverage |
| Multilingual conversation | Flux: 10 languages; Nova-3 multilingual: 55 | Universal-3.6 Pro Realtime: 32 languages |
| Batch language coverage | Model-specific Nova-3 monolingual and multilingual options | Universal-3.5 Pro: 18 languages, with Universal-2 fallback covering 99 |
| Streaming usage unit | Processed audio duration | Open WebSocket session duration, including idle time |
| Self-hosting | Enterprise containers; Amazon SageMaker deployment option | Commercial self-hosted streaming stack |
A speech-to-text component leaves the surrounding application under your control. We provide call execution and inspection through Dasha when the requirement extends to operating a voice agent.
Deepgram: distinguish Flux from Nova-3
Flux and Nova-3 solve different problems inside the same provider. Their model-specific feature sets have important limits.
Flux provides conversation events
Flux uses /v2/listen and emits events such as StartOfTurn, EndOfTurn and TurnResumed. These let an application respond to the conversation's state rather than infer every turn boundary from transcript fragments.
Optional EagerEndOfTurn events allow a language model to start preparing a response before the final turn decision. If the caller continues speaking, TurnResumed tells the application to cancel that draft. This creates a concrete tradeoff: earlier preparation can reduce waiting, while discarded generations add language-model work. The application's cancellation logic still matters.
Flux has English and multilingual variants. The multilingual model covers English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian and Dutch. Its turn-detection features do not imply feature parity with Nova-3: Flux does not support speaker diarization, Deepgram's Smart Formatting feature or general profanity filtering.
Nova-3 covers transcription-oriented features
Nova-3 uses /v1/listen for streaming and pre-recorded audio. It supports speaker diarization, which assigns words to speakers, plus Smart Formatting, redaction and keyterm prompting. Its streaming interface exposes interim results and endpointing controls.
Nova-3's multilingual mode covers 55 languages with code-switching, the ability to transcribe a conversation that changes languages. Its monolingual options have a separate language and dialect list. A requirement for Swedish meeting transcription and a requirement for a ten-language interactive agent therefore point to different Deepgram configurations.
Deepgram is a practical fit when your application needs explicit conversational state from Flux, Nova-3's transcription features, or its deployment options. A requirement combining Flux turn events and native speaker labels creates an additional integration problem because those features are split across models.
AssemblyAI: separate realtime recognition from batch coverage
AssemblyAI also has model-specific language coverage for live conversations and recordings. The Universal-3.6 Pro Realtime model supports 32 languages with native code-switching. Universal-3.5 Pro is the separate pre-recorded model, supporting 18 languages. Universal-2 extends batch coverage to 99 languages through fallback.
Realtime turns can change before they finish
Universal-3.6 Pro Realtime considers the content of a turn as well as silence. Its entity-aware endpointing can hold a turn open when a caller pauses during a phone number, account identifier or spelled-out name. The turn-silence controls, min_turn_silence and max_turn_silence, control when completion is considered and when a turn must end.
Partial Turn messages replace earlier versions of the same turn. The final message has end_of_turn: true. This matters during migration: code that appends every partial transcript will duplicate words, and code that acts on an early fragment may receive an incomplete identifier.
Realtime features include prompting, keyterms, conversation context and speaker diarization. The lower-cost Universal-Streaming English and Multilingual models remain separate choices. Their price and language coverage should not be attributed to Universal-3.6 Pro Realtime.
Batch language routing changes the model
Universal-3.5 Pro supports contextual prompting and a keyterms vocabulary of up to 1,000 words. Universal-2 supports up to 200 words. The 99-language batch coverage combines models; it does not mean every recording receives Universal-3.5 Pro recognition.
AssemblyAI fits applications that need promptable recognition, content-aware turn completion or broad batch language routing. For a multilingual product, the operating implication is to retain the selected model alongside each transcript. Otherwise, an aggregate accuracy metric can mix different recognizers and hide language-specific failures.
Pricing: compare the same model and billable duration
The following are base cloud pay-as-you-go rates before optional features and negotiated discounts. Hourly equivalents for Deepgram are the per-minute rate multiplied by 60. These are speech-to-text costs, excluding telephony, language-model generation, speech synthesis and your application infrastructure.
| Workload and model | Listed rate | Equivalent per hour |
|---|---|---|
| Deepgram Flux English | $0.0077/min | $0.462 |
| Deepgram Flux Multilingual | $0.0078/min | $0.468 |
| Deepgram Nova-3 monolingual, streaming | $0.0077/min | $0.462 |
| Deepgram Nova-3 multilingual, streaming | $0.0092/min | $0.552 |
| Deepgram Nova-3 monolingual, pre-recorded | $0.0043/min | $0.258 |
| Deepgram Nova-3 multilingual, pre-recorded | $0.0052/min | $0.312 |
| AssemblyAI Universal-3.6 Pro Realtime | $0.45/hr | $0.450 |
| AssemblyAI Universal-Streaming English or Multilingual | $0.15/hr | $0.150 |
| AssemblyAI Universal-3.5 Pro, batch | $0.21/hr | $0.210 |
| AssemblyAI Universal-2, batch | $0.15/hr | $0.150 |
Streaming prices use different clocks
Deepgram speech-to-text is billed per second of processed audio. AssemblyAI uses session-based streaming billing for the entire time a WebSocket session stays open, including periods when no audio is sent. Separate simultaneous AssemblyAI sessions accumulate billable time independently.
That makes the $0.462 versus $0.450 comparison narrower than it looks. With exactly 1,000 billable hours on each service, the base charges are $462 and $450. Just 30 additional open-session hours on AssemblyAI add $13.50, exceeding that $12 difference. This arithmetic isolates billing units; it assumes equivalent recognition quality and features and excludes add-ons.
AssemblyAI sessions end through a Terminate message. Unclosed sessions automatically end after three hours and incur the corresponding session-duration charge. Connection lifecycle code is therefore part of the cost model.
Multichannel processing adds another multiplier. Both providers bill separately processed channels. A one-hour, two-channel recording processed as two channels represents two billable audio hours, rather than one.
Add-ons and commitments change the total
Deepgram's streaming add-ons include speaker diarization at $0.0020/min, redaction at $0.0020/min and keyterm prompting at $0.0013/min on pay-as-you-go. Smart Formatting is included where supported. Optional AssemblyAI features also have separate charges; the base recognition rate is not an all-features price.
Deepgram offers pay-as-you-go without a minimum commitment. Growth starts with $4,000 in annual prepaid credits and has different rates and concurrency limits. AssemblyAI cloud usage is pay-as-you-go, with volume agreements available. Self-hosting has separate commercial terms.
Production limits: concurrency and admission rate are different
Concurrency is the number of requests running at once. Admission rate is the number of new sessions allowed within an interval. They constrain different traffic patterns.
| Limit | Deepgram | AssemblyAI |
|---|---|---|
| Streaming cloud starting point | Pay-as-you-go: up to 150 concurrent Flux or Nova-3 requests per project | Paid accounts: starting rate of 200 new sessions per minute; no fixed cap on total open streaming sessions |
| How streaming scales | Growth: up to 225 concurrent requests in North America, 150 in Europe, Australia and India; Enterprise limits are negotiated | Paid-account admission limit grows automatically with sustained usage |
| Pre-recorded parallel processing | Pay-as-you-go Nova-3: up to 50 concurrent requests | Paid accounts: 200+ active jobs, with excess jobs queued |
| Limit scope | Project; additional self-serve projects do not multiply capacity | Account; API keys share account limits |
Deepgram applies project concurrency limits. AssemblyAI separates streaming admission limits from batch processing limits.
For the base streaming limits above, assume one request per caller, no other active Deepgram requests and no earlier AssemblyAI session openings in the minute. A burst of 120 new callers fits within both limits: 120 concurrent requests are below Deepgram's 150-request ceiling, and 120 new sessions are below AssemblyAI's 200-per-minute starting allowance. More than 200 new sessions in that minute would exceed AssemblyAI's starting admission limit even if few remain open. Long-lived sessions can still accumulate beyond 150 on AssemblyAI while arrivals stay within its per-minute allowance.
These are consequences of the limit definitions, not throughput measurements. They explain why “unlimited concurrency” does not mean unlimited cold-start admission. AssemblyAI's admission limit also scales down after lower usage and returns to its starting level after 15 minutes without new sessions.
Deployment and vendor dependency
Both providers offer cloud services and self-hosting. “Deepgram is self-hosted, AssemblyAI is cloud-only” is no longer an accurate distinction.
Deepgram's self-hosted deployment options include Enterprise deployments with Docker, Podman or Kubernetes, plus an Amazon SageMaker route with separate purchasing and deployment requirements. AssemblyAI's self-hosted streaming stack uses a WebSocket gateway, recognition containers running on graphics processing units (GPUs) and a license proxy. Its streaming offer requires a $50,000 upfront commercial commitment.
Self-hosting moves capacity planning, GPU operation, upgrades and service monitoring into your infrastructure. It does not turn either provider's licensed models into open-source software. The exact model, feature set and licensing traffic remain deployment-specific.
For cloud streaming, AssemblyAI offers default edge routing plus US and European Union (EU) Data Zone endpoints. Deepgram has regional endpoints for North America, Europe, Australia and India. A region label alone does not establish the location of every log, support interaction or downstream language-model request. Those are separate data flows.
Both companies also supply products beyond speech recognition, including speech synthesis. Deepgram's Voice Agent API is a separate managed agent product. Buying more layers from one provider can reduce integration work while increasing the migration scope: a later switch may affect turn events, voice generation and orchestration as well as transcripts.
Accuracy and latency need task-specific definitions
A single word error rate cannot settle every application decision. Word error rate counts substitutions, deletions and insertions against a reference transcript. It does not directly measure whether the correct customer's record was retrieved or whether a speaker label stayed consistent throughout a meeting.
Useful acceptance criteria follow the workflow:
- Phone agents: complete names and account identifiers, premature turn endings, interruption handling and time until audible response.
- Meeting products: words assigned to the correct speaker, overlapping speech, language changes and usable timestamps.
- Batch analytics: domain vocabulary, transcript completeness, queue delay and processing time at the required volume.
Streaming latency also has multiple endpoints: first partial text, final turn text and first audible agent response. Earlier partials do not guarantee earlier correct actions. For Flux, speculative language-model work creates cancellation overhead; for AssemblyAI, holding an unfinished entity open deliberately changes turn timing. Neither tradeoff is captured by a provider-wide “fastest” label.
Where Dasha fits when the product is a voice agent
We recommend Dasha when your team wants a managed runtime for production phone or web agents, with call execution and inspection around the conversation. We provide a managed production platform through REST APIs and a web application, including integrations with business systems. We are a different purchasing category from a standalone transcription API.
Our external API tools connect conversations to business systems. Our completed-call inspector brings together transcripts, recordings, language-model interactions, tool executions and timeline events. Your team still owns business rules, data, downstream services, telephony configuration, compliance and production acceptance.
If your product needs transcripts, Deepgram and AssemblyAI remain direct component choices. If the requirement is to build and operate the conversation around those transcripts, explore our managed runtime with that responsibility boundary in mind.
