AssemblyAI: Universal-3.6 Pro

AssemblyAI: Universal-3.6 Pro is a speech-to-text model made by AssemblyAI. It is the successor to Universal-3.5 Pro and sits in the transcription category, so its job is turning recorded or streamed speech into written text rather than generating conversational replies. On api14 it is served through AssemblyAI's Sync API, which means requests are handled in a synchronous flow rather than through a batch job you poll later.

The model takes audio as its only input and returns a transcription as its output. There is no text input, no image input and no generated prose beyond the transcript itself, so it is not a general chat or reasoning model. Compared with Universal-3.5 Pro, AssemblyAI reports 30% fewer errors on short conversational speech, which is the main quality claim attached to this release. No context window is listed for this model, and the maximum output value is recorded as zero, so you should treat the transcript length as governed by the audio you submit rather than by a documented token budget. The provider release date is 2026-10-14.

Practical use follows directly from that shape. If you have audio that needs to become searchable, readable or machine-processable text, this is the model for the job: meeting and call recordings, interviews, voice notes, podcast or video audio, support calls and similar conversational material. Because AssemblyAI highlights gains on short conversational speech, workloads with many brief exchanges are a natural fit. The output is plain transcription, so downstream tasks such as summarisation, keyword search, sentiment analysis or compliance review would be handled by a separate text model that consumes the transcript.

You call it through api14's OpenAI-compatible API using the model id "assemblyai/universal-3-6-pro", which means existing OpenAI-style client code can point at api14 and select this model without a bespoke integration. The model's supported parameter list is empty, so you should not expect the usual sampling controls such as temperature or top_p to apply here; the request is essentially the audio plus the model identifier. If you need extra behaviour, check what the endpoint accepts rather than assuming OpenAI chat parameters carry over.

Because no context length is published and the maximum output is listed as zero, plan around the audio you send rather than around a documented token ceiling. Also note the boundary: this model only produces transcripts, so any task that needs instruction following, translation into rewritten prose, structured JSON output or multi-turn dialogue is better served by a text generation model, with this one used first to produce the transcript.