Speech recognition has moved beyond simple transcription. Modern voice control systems need to parse intent, resolve ambiguous commands, and maintain state across multi-turn conversations. The most robust architecture treats automatic speech recognition (ASR) as the first stage of an LLM-powered pipeline: audio goes in, structured action comes out. This shift changes how you should think about inference costs, because a five-minute meeting recording or a lengthy voice command can generate thousands of tokens of context. Oxlo.ai is designed for exactly this kind of long-context workload.
The Modern Speech Stack
A production voice control pipeline usually has three layers. First, an ASR model converts audio to text. Second, an LLM interprets the transcript, extracts entities, and decides which functions to call. Third, an optional TTS model speaks the confirmation or result back to the user. Each layer has different latency and accuracy requirements, and each benefits from being able to scale without unpredictable cost spikes.
Oxlo.ai covers all three stages. You can route audio through audio/transcriptions using Whisper Large v3 or Whisper Turbo, send the resulting text to any chat model via chat/completions, and synthesize responses with audio/speech using Kokoro 82M. Because the platform is fully OpenAI SDK compatible, you can swap these endpoints into an existing Python or Node.js codebase without rewriting your HTTP client.
Why Input Length Matters
Audio is dense. A single minute of speech produces roughly 100 to 150 tokens of text, and real-world voice control sessions often include multi-turn history, system prompts, and tool schemas. Under token-based pricing, long transcripts and large prompt templates compound quickly. The result is that voice applications, which are inherently long-context workloads, often incur disproportionate inference costs.
Oxlo.ai uses request-based pricing: one flat cost per API call regardless of how many tokens the prompt contains. For voice workflows that pass long transcripts to an LLM, or that maintain extended conversational context across several turns, this can make costs significantly more predictable. You can read the exact structure on the Oxlo.ai pricing page. There are also no cold starts on popular models, so voice assistants stay responsive even after idle periods.
Building a Voice Control Pipeline
Consider a smart-home assistant that listens to a command, transcribes it, extracts the intended device and action, and calls a local API. With Oxlo.ai, the implementation is straightforward.
Step one is transcription. You send an audio file to the transcriptions endpoint:
import openai
client = openai.OpenAI(
api_key="YOUR_OXLO_API_KEY",
base_url="https://api.oxlo.ai/v1"
)
audio_file = open("command.wav", "rb")
transcript = client.audio.transcriptions.create(
model="whisper-large-v3",
file=audio_file,
response_format="text"
)
print(transcript) # "Turn off the living room lights in five minutes"
Step two is intent parsing and tool selection. You pass the transcript to a chat model with a system prompt and a function schema. Oxlo.ai supports function calling and JSON mode, so you can enforce structured output:
response = client.chat.completions.create(
model="llama-3.3-70b",
messages=[
{"role": "system", "content": "You are a home automation parser. Extract the device, action, and delay_minutes."},
{"role": "user", "content": transcript}
],
tools=[{
"type": "function",
"function": {
"name": "schedule_device_action",
"parameters": {
"type": "object",
"properties": {
"device": {"type": "string"},
"action": {"type": "string", "enum": ["on", "off"]},
"delay_minutes": {"type": "integer"}
},
"required": ["device", "action"]
}
}
}],
tool_choice="auto"
)
tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.arguments)
# {"device": "living room lights", "action": "off", "delay_minutes": 5}
Because Oxlo.ai is fully OpenAI SDK compatible, the openai library handles streaming, function calling, and error formatting exactly as it would against OpenAI's own endpoints.
Text-to-Speech for Closed-Loop Interaction
A voice interface feels incomplete without spoken feedback. After your application executes the scheduled command, you can generate a natural-sounding confirmation with Kokoro 82M through the same client:
speech = client.audio.speech.create(
model="kokoro-82m",
voice="af_bella",
input="OK. I'll turn off the living room lights in five minutes."
)
with open("confirmation.mp3", "wb") as f:
f.write(speech.content)
This closes the loop: audio in, structured action, audio out, all through one provider and one SDK instance.
Model Selection
For transcription, Whisper Large v3 gives the highest accuracy for noisy or accented speech, while Whisper Turbo trades a small amount of accuracy for lower latency. If you are building a real-time voice control system, Turbo is usually the better starting point.
For the reasoning layer, the choice depends on complexity. Llama 3.3 70B works well for general intent parsing and multi-turn dialogue. If the voice assistant must perform deep reasoning, complex coding, or extended chain-of-thought planning, DeepSeek R1 671B MoE or Kimi K2.6 are available on Oxlo.ai. Qwen 3 32B is a strong multilingual option if your voice control must handle mixed-language input.
For TTS, Kokoro 82M is lightweight and fast, making it suitable for low-latency responses.
Putting It Together
Voice control is no longer just about converting audio to text. It is about reasoning over that text, maintaining context, and responding naturally. An architecture built on Oxlo.ai lets you run the entire pipeline, transcription, reasoning, and synthesis, through a single OpenAI-compatible provider with request-based pricing. For workloads where transcripts and conversation history are long, that pricing model removes the penalty on input length and keeps costs flat per interaction. Start with the Oxlo.ai pricing page to compare plans, or drop the base URL into your existing OpenAI client to test the transcription and chat endpoints today.
Top comments (0)