There are five public model ids, and most of the choosing is done by one question: is a person waiting? Everything else follows from that, and this page walks the rest of the forks.

​
Live audio is a different model, not the same one faster

The most expensive mistake on this page is building a live experience out of the file endpoints — recording a second of microphone audio, POSTing it to /v1/audio/transcriptions, sending the text to a chat model, and synthesizing the reply. That costs three round trips per turn, and it throws away the thing that makes conversation work: turn boundaries. Chopping a microphone into fixed slices cuts words in half and gives the model no idea whether someone has finished speaking. nur-realtime-v1 is audio in and audio out on one socket, and it handles end-of-turn detection, barge-in and cancellation for you. So:
  • Audio you already have — a recording, an upload, a voicemail — is a file. Use transcription. It is cheaper and it needs no socket held open.
  • Audio arriving as someone speaks is a conversation. Use realtime.

​
Transcription: two tiers, and the difference is people

nur-stt-v1 (Whisper large-v3) gives you the words. nur-stt-v1-pro (MOSS-Transcribe-Diarize) gives you the words and who said them — diarized segments with timings, per-segment confidence, and an audibility read on whether a speaker was on mic, off mic, or too faint to trust. The pro tier is the same price as nur-stt-v1 ($0.001 per minute). Pick it when the extra information changes what you do:

Use nur-stt-v1

One speaker, or you only need the words: captions, voice notes, dictation, a search index over call audio.

Use nur-stt-v1-pro

More than one voice in the room and the answer depends on which: meeting notes, interviews, QA review, anything you will attribute or quote.
Two practical differences beyond the price:
  • The pro tier streams. Segments arrive over SSE as the file decodes rather than at the end, which matters on long audio — one pass handles roughly ninety minutes, and you do not want to stare at nothing for it.
  • Diarization is guesswork on short audio. Speaker separation needs enough continuous speech per voice to be confident. On a file of two-second fragments it will sometimes split one person in two, so prefer it for long-form recordings rather than clips.
If you are unsure, start with nur-stt-v1. Moving up is a one-word change to model; the request and response shapes are the same.

​
Voices: pick a built-in unless you need a person

Both nur-tts-v1 and nur-realtime-v1 can speak in a cloned voice, and every voice — cloned or built-in — resolves to a stored reference clip. Prefer built-in voices. They are designed from a text vocabulary rather than recorded from anyone, so they carry no likeness rights and no retention clock, and they need no upload. Clone only when the point is a particular person: a founder, a presenter, a support lead whose voice customers already know. Cloning takes a permission you have to actually hold — see Voice cloning for what makes a clip work and what you are attesting to.

​
The LLM: ours is a default, not a lock

nur-llm-v1 serves POST /v1/chat/completions and is on the free tier, which makes it a reasonable default for the text side of whatever you are building — summarizing a transcript, extracting fields, drafting a reply. It is not the only option, and nothing here locks you in: the endpoint is OpenAI-shaped in both directions, so pointing part of your system at another provider is a base URL and a key, exactly as pointing it here was. Reach for an external model when you need a capability ours does not have — a much longer context, a specific tool-calling behaviour, or a model you have already evaluated against your own data.

​
Pin the version, not the alias

Every id has an unversioned spelling — nur-tts for nur-tts-v1 — and it resolves. It also follows whatever version is current, so an unversioned id in production means the model under you can change without a deploy. Use the versioned id you tested against. Keep the alias for exploration.
The API also answers to OpenAI’s names. tts-1, whisper-1, gpt-4o-transcribe and gpt-realtime all resolve to the EESI model serving that job, which is what lets an existing OpenAI client work by changing a base URL. See Migrating from OpenAI.

​
Ask the deployment what it serves

Each backend is opt-in per environment. A model with no backend configured is not listed and answers 404 model_not_found, so the set of ids on your laptop, your staging cluster and production will differ. Read the catalog rather than hardcoding an id.

​
Going further

Capabilities

What each model does, in detail, with the request shapes.

Pricing and rate limits

What each one costs and the ceilings you can hit.