Skavio Transcribe: what Groq-to-AssemblyAI fallback does—and does not—guarantee
Skavio Transcribe has an alternative processing route: Groq is the primary transcription provider, with AssemblyAI configured as fallback. That provides operational flexibility, not a promise that every recording will finish successfully. Separate three questions: has the job been accepted, has transcription completed, and is the resulting text suitable for your purpose?
1. Understand the provider order before relying on it
The verified configuration is Groq primary, AssemblyAI fallback. Local automatic speech recognition (ASR) fallback is disabled in the current runner, so a third, local transcription route should not be assumed. This establishes the provider order—not which errors trigger fallback, how quickly switching happens or how many attempts are made. Groq documents HTTP 429 responses when rate limits are exceeded, for example, but that does not verify that Skavio switches providers on every 429. Treat fallback as another configured processing route. It is not an uptime SLA, a completion deadline or a guarantee of recovery: the fallback provider can also reject a request or encounter a transcription failure.
2. Check the recording and the server quote
Before submission, confirm that you have the intended recording. Play the beginning and a representative passage, check that the speech you need is present, and note any sections that will require careful review. A provider change should not be treated as a repair for missing content or unclear audio. Then inspect the server quote. Canonical Pricing V2 sets Transcribe at 8 shared credits per started minute, with a minimum of 8 credits per job. For example, a 61-second recording represents two started minutes, or 16 credits. Check the measured server quote for your actual job rather than relying only on a manual calculation. The web processing tools and Processing API share the company wallet. For API submissions, the measured quote is reserved when the job is submitted; success charges once, while permanent failure releases that reservation. Releasing reserved credits is not a cash refund.
3. Wait for completion—not merely acceptance
A successful submission response is not the same as a successful transcript. AssemblyAI’s documentation distinguishes queued, processing, completed and error states, and describes failures that can occur after a request has been accepted. These are provider states, not confirmed labels for Skavio’s interface or API. The practical rule is to wait for successful completion and verify that the transcript is available before sending it into an editing, reporting or downstream data workflow. If processing is still ongoing, do not infer either success or failure from elapsed time alone. Fallback does not establish a fixed turnaround time. Actual processing time depends on the recording’s length and format, the queue and service availability. An internal speed measurement is evidence about a particular run—not a deadline for your job or a benchmark for the fallback route.
4. Review the transcript; fallback is not a second opinion
The configured provider order does not establish simultaneous transcription by both providers, accuracy-based comparison or automatic correction of a completed transcript. Nor does it promise identical wording, punctuation, timestamps or accuracy across providers. Review important passages against the recording before treating the text as an authoritative record. Focus on names, specialist terminology, numbers, dates and quotations that will be published or used in decisions. Keep the product boundary clear, too. AssemblyAI’s role as Transcribe’s fallback does not add Skavio Meeting’s features. Meeting is a separate workflow combining AssemblyAI transcription and speaker diarization with OpenAI analysis to produce a speaker-aware transcript and meeting report.
- Check unfamiliar names and acronyms against the audio.
- Verify amounts, dates and other consequential details.
- Listen to important quotations in context before reusing them.
5. Investigate a failed job before submitting again
If a job fails, inspect any available error information before repeating the submission. AssemblyAI documents both immediate request errors and later transcription failures, including audio-file, language and server problems. Those categories illustrate why a second provider cannot guarantee recovery; they do not identify the cause of a particular Skavio failure. Check the source recording and any relevant input requirements, and determine whether the previous job has reached a final outcome. For API jobs, distinguish an uncertain submission response from a confirmed failure: the Processing API supports idempotent submissions, so integrations should use that mechanism for safe retries rather than blindly creating another job. A permanently failed API job releases its reserved credits under the verified processing rules. That accounting outcome is separate from the technical cause of failure—and does not prove that every processing attempt incurred zero provider cost.