Providers

gemini-3.5-transcribe-live

The Google speech-to-text model gemini-3.5-transcribe-live, with every setting it accepts, the allowed value and the default.

Google's streaming recogniser, and the transcriber that writes numbers as digits: on the same audio it returned "25 milligrams" where Deepgram's Nova, on its own defaults, spelled out "twenty five milligrams". It settles on the language itself unless you name one.

Reached through the LiveKit Inference gateway.

One model, and the two settings below are the only keys OnCore sends to it. This is the one provider on the platform where that is a narrow allowlist rather than a passthrough, and the reason is in the warning below. Note what is absent: this model has no end-of-turn setting, so unlike Deepgram's Nova there is no endpointing to tune here, and when the caller has finished speaking is decided for you rather than by the transcriber.

Read this before using gemini-3.5-transcribe-live

This model refuses any key it does not recognise, and LiveKit publishes that outright: unrecognised keys are rejected when the session starts. Measuring agrees. A session opened with an invented key never opened at all, and the error named the offending key.

Because that failure costs the whole call, OnCore sends this model customVocabulary and languageCodes and nothing else, whatever else your transcriber settings contain. So a misspelled key here is discarded before it can reach Google rather than ending the call: what you lose is the setting, not the conversation. Spell both keys exactly as this page spells them, because a near miss is not corrected for you.

That narrowing is specific to this provider. On Deepgram an unfamiliar key travels to the provider and is ignored there instead. Either way a misspelling does nothing, and on neither provider does anything tell you so.

Settings#

Every setting is optional. Leave one out and OnCore sends nothing for it, so the Default applies. If invalid is what the provider does with a value it does not accept.

Setting	Type	Allowed	Default	If invalid
`customVocabulary`	array of strings	terms to bias recognition toward, up to 1000 entries of up to 200 characters each	no biasing	Refused, call fails
`languageCodes`	array of strings	up to 32 of the language codes listed below	automatic detection	Refused, call fails

Overriding on a single call#

Return this from your assistant-request webhook to change these settings for one call only. The stored transcriber is left untouched, and the next call starts from it again.

json

{
  "data": {
    "overrides": {
      "transcriber": {
        "settings": {
          "customVocabulary": [
            "OnCore",
            "reservation"
          ],
          "languageCodes": [
            "en"
          ]
        }
      }
    }
  }
}

Send only the keys you want to change: anything you leave out keeps the value the assistant already has. Add "id" beside "settings" to swap the whole transcriber for another one from your catalogue at the same time.

customVocabulary: Names the model would otherwise miss, such as a brand or a menu item. The 1000 entry limit and the 200 character limit on each entry are LiveKit's published ones, and both are enforced where it hurts: measured on 2026-09-03, 1000 entries opened a session and 1001 did not, and one 200 character entry opened where one of 201 characters did not. Over either limit the session never opens, so the call is lost rather than the setting. The effect is large when it works: five invented surnames came back 1 of 5 correct with the key absent and 5 of 5 with the terms sent. A bare string where an array is published was accepted and still biased recognition, so the published type is not enforced. There is no published default vocabulary, so leaving the key out biases recognition toward nothing at all.

languageCodes: This is the multi-language form of the transcriber's language, and LiveKit publishes it as taking precedence over it. Set both and the codes here are the ones that apply, so an assistant configured for fr that receives ["en"] in this key recognises English on that call. Published as BCP-47 tags such as en-US, up to 32 of them, and a bare en was accepted. The count is checked and the contents are not: measured on 2026-09-03, 32 entries opened a session and 33 did not, so going over costs the call, while ["xx-XX"], which is not a language at all, opened a healthy session and quietly fell back to detecting the language itself. A typo here costs you the setting with nothing to show it, so send codes from the published list below. Leave the key out and the model settles on the language itself; that is how it ran with nothing set.

Both settings were measured on a live session on 2026-09-03. Both reach Google, both change the transcript, and both are refused when they go over their published cap.

Languages#

Leaving both the transcriber's language and languageCodes unset is the one setting to avoid on a bilingual call. Measured on 2026-09-03 against an English-then-Spanish stream, that configuration dropped the English half in four runs out of four, while an explicit two-code languageCodes list kept both halves in three runs out of three. Name the languages you expect rather than relying on detection.

OnCore fills languageCodes for you from the assistant's own candidate languages when you set none, so a multilingual assistant gets the list without doing anything. Your own value always wins, and an assistant locked to one language derives nothing.

The language this model reports back is the one you asked for, not the one it heard. Arabic audio with nothing set comes back labelled en, so a transcript's language field is an echo of the request. Anything that keys off it is reading its own input; OnCore detects the caller's language from the transcript text instead.

LiveKit publishes support for 26 languages: ar, cs, da, de, el, en, es, fi, fr, he, hi, id, it, ja, ko, nl, no, pl, pt, ru, sv, th, tr, uk, vi and zh. All 26 opened a session on 2026-09-03 with no warning. Transcription itself was checked on three of them, es, ja and ar, each returning the spoken line exactly; the other 23 are published support rather than something a call has proved.

To hold detection to a known set rather than all 26, name those codes in languageCodes. The model still works out which language is being spoken, but only from the set you give it. See multi-language calls.

What this model does not return#

It returns the transcript text and the language it recognised, and LiveKit publishes three absences alongside that: no word timings, no per-word confidence and no speaker labels. Measured on 2026-09-03 the first two are worse than absent. The per-word list arrives empty rather than missing, and confidence arrives set to 1 on every result, interim and final, so a confidence threshold reads a constant and passes everything. Gate on the transcript text, not on either field. Each one rules out a job this transcriber might otherwise look right for. There is nothing here to align a transcript back to the audio with, nothing to threshold a doubtful word on, and no way to tell two people apart on a shared handset. For speaker separation, AssemblyAI Universal-3.5 Pro publishes a speakerLabels setting.

Where the model runs#

LiveKit publishes this model as served from a single global deployment, because Google publishes no regional endpoints for the API behind it. A session that pins its request to a region does not route to it, so an assistant relying on a particular region for its other models does not get one here.

The two settings are the whole set#

Google publishes a much wider recognition API than a voice assistant uses, and on this route nothing outside these two keys is sent at all. So a transcriber body carried over from another provider does not partly work here; the parts that are not these two keys simply never leave.

Next steps#

ElevenLabs: speech-to-text from ElevenLabs.
Providers introduction: per-call overrides, and how a wrong value behaves across providers.

Previousstt-1 NextScribe v2 and Scribe v2 Realtime