# 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
- **Audience:** both
- **Channels:** phone
- **In the app:** #/phone
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/phone/model-limits/

## 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.

| Measurement | Classification | What the review offers |
|---|---|---|
| Reply inside 2.5 s | On target | Nothing — the reply is fine |
| Reply past 4 s, model's first token under 60% of the wait | A finding with a control | The 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 wait | `MODEL_LIMITED` | The 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.

> **Careful** Do not spend prompt characters on either. Instruction size is on the record: about 7,500 characters gave a 1.2–1.8 s first token and about 9,600 gave 2.3–3.4 s. A rule that changes nothing still makes every reply on every call slower.

## 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.

> **Note** A page of findings with no controls attached is not a broken review. It is the review telling you the configuration is already at its limit, which is worth knowing before somebody spends a week on it.

## 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.

## Related

- [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/)
- [The Voice Lab](https://connectbyjbrh.com/docs/phone/voice-lab/)
- [Findings a setting cannot fix](https://connectbyjbrh.com/research/model-limited-findings/)
- [Reply latency on a call](https://connectbyjbrh.com/docs/phone/latency/)
- [Human voice profiles](https://connectbyjbrh.com/docs/phone/human-voice-profiles/)
- [What every character of a prompt costs on a live call](https://connectbyjbrh.com/research/prompt-size-and-first-token/)

## What this page is based on

- Connect phone source pack — `docs-source/sources/PHONE.md` §6, the Voice Lab and its review
- Connect phone source pack — `docs-source/sources/PHONE.md` §7, the model and the conversation layer
- Connect capability registry — `docs-source/facts.py` (`voice_lab`, `MEASURED`)