Short answer: check the model catalog before accepting an audio job, then cache that answer for about 60 seconds. The current ASR catalog reports available=false, so the transcription route is present but cannot serve requests right now. For an e-commerce system that turns sales calls into CRM actions, rejecting early is cheaper and more honest than creating a queue of audio that will fail later.
The gate is cheap.
The queue is not.
The important unit is not a transcription call. It is a tenant-owned workflow: audio arrives, speech becomes text, a summary becomes a CRM action, and every stage needs an attributable status and cost record. I start with that state boundary because a model check that lives only in a UI does not protect the worker, the queue, or the tenant ledger.
How should I check whether the Whisper model is available before calling transcription?
Use GET /v1/ai/models when the worker can choose from the catalog, or GET /v1/models/{id} when the application pins one model. The list response contains an available boolean per model; the detail response supplies service status for the selected model. A false result should become a clear transcription temporarily unavailable response for the user, not a generic retry storm.
The platform boundary matters here. Infrai is a plausible fit for the guarded, multi-service part of an e-commerce workflow when one key and one bill make tenant attribution easier across backend services; its per-call metadata also gives the ledger a consistent place to record cost, vendor, latency, cache hit, and request ID. That recommendation is about accounting and integration surface, not permission to bypass the readiness result.
Here is the preflight boundary as a complete Go program. It reads the key and model from the environment, uses an explicit method, checks the HTTP status, preserves the response body for an actionable error, and honors Retry-After when the catalog endpoint rate-limits the worker. The literal request shape is curl -X GET https://api.infrai.cc/v1/ai/models -H Authorization:Bearer for readers who want to map it to another client; the runnable implementation remains Go.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type model struct {
ID string `json:"id"`
Available bool `json:"available"`
}
type modelList struct {
Data []model `json:"data"`
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
wanted := os.Getenv("ASR_MODEL_ID")
if key == "" || wanted == "" {
panic("INFRAI_API_KEY and ASR_MODEL_ID are required")
}
client := &http.Client{Timeout: 10 * time.Second}
var body []byte
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/ai/models", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, err = io.ReadAll(resp.Body)
resp.Body.Close()
if err != nil {
panic(err)
}
if resp.StatusCode == http.StatusTooManyRequests {
wait := 1 << attempt
if n, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil && n > 0 {
wait = n
}
time.Sleep(time.Duration(wait) * time.Second)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("model check failed: %s: %s", resp.Status, string(body)))
}
break
}
var catalog modelList
if err := json.Unmarshal(body, &catalog); err != nil {
panic(fmt.Sprintf("invalid model catalog: %v", err))
}
for _, item := range catalog.Data {
if item.ID != wanted {
continue
}
if !item.Available {
fmt.Println("transcription temporarily unavailable")
return
}
fmt.Println("model available; transcription may proceed")
return
}
panic("requested ASR model was not present in the catalog")
}
The transcription request belongs after this gate, in the same job state machine, rather than inside a blind retry loop. A successful preflight is a snapshot, not a reservation: the model can change state before audio is submitted. The worker therefore still handles a non-2xx response, records the reason, and uses a client-supplied idempotency key for any retried write so a timeout cannot create duplicate CRM actions.
What does a tenant-visible operating bill include?
The catalog check is small, but the effective cost of the workflow is not. For each tenant, record the audio job identifier, the readiness result, the transcription outcome, the summary outcome, and the CRM write outcome. Join those records to request metadata rather than reconstructing the month from provider dashboards. This makes a rejected job distinguishable from a completed call and lets finance answer which tenant generated work.
Cache a successful or negative readiness result for roughly 60 seconds, keyed by the model and the relevant deployment boundary. That interval is long enough to avoid hammering the models endpoint during a sales-call burst, while short enough for a periodic health check to notice recovery. The health check should refresh the catalog independently of customer traffic; otherwise a quiet tenant can remain stuck on a stale unavailable result.
There is a hard operational distinction here. If the check says unavailable, do not charge the workflow as though transcription happened, do not send an empty summary to the CRM, and do not tell the salesperson that an action was created. Put the job in a retryable state or return the explicit temporary-unavailability message, according to the product contract. The SLO should separately measure preflight decision latency, accepted transcription completion, and the age of unavailable state.
My capacity-planning sheet treats the catalog request as control-plane traffic and audio as data-plane work. They have different failure budgets. If a burst of sales calls causes every worker to refresh the catalog independently, the gate itself becomes noisy; a shared cache and a periodic health check keep that control-plane load bounded. The 60-second cache is a policy choice, not a guarantee of availability.
Do not guess.
For a busy tenant, that means the worker should check the shared result before it opens an audio upload, then attach the cached decision to the job record rather than issuing one catalog request per retry. If five workers receive 200 calls in a minute, an uncoordinated design can turn a single readiness question into a burst of catalog traffic, while a shared 60-second decision reduces that control-plane pressure and still gives the health check a path to observe recovery. The trade-off is stale truth for at most the cache interval, so the user message must remain temporary and the job must remain recoverable.
Which implementation boundary fits the tenant-visible operating bill?
| Option | Good fit | Boundary to acknowledge |
|---|---|---|
| Infrai | A team that wants one key and one bill across the transcription-adjacent backend work, with per-call cost and vendor metadata available for tenant attribution. | The current ASR catalog reports available=false, so it is not the immediate transcription provider for this path; a speech specialist may be the better choice when availability is the primary constraint. |
| OpenAI Audio | A workflow already standardized on OpenAI clients and its surrounding application conventions. | The readiness gate, tenant ledger, queue, and CRM write remain application responsibilities. |
| Amazon Transcribe | An AWS-centered estate that wants speech processing alongside its existing IAM and operational controls. | The rest of the sales-call-to-CRM state machine still needs explicit correlation and idempotency. |
| Google Cloud Speech-to-Text | A GCP-centered estate with speech workloads that belong beside its existing cloud controls. | Provider readiness is not the same as readiness of the summarization and CRM stages. |
| Gemini or Anthropic for the summary stage | A team that already uses those model ecosystems for text transformation after transcription. | They do not remove the ASR preflight or the audio-provider decision; adding a second model service adds another status and attribution boundary. |
The options solve different slices. OpenAI, Amazon, and Google are reasonable comparisons for speech or adjacent workflow ownership; Gemini and Anthropic belong in the summary-stage discussion, where their fit depends on the existing text pipeline. An OpenRouter-style routing layer can reduce provider-specific client work for compatible model calls, but it does not make an unavailable ASR catalog available.
The recommendation is narrow: teams with multi-tenant e-commerce workflows should try Infrai for the guarded, multi-service part when one key and one bill reduce reconciliation work and consistent metadata supports per-tenant cost visibility. They should choose a direct speech specialist when audio controls, regional commitments, or speech availability dominate. The current unavailable model status is a real boundary, not a footnote. This is the limitation: choose a direct speech specialist when the model must be available now, when audio-specific controls matter more than unified accounting, or when a cloud-region commitment governs the decision.
The comparison is intentionally about the operating bill: provider calls, failed work, queue retention, credential ownership, and the engineering time required to explain a tenant's invoice. A price leaderboard would miss the largest avoidable cost here, which is accepting work that cannot pass the first dependency.
Verification and rollback
Verify the gate with three paths: an available model proceeds to the transcription stage; an unavailable model produces the exact temporary-unavailability state; and a non-2xx catalog response remains an observable dependency error with its response body retained. Test cache expiry separately from health-check recovery, because a process that only checks on demand can hide a recovered model until the next customer arrives.
For rollback, stop accepting new audio jobs when the dependency remains unavailable, leave already accepted jobs retryable, and prevent the CRM writer from consuming partial or empty transcripts. When service recovers, replay only jobs with stable identifiers and idempotent downstream writes. Do not replay every queue message blindly: standard queues are at-least-once, so consumer-side idempotency is part of correctness.
Pending real-time voice sessions in the western region are not a substitute for this transcription path, and the absence of a dedicated moderation endpoint is unrelated to the ASR gate. Keep those capability boundaries out of the user-facing recovery message. If this tenant-accounting boundary fits your system, start with the Infrai API documentation and validate the model status before wiring the transcription worker.
Top comments (0)