AI avatar waiting UX: Tavus hair check vs Sume queued status

Tavus hides the join delay with a hair check before the live room; Sume jobs sit in queued or processing with no queue position or ETA.

5 min readSume
All posts

Tavus's latency guidance is to let the user set up camera and microphone in a hair check while the agent joins, and to enter the live room only once the agent is there. Sume jobs have a different wait: they move from queued to processing to a terminal state, and the API exposes queue counts but no per-job queue position or ETA. Both waits need an interface; neither can be removed.

Design the wait as part of the product, not as an afterthought to a spinner.

What Tavus recommends

The Tavus page gives no latency numbers. It recommends waiting until the agent has actually joined before dropping the user into the room, so the start feels instant instead of an awkward silence, and running Daily's testCallQuality() before the call. Results come back as good, warning, bad, failed or aborted; the page says to warn the user on warning or bad, and to log and handle failed or aborted (Tavus docs: Reducing Join Latency).

What Sume exposes while you wait

A Sume job is queued while it waits for a workspace slot, processing while it runs, then completed, failed or canceled. queued is a normal state. Sume says it currently exposes queue counts and remaining capacity, not a precise queue position or ETA, and that sync and subscribe modes wait up to 30 seconds, after which you keep polling the job id (Generation admission).

What the user sees while waiting, by status (read 2026-10-03)
Sume statusTerminalWhat to show
queuedNoAccepted; waiting for a slot. Show a neutral waiting state, not a failure.
processingNoRendering. Keep the page usable or offer an email or notification.
completedYesFetch the result and show the video.
failedYesShow the public error and offer a retry as a new request.
canceledYesConfirm and offer to resubmit.

Patterns that work

Because a render is not instant, the best experience is to let the user leave. Store the job id, poll while the page is open, sleeping for the next_poll_after_seconds each reply gives (back off when it is absent), and use a signed webhook to trigger an email or push when the job reaches a terminal state (Webhooks).

  • Show real progress: when a job has an events endpoint, read it rather than animating a fake percentage.
  • Preview first: a first-frame still lets the user approve the look before the full render is paid for.
  • On queue_full, tell the user to try shortly. Do not retry in a tight loop.

Copy and timing

Write the waiting copy for the real states. For queued, say the request is accepted and waiting. For processing, say it is being made. Do not show a percentage that you cannot read from the API, and do not promise a time that Sume does not publish.

If the user must wait on the page, give them something to do: edit the next script, review captions, or pick a thumbnail. If they can leave, say so and tell them how they will be notified.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume