Skip to content
OnCoreDocs

Providers

Introduction

The speech and language providers behind an assistant, how to change their settings for a single call, and what happens when a value falls outside its range.

Every assistant runs on three providers: one to hear the caller, one to think, and one to speak. You pick them by ID from the voice, model, and transcriber catalogues, and each entry carries the provider settings that shape how it behaves on a call.

This section documents those settings per model. That is not a formatting choice: two models from the same provider often accept entirely different keys, and setting one model's key on another is not an error, it simply does nothing.

Find your model#

Start from the model your assistant actually uses. Each page lists every setting it accepts, the allowed values, the default, what happens when a value is wrong, and a ready-to-send override body.

Text-To-Speech (TTS)#

Speech-To-Text (STT)#

Models (LLM)#

Where settings live#

Provider roleCatalogueSettings carried in
Speech-to-textGET /transcribersbody on the transcriber
Text-to-speechGET /voicesbody on the voice
Language modelGET /modelstemperature and maxTokens on the model, and nothing else

Keys on a transcriber or a voice are camelCase. Language-model settings are passed to the provider exactly as written instead, so those keep the provider's own spelling: max_completion_tokens, not maxCompletionTokens. Each model page shows the spelling to send. A model carries no settings body of its own, so every language-model setting beyond those two reaches the provider as a per-call override and no other way. The one exception is a realtime model: GPT-Live 1 stores its settings on the model's catalogue entry itself, platform managed, its override keys are camelCase, and its page states its own rules. A key you leave out is simply not sent, so the provider's own default applies. Setting a key to the value you believe is the default is not the same as omitting it: it pins that value, so a later change to the provider's default will not reach you.

Changing settings for one call#

Everything above is stored configuration, shared by every call the assistant takes. To change a setting for a single call instead, return an overrides object from your assistant-request webhook. Nothing stored is modified, and the next call starts from the saved configuration again.

Each of the three channels takes the same two levers, and they compose:

json
{
  "data": {
    "overrides": {
      "transcriber": {
        "id": "0195f1e2-0000-0000-0000-000000000000",
        "settings": {
          "endpointing": 300,
          "smartFormat": true
        }
      },
      "voice": {
        "id": "0195f1e2-0000-0000-0000-000000000000",
        "settings": {
          "speed": 1.0,
          "stability": 0.5
        }
      },
      "model": {
        "id": "0195f1e2-0000-0000-0000-000000000000",
        "settings": {
          "temperature": 0.7,
          "maxTokens": 250
        }
      }
    }
  }
}
  • id swaps the whole row for another entry from that catalogue. Use it to run one call on a different voice, model, or transcriber.
  • settings merges over whatever that channel resolved to, whether that is the row you just swapped in or the assistant's saved one. Only the keys you send change; the rest keep their stored values.

Send whichever channels you need, and only the keys you want to change. An empty or absent overrides object leaves the call exactly as configured. An id that does not match a row in your catalogue is ignored rather than reported, and the call continues on the saved configuration, so check the ID if an override appears to do nothing.

The keys inside settings are the ones documented on each model page, so check the page for the model that will handle the call. A key that model does not accept is not an error: depending on the provider it is forwarded and ignored there, or it prevents the session from opening, which is what the next section is about.

Settings and IDs compose

Swapping a model with id and sending settings in the same request applies your settings to the model you swapped in, not to the assistant's saved one. That is what makes a single override able to say "use the multilingual transcriber for this call, and slow it down a little".

How a provider is reached#

Two routes, and the difference decides which settings can take effect at all.

  • Through the LiveKit Inference gateway, which accepts a documented set of options per provider and validates them before opening a session. Most models work this way.
  • Through the vendor's own client, which takes a fixed set of arguments. Settings outside that set cannot be carried.

Every model page states its route, because it decides whether a setting is honoured or ignored.

What happens when a value is wrong#

This is the part worth reading before you tune anything. Providers do not agree on how to handle a setting they dislike, and only one of these is loud. Each model's table names the behaviour per setting, in the If invalid column, and says so plainly where nobody has tested it.

BehaviourWhat you observe
Refused, call failsThe session does not start. The call fails within a few seconds of connecting.
Refused, failover answersA language model rejects the value, and nothing surfaces as an error. Automatic failover answers that turn from another model, on its own settings, and the reply reads perfectly normally.
Refused, transcriber falls backThe value is caught before the session opens. The call continues on the default transcriber rather than the one you chose.
Ignored, default appliesThe key is dropped and the default applies. The call runs normally, and nothing indicates your setting had no effect.
Used as sentThe call runs with your value. If it is outside the sensible range, turn-taking or delivery degrades with no error anywhere.
Lowered to the ceilingThe platform caps the value below the range the provider publishes, because the top of that range does not work. Anything higher is lowered rather than sent, so you get the ceiling and no error.
Not measuredNobody has sent this model a value outside the range, so there is no answer to give you. Stay inside the Allowed column and treat it as advice rather than as a bound the provider was seen to enforce.

An out-of-range value can end the call

On some models a number outside its documented range is not clamped or ignored, it is refused, and the session never opens, so the caller is dropped seconds into the call. Stay inside the ranges on these pages, and change one setting at a time on a test assistant before applying it to a live one.

The practical consequence: a setting that does nothing and a setting that ends every call look identical from the outside until you place a call.

Changing settings safely#

  1. Open the page for the exact model your assistant uses, not just the provider.
  2. Change one setting, ideally as a per-call override on a test assistant, keeping the stored value untouched.
  3. Place a real call. A refused value shows up immediately: the call ends within seconds of connecting.
  4. Listen for the effect you intended before applying it more widely. A value inside its range but wrong for your callers degrades the conversation without failing.

Next steps#

PreviousChurn auditsNextFlash and Turbo