ENGINEERING NOTE · SEPTEMBER 27, 2026

Measure voice-agent latency where the user waits

For a push-to-talk agent, measure from button release to perceptible feedback and to the first audible reply—not just the time spent generating text. Record reply completion separately. A fast host trace cannot establish that the intended device played anything.

Three measurements, three different questions

Release to feedback: when does the interface acknowledge that the turn left capture mode? A visible or audible acknowledgement should describe receipt, not imply that an external action succeeded.
Release to first reply audio: when does the user hear the actual answer? A waiting tone is not the first answer sample. Report the observation method, including any instrumentation delay.
Release to reply completion: when does playback finish, fail or get interrupted? Keep these outcomes separate; a shortened failed reply must not improve a completion statistic.

Also inspect host stages: upload receipt, transcription, queue wait, agent work, speech synthesis and transport. In a streaming pipeline these can overlap, so adding their durations can overstate total elapsed time. Keep the device-observed end-to-end interval alongside stage spans instead of substituting one for the other.

Keep clocks honest

Use a monotonic elapsed-time clock within each process. The W3C High Resolution Time working draft explains why wall-clock adjustments can distort durations. That browser API is not an ESP32 timing implementation. Device and host counters have separate origins: do not subtract a raw device timestamp from a host timestamp. Correlate events with a turn identifier and retain local durations; a cross-machine timeline needs an explicit synchronization method and uncertainty.

A repeatable test card

Fix the firmware and host revision, audio format, utterance, reply length, model configuration and network conditions. Record cold-start versus warm runs rather than mixing them.
Observe button release, first feedback, first audible answer and playback termination on the same physical test setup. Label host-only fixtures separately.
Repeat across short and long requests, idle and queued hosts, and good and degraded Wi-Fi. Publish trial counts, failures and interruptions alongside median and tail latency; do not silently drop timeouts.
For a disconnected turn, record whether the job ran and whether the device heard it. An unknown delivery outcome is not zero latency, and reconnect is not authorization to repeat a side effect.

The useful debugging question is then concrete: did the user wait for upload, queue admission, synthesis, or device playback? Choose the next experiment from the measured slow stage rather than promising a universal latency target.

Clarilot's present evidence boundary

This is a proposed measurement plan, not a Clarilot benchmark. The current host prototype contains separate reply-delivery and playback-report handling. Firmware compilation and software tests are distinct from physical validation: microphone pickup, speaker output, button timing, battery behavior and device-network performance remain unvalidated on the intended pocket hardware. No measured end-to-end latency or arbitrary-agent compatibility is claimed here. The public site is a preview and waitlist, not an agent gateway.

Join the Clarilot email waitlist for project updates. Joining is not a hardware reservation or a beta-access guarantee.