Connect by JBRH Open Connect

What a setting cannot change

Some of what happens on a call belongs to the model, not to you. The quality review marks a finding MODEL_LIMITED when the model's own first token accounts for 60% or more of the wait, lists it, counts it, and deliberately does not lower the call's score — because a score that punishes you for something no setting reaches is a score you stop reading.

Status
Available What this means
Audience
both
Channels
phone
In the app
#/phone
Last verified
Product version
6.3.2

The line between a control and a ceiling#

Every knob in the Voice Lab is one of two kinds and says which. An engine knob becomes a session parameter — the model, the voice, a pinned language, temperature, the end-of-speech silence, the interruption thresholds, noise cancellation. A steering knob becomes a line of instruction the model is asked to follow — speed, energy, warmth, pauses, fillers, formality. The first kind changes what the runtime does. The second kind changes what the model is asked to do, and a model may decline.

voice_quality.review is written on that distinction. A deterministic finding — a slow reply, a long gap, an ignored interruption, a false stop, repetition, a stock phrase, the wrong script, a caller who was not heard — arrives with the setting change that addresses it. When the wait was mostly the model thinking, there is no setting to name, and the review says so instead of inventing one.

MeasurementClassificationWhat the review offers
Reply inside 2.5 sOn targetNothing — the reply is fine
Reply past 4 s, model's first token under 60% of the waitA finding with a controlThe specific setting: shorter replies, a smaller brief, faster end-of-speech detection
Reply past 4 s, model's first token 60% or more of the waitMODEL_LIMITEDThe reason, and no control — turning a knob would not move it

MODEL_LIMITED findings are listed and counted, and they do not reduce score. score_all is the older number that included them, kept so the two can be compared rather than deleted. Read score to judge your configuration; read score_all to judge the call.

Two behaviours that were rolled back rather than left in#

Both were tried as prompt instructions, measured, and removed. They are written down here because the obvious next idea is to try them again.

Respect-word cadence
A rendered rule asking for the Telugu respect particle *andi* at the right cadence changed nothing measurable — six of eight replies were unaffected — and one English sentence came back answered in Telugu. The rule cost prompt characters, which cost first-token time, and bought nothing.
Murmur handling
Gemini writes a mumble down as a word in some language and answers it. A prompt sentence telling it not to changed nothing. conversation.is_murmur, murmur_reactions and murmurs_accepted exist to *measure* how often this happens, not to fix it.

Other places the ceiling shows#

  • The default model takes no mid-call notes. Gemini 3.1 Flash Live is fastest to first audio, and the SDK marks its session immutable. A supervisor's guidance and the worker's own nudge cannot reach it: a stalled reply is recorded as nudge {via: none}, a note as undelivered, guidance as guidance_undeliverable. Choosing the 2.5 native-audio model buys mid-call notes and costs roughly a second per reply.
  • Affective dialog is refused on 3.1 with error 1007. It is a native-audio feature, and the Lab shows it as available only on a model that has it.
  • No check-in and no goodbye is spoken on 3.1. The text-to-speech voice carries the live voice's name but not its sound, so a spoken interjection would arrive in a different voice. The silence is recorded instead, and the hang-up watcher ends a genuinely abandoned call without a word.
  • The floor on the realtime path is the model's first token plus its end-of-turn detection — 3.3 s median on the best measured call, not the one to two seconds a demonstration suggests.
  • rt_ack_after_ms stays off. A host-spoken "Mm-hm." on a 3.1 call cut the caller off and stalled the model for 22 seconds.

What to do with a model-limited review#

  1. Read the finding's reason before changing anything.

    Result If it says the model's own first token dominated the wait, no amount of tuning on that call's settings will change the number.

  2. Look at what you can still shrink — the brief, the knowledge budget, the persona block, the reply length.

    Result These do not make the model faster, but they make it think about less, and that is measurable.

  3. Consider the model itself as the setting.

    Result Model choice is an engine knob. Swapping models is the one control that moves a model-bound number, and it trades against mid-call notes and affective dialog.

Questions#

Why does a call with several findings still score well?

Because the findings were model-limited. score counts only what a setting could have changed. If you want the number that includes everything, read score_all beside it — the review shows both so the difference is visible rather than argued about.

Can I ask the voice to use a politeness particle at the right moments?

You can write the instruction, and the human voice profiles include politeness markers such as *andi*, *ji*, *-nga* and *po* as directions the model approximates. What was proven not to work is a cadence rule — telling the model *when* to place the particle. It changed six of eight replies not at all and once switched the reply's language.

Is a model-limited finding worth reporting?

It is worth reading. It is the difference between a line that is badly configured and a line that is running into the model underneath it, and those two problems have completely different answers.