mistv3

Rime's current Mist generation, and the only Rime model in this catalogue. Its speed control works per line or per bracketed span, so one sentence can be slowed where it matters and left alone elsewhere.

Reached through the LiveKit Inference gateway.

The voice and the language have to agree on this provider. A voice is refused rather than substituted when it does not cover the language on the call, so the two are changed together or not at all.

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 voice is left untouched, and the next call starts from it again.

{
  "data": {
    "overrides": {
      "voice": {
        "settings": {
          "speedAlpha": 1,
          "inlineSpeedAlpha": "0.5",
          "pauseBetweenBrackets": true,
          "phonemizeBetweenBrackets": true
        }
      }
    }
  }
}

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 voice for another one from your catalogue at the same time.

speedAlpha: Below 1.0 is slower and above 1.0 is faster, which is the reverse of the direction LiveKit's own parameter table publishes for this model. Measured: 0.7 stretched a 2.98s line to 5.66s, and 1.4 cut it to 1.61s. Nothing bounds the value in either direction, so 100 rendered the same line in 0.58s and -1 in 0.54s, both without an error. Only 0 came back at the baseline duration, which is what a value being dropped looks like.

inlineSpeedAlpha: Paces only the text inside square brackets. The brackets go in what the assistant says and the multiplier goes here, so the line Please [follow] me to your table. with "0.5" paced the word follow alone. Measured below 1.0 as faster, the opposite of what speedAlpha does on the same model: that "0.5" cut the line from 1.75s to 1.55s. LiveKit publishes a direction of effect for speedAlpha and none at all for this key, so the direction here is measurement rather than a published contract. One span with one valid multiplier is the whole measurement, and nothing Rime would refuse was ever sent, so try a multi-span line on a test call before relying on it.

pauseBetweenBrackets: Turns a <500> marker in what the assistant says into a pause of that many milliseconds. Leave it off and the marker is read out loud instead, which is the failure a caller actually hears. Measured on 2026-09-03: with the flag the render carries a 600ms silence exactly where the marker sat, at the same total duration, and transcribing the audio back shows the marker spoken as a word without it. An earlier measurement scored this key inert because it compared total duration only, which this flag does not change.

phonemizeBetweenBrackets: Reads text inside curly braces as phonemes rather than as letters, so Welcome to {h'El.o} Bistro. speaks the braced part from the notation. It is off unless you set it: the same line took 1.95s with the flag and 1.67s without, so the braces are read as ordinary letters until you turn this on. The notation is Rime's own rather than IPA. Only true was sent, so there is no measurement of what Rime does with a value it dislikes. OnCore's dictionary pronunciations do not reach this model, so this flag is the only way to spell a word out phonetically on a Rime voice.

Three markups, three kinds of bracket#

This model reads three markups out of the text the assistant speaks, and the setting names are not a reliable guide to which bracket each one uses. Getting them the wrong way round is the most common way to set one of these and hear nothing change.

Voices confirmed on this model#

cove, astra, luna, summit and talon for English, and isa for Spanish, each verified by rendering a line through the gateway. Voice IDs come from your GET /voices catalogue. Leaving the voice unset also renders, on some default voice, and which one could not be established: this model is non-deterministic, so two renders of the same voice and the same line differ in bytes and in length, which leaves nothing in a render that identifies the voice behind it. Name the voice you want rather than relying on whatever the default resolves to.

Languages#

LiveKit publishes five language codes for mistv3: en, es, fr, de and hi.

English and Spanish were confirmed on a live render, and a voice has to match the language: isa spoke Spanish, and cove on a Spanish call was refused. French and German are verified: juliette and alois render French, frieda and klaus render German. Hindi is published for this model and does not work. Every attempt was refused outright, including with a Hindi voice, while the same voice and language render on rime/coda, and Rime's own catalogue lists no Hindi voice for mistv3. Treat the model's real coverage as the other four codes: en, es, fr and de. A voice has to match the language in both directions: cove on a Spanish call is refused, and so is isa on an English one. A non-English voice also needs the call's language set explicitly, which neither vendor documents.

Rime models this catalogue does not carry#

mistv3 is the only Rime model OnCore runs, and that is a limit of this catalogue rather than of Rime.

rime/coda is the one to know about. LiveKit publishes it as the Rime default in its own agent builder and as the replacement for the deprecated rime/arcana, and it publishes eight language codes against mistv3's five: it adds ja, pt and ar to en, es, fr, de and hi. So an assistant that needs a Rime voice speaking Arabic or Japanese is asking for something Rime has and this catalogue does not carry yet. Ask before designing around its absence.

coda also takes a different parameter set, which is worth knowing before treating the section below as Rime behaviour. LiveKit publishes speedAlpha and timeScaleFactor for it and not pauseBetweenBrackets, phonemizeBetweenBrackets, inlineSpeedAlpha or noTextNormalization, so the bracket markups on this page are a Mist feature rather than a Rime one.

Two keys that are carried but do nothing#

timeScaleFactor and noTextNormalization are forwarded on this route and accepted without error, and neither changed the audio.

timeScaleFactor has a published default of 1.0 and is published for mistv3 and coda and for no other Rime model, with mistv2 published as raising an error rather than ignoring it. Measured on 2026-09-03 it is simply inert: 1.3 gave 3.03s against a 2.98s baseline, inside the jitter band of the model rendering the same line twice, and mistv2 accepted and ignored it rather than erroring, so the published error does not happen either. LiveKit publishes the reason it cannot work here: the key applies to Rime's HTTP synthesis, and a call is rendered over the streaming socket, where speedAlpha is the only speed control.

noTextNormalization has a published default of false and does not turn digit normalization off here. 7:30 PM on 25 August for 4 guests was spoken as words with the flag set and without it, and five renders of the flagged line came back character-identical, so an apparent wording difference in an earlier measurement was the model's own variation rather than the flag. LiveKit publishes the flag for mistv3; Rime's own docs list it for the earlier Mist models, and the measurement matches Rime. Leave it alone.

An unrecognised key is accepted and ignored as well, so a misspelled setting leaves no trace anywhere. That is the permissive end of the range. Google speech-to-text is the one model that would end the session over the same mistake, which is exactly why OnCore never sends that one a key it does not model.

Next steps#

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