Dictation
Dictation provider routing for OpenAI, Z.AI, Grok, and SiliconFlow
Select dictation-capable providers through /dictate while keeping transcription URLs server-side.
Teams testing transcription providers behind one proxy endpoint.
The problem
Speech providers use different URLs, models, and multipart details. Client apps should not carry those differences.
How LLM Proxy helps
LLM Proxy exposes dictation-capable providers through configured catalogs and provider-specific transcription URLs while preserving one /dictate endpoint.
How it works
- Configure dictation catalogs for OpenAI, SiliconFlow, Z.AI, or xAI as needed.
- Send multipart audio to /dictate with key=<tenant secret>.
- Omit provider/model for tenant defaults or select a dictation-capable provider and model.
- Receive JSON text output from the proxy.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Dictation catalogs | Supported providers declare default dictation models and model lists. | Unknown models fail at the request edge. |
| Transcription URL config | Each dictation-capable provider owns an explicit transcriptions_url. | Client apps do not hardcode provider STT URLs. |
| Provider-specific multipart handling | The backend handles details such as whether a model field is sent. | Grok/xAI STT omits the multipart model field. |
Use-case examples
OpenAI default dictation
A caller omits provider and model to use tenant dictation defaults.
Z.AI transcription
A caller chooses provider=zai when that tenant has GLM-ASR configured.
xAI STT
The proxy routes provider=xai to the configured xAI STT endpoint.
Objections and limitations
- Text-only providers do not support /dictate through the proxy.
- Upstream products may expose other speech APIs that are not wired here.
- Audio payload size is still capped by max_input_audio_bytes.
FAQ
What is the main job of dictation provider routing?
LLM Proxy exposes dictation-capable providers through configured catalogs and provider-specific transcription URLs while preserving one /dictate endpoint.
Who should read this dictation resource?
Teams testing transcription providers behind one proxy endpoint.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Audio transcription proxy API behind tenant secrets, which covers audio transcription proxy API.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference