Nova 3, Nova 3 Medical and Nova 2

The three silence-based Nova transcribers OnCore runs: nova-3, nova-3-medical and nova-2. All three decide the caller has finished when the audio goes quiet for endpointing milliseconds.

nova-3 is the current generation and the default choice, and it covers the most languages. nova-3-medical is the same generation tuned for clinical speech, and it is English-only, though it publishes two English variants nova-3 does not: read the languages below before assuming nova-3 is the wider choice. nova-2 is the previous generation, kept for assistants already using it; prefer nova-3 for anything new.

Reached through the LiveKit Inference gateway.

Deepgram has two transcriber families and they take different settings, so each family has its own page. Check the model on your transcriber before tuning.

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.

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.

{
  "data": {
    "overrides": {
      "transcriber": {
        "settings": {
          "endpointing": 300,
          "punctuate": true,
          "smartFormat": true,
          "fillerWords": false,
          "interimResults": true,
          "noDelay": true,
          "numerals": true,
          "keyterm": [
            "Sadie",
            "reservation"
          ]
        }
      }
    }
  }
}

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.

endpointing: Measured on nova-3-medical, a word rather than a number is refused and the session never opens. 25 against 1000 changed only how many interim results arrived. Neither a negative value nor an implausibly large one was ever sent, so treat the bound as advice: a large value would leave the assistant waiting through long silences.

keyterm: Published for the Nova-3 models only, so nova-3 and nova-3-medical read it and nova-2 does not. On nova-2 OnCore leaves it out of the request rather than passing it on, because Deepgram fails the handshake over it there and a failed handshake means the whole call transcribes nothing. nova-2's own equivalent is keywords, which nova-3-medical refuses, so no single spelling is safe across all three: set the terms for the generation you are on.

The three share this set because it is published as one set: LiveKit lists a single parameter table for the whole Nova family rather than one table per model, and it gates exactly two keys by generation, keywords to Nova-2 and keyterm to Nova-3. That is why one page covers the three. nova-3-medical is nova-3 with a clinical vocabulary and it takes the same transcriber body. Where the three genuinely differ is language coverage and where the model runs, and neither of those is set from the table above.

Languages#

nova-3 covers the most: 83 published language codes, spanning Arabic, Chinese and most of Europe, plus multi for a call that changes language part way through. nova-2 publishes 53 of the same kind, also with multi. LiveKit publishes one caution on multi that is easy to miss: on both models it covers fewer languages than the model's own monolingual list, so naming the language you expect beats reaching for multi when there is only one. nova-3-medical is English only, and that is published as well as measured: a session opened with de was refused at session start with the gateway naming the model, so there is no multilingual mode to fall back on. See multi-language calls.

The published language tables understate nova-3, and that trips up an easy assumption. nova-3-medical publishes eight English variants: en, en-US, en-AU, en-CA, en-GB, en-IE, en-IN and en-NZ. LiveKit's nova-3 table lists six of them, leaving out en-CA and en-IE. Measured on 2026-09-03 both of those open a session on nova-3 and transcribe correctly, indistinguishably from the en-US and en-GB controls, so the gap is in the published table rather than in the model. A Canadian or Irish English caller is served by either model. What is real is that nova-3-medical is English only: a German session was refused outright at session start.

Where the model runs#

LiveKit keeps a Deepgram deployment colocated with the agent in Mumbai and routes to it automatically when the model and language match one it publishes: deepgram/nova-3-general in English, Hindi and multi, deepgram/nova-2-general in English and Hindi, and deepgram/flux-general in English. Every other combination goes out to Deepgram's own API.

nova-3-medical is not on that list. An assistant serving callers in India gives up the colocated deployment by choosing it, and pays the round trip out to Deepgram on every turn instead. That is heard as a slower reply rather than reported as an error, so nothing will point at it. Where response time in that region matters more than the clinical vocabulary, nova-3 is the model that keeps the colocation.

Keys in the table, and keys carried through#

The table above is the set of keys OnCore models. It takes each one in OnCore's own camelCase, converts it to the name Deepgram expects, and this page states the value it takes.

Every other key LiveKit publishes for the Nova family is carried through untouched. OnCore keeps no list of permitted Nova keys on this route, so a key it does not model is not discarded on the way out: it is forwarded exactly as you spelled it. The gateway in front of Deepgram is stricter than OnCore, though, and it accepts only the keys it publishes for this family. That cuts both ways.

