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.
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).
| Sume status | Terminal | What to show |
|---|---|---|
queued | No | Accepted; waiting for a slot. Show a neutral waiting state, not a failure. |
processing | No | Rendering. Keep the page usable or offer an email or notification. |
completed | Yes | Fetch the result and show the video. |
failed | Yes | Show the public error and offer a retry as a new request. |
canceled | Yes | Confirm 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
- AI favicon for Google Search: square, over 48 px, stable URL
Google wants a square favicon bigger than 48 px at a URL that stays put. How to make one with the Sume image API, what it costs, and what no tool can promise.
- AI image API timeouts in Python: httpx above 30 s, 200 or 202
Sume's image endpoint holds a request up to 30 seconds, then returns 202 with a job. A runnable httpx example with a 40 second client timeout.
- Editing an image five times with AI: keep PNG between passes
Each JPEG save adds error that stays in every later edit. A Pillow test of PNG against JPEG over five passes, and the format to request from Sume.
- AI presenter video from a script: first clip in Python on Sume
Make an AI presenter clip from a script in one Python file: submit to /v1/avatar-1.0/talking-video, poll to terminal, read the result. Costs and limits.
Written by Sume