Connect by JBRH Open Connect

The response watchdog

When the caller has stopped speaking and nothing has started coming back, the worker asks for a reply. The threshold rt_response_watchdog_ms defaults to 5.5 seconds — comfortably above any normal first token — and only real speech disarms it. Set it lower and it fires during ordinary generation, cancelling the very reply it was waiting for and making the call slower rather than faster.

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

What the watchdog is for#

A realtime call can stall in a way a request-response system cannot. The caller finishes, the turn ends, and nothing begins on the other side — no error, no timeout from anybody's point of view, just an open line and a person waiting. The watchdog is the answer: after rt_response_watchdog_ms of that, the worker calls generate_reply() and asks for one.

It is armed by the end of the caller's turn and disarmed only by speech. Not by an event, not by any internal state, not by a partial transcript: audio coming back is the only thing that proves the stall is over, which is the same principle as measuring latency on the wire rather than from transcript rows.

Why 5.5 seconds and not three#

The default was 3 s. It looks like the responsible choice — a caller should not wait three seconds — and it made calls measurably worse. Call C paid 3–7 second first tokens for it.

The mechanism is worth stating exactly, because it is not obvious: a nudge issued while a generation is already in flight cancels that generation. Generation was two seconds along, the watchdog fired at three, the in-flight work was thrown away and it started again from the beginning. Every early nudge bought itself a fresh first token.

ValueWhat happens on a normal turnEffect
Below the first-token timeFires while generation is under wayThe reply is cancelled and restarted; the caller waits longer
5.5 s (default)Sits above measured first tokens, including a slow oneFires only on a real stall
Very highRarely firesA genuine stall becomes a long silence the caller ends themselves

The session that cannot be nudged#

On Gemini 3.1 Flash Live the SDK marks the session immutable, and that closes the same door the nudge uses. The worker still detects the stall and still records it — the event carries nudge {via: none} — but nothing is delivered. The same constraint is why mid-call notes come back as undelivered and supervisor guidance is recorded as guidance_undeliverable there.

This is a real trade rather than a bug to route around. 3.1 gives 0.6 s to first audio against 1.2–2.2 s for 2.5 native audio; 2.5 accepts mid-call notes, guidance and nudges. Pick 2.5 when steering a live call matters more than a second per reply, and know that on 3.1 the watchdog is an instrument rather than an intervention.

Either way the stall is on the record, which is what makes it reviewable: call quality review counts them, and a line that stalls repeatedly has a session or brief problem, not a timer problem.

What it is not#

  • It is not the silence check. That watches the *caller* going quiet; the watchdog watches Connect going quiet after the caller has finished.
  • It is not a retry for a failed session. A model session that refuses to start is opened once more on the same model and once on the fallback, and model_session_restarted goes on the record.
  • It is not a way to make replies faster. Its best-case contribution to a healthy call is nothing at all, because it never fires.

Questions#

Should I lower the watchdog to make the line feel snappier?

No, and this is the one setting where the intuitive direction is reliably wrong. Lowering it below the model's first-token time means firing during normal generation, and a nudge cancels a generation in flight. The way to make replies faster is a smaller brief, shorter replies, or a faster model.

How do I know whether the watchdog fired on a call?

The nudge is an event on the call, and it carries how it was delivered — including via: none when the session would not accept it. A call with several nudges is telling you something about the session or the prompt size, not about the timer.

Does the nudge say anything to the caller?

Nothing is spoken by the watchdog itself. It asks for the reply that should already have started; whatever the caller hears is that reply. Nothing is inserted into the line, and nothing is said while the caller is speaking or was heard within the last 2.5 seconds.