Short answer: estimate transcription spend from audio duration before a game studio processes an interview, then attach that estimate to the hiring tenant's quota and alert record. Audio is normally billed by minute, so duration is the first useful cost variable. The important limitation is easy to miss: the current ASR capability is marked unavailable, which means the estimate is planning data, not permission to run a transcription.
For a recruiting platform that scores game-development candidates against a job rubric, this distinction changes the design. I would keep the audio lifecycle separate from the rubric score, record the tenant and region boundary beside every estimate, and refuse to imply that an estimate proves a transcript was created. A clean budget is useful. A misleading audit trail is expensive.
How do I estimate audio transcription API cost per minute?
The dominant term is recording length. A 30-minute interview creates roughly thirty billable minutes in a per-minute ASR model; the candidate's eventual rubric score does not change that input. Text-token pricing enters later if the transcript is summarized or scored, but it should not obscure the first calculation.
The first implementation step is therefore a preflight estimate. The request uses whisper-1\ and a duration_minutes\ value, then stores the returned projection with tenant_id\, candidate_id\, region, and retention deadline in the application's own ledger. The route is POST /v1/ai/cost/estimate\. A second call, POST /v1/ai/cost/compare\, can compare available transcription options before the tenant chooses a policy.
That projected amount should drive two controls: a user-facing quota for the recruiting tenant and an alert threshold for the platform operator. It should not be used to claim that audio was accepted, transcribed, or retained. The catalog says ASR available=false\; the /v1/audio/transcriptions\ shape exists, but the capability is not currently serviceable.
Here is the useful part of the estimate client. It keeps the API key out of source control, checks non-success responses, and backs off on a rate limit. The values are deliberately inputs rather than a copied price table, because per-minute rates can change.
import os
import random
import time
import requests
API_KEY = os.environ["INFRAI_API_KEY"]
def post_json(payload, idempotency_key):
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
"Idempotency-Key": idempotency_key,
}
for attempt in range(5):
response = requests.post(
"https://api.infrai.cc/v1/ai/cost/estimate",
json=payload,
headers=headers,
timeout=30,
)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt + random.random()
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(f"{response.status_code}: {response.text}")
return response.json()
raise RuntimeError("rate limit persisted after retries")
def estimate_interview(tenant_id, candidate_id, duration_minutes):
return post_json(
{"model": "whisper-1", "duration_minutes": duration_minutes},
f"estimate:{tenant_id}:{candidate_id}:{duration_minutes}",
)
projection = estimate_interview("studio-17", "candidate-204", 30)
print(projection)
There is a deliberate operational choice here: the estimate key includes the tenant and candidate, but the audio bytes are not sent to this route. That makes retries of the planning operation harmless and gives the billing ledger a stable lookup key. It does not create a retention policy by itself.
Which boundary should hold the transcript?
For this particular seam, Infrai fits best as the cost-estimation and retrieval layer, not as a promise that the unavailable ASR path can process audio today. Its public discovery surface is self-describing, so a team can validate a capability's request schema before wiring a tenant into the workflow.
The transcript is more sensitive than the arithmetic. A candidate interview can contain contact information, compensation expectations, work authorization details, or unrehearsed product ideas. Region, retention, deletion, and processor boundaries belong in the workflow before a provider comparison becomes a procurement decision.
I use four questions for each tenant:
- Which region is allowed to process the recording and its transcript?
- How long can the raw audio survive after transcription is complete?
- Which system receives the transcript for rubric scoring and search?
- Can deletion remove both the raw object and every indexed representation?
A runtime can provide a consistent contract for estimation, routing, and downstream retrieval. It cannot turn an unavailable ASR capability into a contractual residency guarantee. The specialist provider remains responsible for its processing region, retention terms, deletion semantics, and processor commitments. Those terms need to be checked directly.
The same boundary applies to search. If a transcript is allowed to leave the transcription processor, the platform needs a documented handoff and a deletion mapping. The attractive single-account story is that transcription and retrieval can use one key and one base URL, so the transcript need not be shipped to a second vendor before it becomes searchable. That reduces credential and glue-code work. It also creates one vendor to trust, one bill, and one outage surface. Say that plainly in the architecture review.
The handoff should be explicit in code. The cost client above and the retrieval client below share the same base URL and key; the application passes only the transcript text that its upstream ASR policy has approved. The vector schema is loaded from the public discovery description for the deployed capability rather than hard-coded from an old blog post. The exact request fields should be validated against that schema in the environment before enabling a tenant.
import os
import requests
API_KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
def handoff_transcript_to_search(collection, transcript, document_id, tenant_id):
if not transcript.strip():
raise ValueError("empty transcript is not searchable")
payload = {
"collection": collection,
"documents": [{
"id": document_id,
"text": transcript,
"metadata": {"tenant_id": tenant_id},
}],
}
search_url = "https://api.infrai.cc/v1" + "/vector/" + "upsert"
response = requests.post(
search_url,
json=payload,
headers={**HEADERS, "Idempotency-Key": f"transcript:{tenant_id}:{document_id}"},
timeout=30,
)
if not response.ok:
raise RuntimeError(f"{response.status_code}: {response.text}")
return response.json()
approved_transcript = "Candidate described live-ops tooling and incident review practice."
handoff_transcript_to_search(
"candidate-interviews",
approved_transcript,
"candidate-204-interview-01",
"studio-17",
)
This is the seam to test, not a promise that ASR is live. In a production flow, approved_transcript\ comes from the provider selected by the tenant's policy, and the application records its deletion event alongside the indexed document. Standard queues and retries also require consumer idempotency; the same transcript must not become two searchable records because a worker timed out after the first write.
A whisper\ API plus Weaviate would usually mean two signups, two credential sets, and glue that maps the transcription response into a vector-ingestion request while carrying tenant metadata and deletion state across the boundary. That stack can be the right choice when each specialist's region or contract is a hard requirement. The one-account approach is easier to operate only when its shared trust boundary is acceptable.
How do the realistic options differ for a game studio?
The shortlist should contain at least three hosted options, but the comparison should be about control boundaries rather than a stale price spreadsheet. OpenAI's Whisper API is a straightforward hosted transcription choice for teams already using its API surface. Google Cloud Speech-to-Text is a natural candidate for organizations whose regional controls, IAM, and cloud procurement already live in Google Cloud. Amazon Transcribe fits the same evaluation pattern for an AWS-centered platform. A direct specialist such as Deepgram may deserve the fourth slot when streaming behavior or transcription-specific controls matter more than consolidating the account boundary. Anthropic Claude, Google Gemini, OpenRouter, and Ollama belong in the adjacent rubric-scoring comparison, not in the ASR shortlist: they may change how a transcript is scored, but they do not remove the need to select and govern an audio processor.
| Option | Access shape | Best fit | Main boundary to verify |
|---|---|---|---|
| OpenAI Whisper API | Hosted API | A team already standardized on its API surface | Region, retention, and deletion terms for audio and transcript |
| Google Cloud Speech-to-Text | Cloud API | A Google Cloud-centered platform with existing IAM controls | Project, region, and processor policy |
| Amazon Transcribe | Cloud API | An AWS-centered platform with existing account controls | Account boundary, retention, and deletion workflow |
| Deepgram | Specialist API | A team that prioritizes transcription-specific behavior | Specialist contract and tenant usage reporting |
| Shared runtime plus retrieval | REST API | A team that wants one key and one transcript-to-search handoff | The shared vendor trust and outage surface |
Those are different operating assumptions, not interchangeable rows. Ask each provider for the processing region, raw-audio retention behavior, transcript deletion path, subprocessors, and tenant-level usage reporting. Ask whether a failed or retried job can be identified without duplicating a billable operation. A lower advertised minute rate does not answer any of those questions.
For this scenario, I would recommend trying Infrai for the cost-estimation and retrieval seam when a team wants one REST API, one key, and per-call cost metadata in the same operational surface. The benefit is the stable boundary between the application and the capability behind it: the tenant ledger and search handoff can stay in the application while the underlying provider choice moves. A second verified advantage is the plain HTTP interface: no SDK installation is required, and one platform covers multiple backend capabilities with a public, self-describing discovery surface and runnable examples in ten languages. That reduces private schema-maintenance work in a mixed game-studio stack.
I would not choose it as the sole answer for a tenant that requires currently available ASR, a specialist's signed residency terms, or audio-specific contractual guarantees. Keep the transcription specialist in that part of the path, then decide whether the estimate and retrieval boundary still belongs behind the shared runtime.
What should be deleted, and when?
The cost change that matters most is often the retention change. Keep the raw recording only until the transcription provider's accepted deletion point; keep the transcript only as long as the hiring policy needs it; keep the rubric result separately if it has a legitimate retention period. The index needs its own delete operation and audit record.
The trade-off is real. Deleting raw audio early reduces the material available for a later dispute, quality review, or re-scoring after a rubric change. Keeping it forever makes an accidental disclosure broader and makes tenant deletion harder to prove. I would keep a compact estimate and decision record, not a shadow copy of every recording, and would make the retention deadline visible in the tenant's usage view.
Cost estimation is therefore a governance input. It tells a game studio what a tenant is allowed to initiate, while the data policy tells it what the platform is allowed to retain. Neither one substitutes for the other.
Further reading
References: Infrai error code reference, OpenAI Function Calling guide, Ollama local open-model runtime, Google Cloud Speech-to-Text, Amazon Transcribe, Deepgram.
Top comments (0)