Latency budgets for talking plush: what each added second costs

Buyers of talking plush never ask about latency and always judge it. A toy that answers “too late” feels broken even when every word is right. Budgeting latency is therefore a design task from day one.

The four clocks that run in sequence

Wake and capture: the toy must start listening within a few hundred milliseconds of its wake cue. Recognition: on-device or on-phone recognition takes a few hundred milliseconds; cloud recognition adds the round trip. Reasoning or translation: this is the variable one — half a second on-device, several seconds in the cloud. Synthesis and playback: streamed speech can start in under a second; clip playback is instant.

The budget conversation we have with clients

For companion plush, we recommend a hard ceiling: total first-response under about two seconds when cloud is involved, under half a second for canned responses. Everything above that ceiling needs a designed waiting behaviour — a sound, a motion, a phrase — because unexplained silence reads as failure.

Where the seconds hide

Streaming instead of waiting for full responses saves the most. Keeping recognition on the phone for Bluetooth tiers saves the cloud leg. Choosing phrase libraries over open dialogue saves the reasoning step entirely. Each of these is an architecture decision, not a tuning knob.

The sleep-side budget matters too

Wake-word listening drains battery. An always-listening toy needs a low-power wake path — a hardware wake word engine or a button-press wake. The latency budget and the power budget are the same document read from two ends.