Against you, a key outside the published set never reaches Deepgram at all, and nothing says so. Measured on 2026-09-03: utterance_end_ms, multichannel, alternatives and encoding are all real Deepgram parameters that Deepgram itself rejects outright when sent directly, and every one of them ran through this route with a clean transcript, which is only possible if the gateway dropped them first. A misspelling behaves the same way. keytrem produces a healthy session with no biasing applied and nothing anywhere to say why, and the only signal is a transcript worse than you expected.

In your favour, the wider Nova surface is available to you even though it is not in the table. The next section lists it.

A wrong value on a key the model does know fails loudly instead. Measured on nova-3-medical, each of endpointing set to a word, channels set to a word, redact set to a term Deepgram does not publish, and version set to a model that does not exist stopped the session opening. So a bad value is loud and a bad key name is silent, and only the first will ever show up on a test call.

The rest of the Nova surface#

These are the keys LiveKit publishes for the Nova family that are not in the table above. OnCore does not convert their names, so spell each one exactly as it appears here, in Deepgram's own snake_case, and it reaches Deepgram as written.

Measured on 2026-09-03, redact does exactly what it says: it replaced a card number, an account number and a social security number with [CREDIT_CARD_1], [ACCOUNT_NUMBER_1] and [SSN_2], all three published values work, and an unrecognised value refuses the session. Three others do nothing useful here. detect_language is refused outright on the streaming path this route uses, and that costs the call rather than the setting. search returns its hits somewhere the platform never surfaces. utterance_end is published as a boolean that is not a real Deepgram parameter, so it is accepted and ignored: Deepgram's own flag is utterance_end_ms, an integer, and the gateway drops that one before it reaches Deepgram. The rest were measured working. profanity_filter masked a profanity with asterisks, dictation turned a spoken "period" into the mark itself, and replace swapped a term in both its string and its list form. version reaches Deepgram and checks its value, refusing a model that does not exist. tag opened a healthy session and shows up nowhere a call can see, which is what it is for: it labels the request in Deepgram's own usage reports.

Two published keys are refused by OnCore rather than forwarded, and both would cost you the call. channels set to anything other than one produces a healthy session, no error, and an empty transcript on the mono audio a phone call carries, so the assistant hears nothing at all for the whole conversation. vad_events crashes the gateway in front of Deepgram on the first word. OnCore drops both before the request leaves, vad_events in either spelling. callback, callback_method and extra are published for this family as well. callback describes a completed batch transcript rather than a live call and is refused outright, which costs the call; callback_method was accepted with nothing to show for it; and extra carries whatever you put in it straight into the request.

redact is the one on that list to make a deliberate decision about, and a clinical assistant is exactly where it comes up. It changes the transcript itself rather than what is displayed, so a card number or a social security number redacted here never reaches your end-of-call report, your webhooks or your own systems, and one that is not redacted reaches all three. Decide which of those two you want before the first call rather than after.

Two spellings that go nowhere#

Each of these is the camelCase name OnCore models on the Flux transcribers. On a Nova transcriber that means they are neither converted nor carried through, so they do nothing at all.

• Deepgram publishes the singular tag. Send tag, not tags.
• Deepgram publishes mip_opt_out. Send mip_opt_out, not mipOptOut.

diarize is published for the Nova family and is the one published key that does not reach Deepgram from here at all. That name is a setting on the xAI transcriber, so on a Nova transcriber it is dropped before the request leaves and no speaker labels appear. Sent straight to the gateway it does work, and measured that way on 2026-09-03 it labelled both speakers correctly on every word of a two-speaker recording, so what stops you here is the name clash rather than the model. Where two people on one handset have to be told apart, AssemblyAI Universal-3.5 Pro publishes a speakerLabels setting that is carried.

confidenceThreshold is not a Deepgram setting, so it has no effect on these models.

Boosting recognition of specific terms#

Two routes reach the same keyterm parameter, and which you want depends on whether the terms change from one call to the next.

Terms that belong to the assistant go in a dictionary. Attach it once and the terms ride every call with nothing in the transcriber body. That is the route to prefer, and the one that page documents.

Terms that are only right for one call go in keyterm in a per-call override, in the shape shown above. A caller's own surname, the drug on today's prescription, the clinic that referred them: none of those belongs in a dictionary attached to the assistant, and each is worth biasing for the two minutes it matters.

Next steps#

• Flux: the next Deepgram model.
• Providers introduction: per-call overrides, and how a wrong value behaves across providers.