Choosing a live video avatar for your website: a buyer's checklist

The face is the easy part of a live video avatar; the choice is everything around it

It's Tuesday, and someone on the team has watched a talking face answer questions on a pricing page. By Friday there's a shortlist: Anam, Tavus, HeyGen's LiveAvatar, Beyond Presence. The faces will all look convincing in a demo, because a demo is built to show the face.

What separates the vendors for a team putting one on its own site is everything around the face: where the vendor's code runs on your page, what starts the meter, what ends a session, what the visitor is told, whose face it is, and where the conversation goes afterwards. The same questions apply whether a vendor calls it a live avatar, an interactive avatar API or a conversational video interface.

Each section below is one of those questions, with what four vendors' own documentation says about it, read on 6 October 2026. Vendors change these details, so treat each as the place to start your own check, and ask for the current answer in writing.

Ask where the vendor's code runs: in a frame, in your page, or in code you write

There are three shapes, and most vendors offer more than one. A frame puts the vendor's own page inside yours as an iframe. Beyond Presence embeds an agent from bey.chat this way, LiveAvatar's Embed mode loads a short-lived address your server asks for, Anam calls its version the Player, and Tavus documents an iframe of the conversation_url it returns when a conversation is created.

A component runs the vendor's script inside your page. Anam's widget is an <anam-agent> web component and Tavus offers a <tavus-embed> element; both render in a shadow DOM and, in their simplest install, load their script from unpkg. An SDK hands you the media streams and leaves the interface to you: Anam's JavaScript SDK, LiveAvatar's Web SDK and Beyond Presence's route through a LiveKit client all work that way.

The shape decides what your page has to trust. A frame keeps the vendor's code in the vendor's origin, and it needs your permission to reach the visitor's microphone — the iframe snippets Tavus, LiveAvatar and Beyond Presence publish all carry an allow attribute naming it. A component runs with your page's privileges, so your Content Security Policy has to admit it, and a script that tracks the latest release changes when the vendor publishes; Tavus's install notes point to a versioned URL for pinning one. An SDK is the most work and the most control.

Whichever shape you pick, the vendor's API key belongs on your server. Anam documents short-lived session tokens created server-side for the browser, and LiveAvatar's embed address comes from a server call made with your key. Anam also asks you to list the domains its widget may run on.

Find out what starts the meter, and set what ends a session

Tavus, LiveAvatar and Anam all count usage by session time, so the question that decides a bill is when the clock starts and what stops it — and their documentation draws the start line in different places.

Tavus says credits begin counting when a conversation is created and its AI participant starts waiting in the room. LiveAvatar charges per minute of session time and starts the session before it issues the browser's token, so the time your front end spends setting up isn't metered. Anam records session duration in seconds, and says plainly that silence, a muted microphone or an idle avatar doesn't pause a session that's still active.

Then bound every session at the vendor, from your server. Tavus has max_call_duration for the longest a call may run, participant_left_timeout for how long to wait after the last person leaves, and participant_absent_timeout for a conversation nobody joins. Anam's maxSessionLengthSeconds caps a session, counted from the moment the persona starts streaming.

A limit in your own front end is a courtesy. One the vendor enforces is a bound, and it's the one still holding when a visitor's laptop goes to sleep with the tab open.

Decide who tells the visitor it's an AI, and keep the label on screen

A realistic face on a call is where a visitor is most likely to take an AI for a person, so the label matters most here. The practical question for a buyer is who draws it.

Anam's documentation says its own hosted experiences, such as share links and meeting invites, carry a built-in AI avatar disclosure that stays visible throughout the session. In an SDK integration, where your application draws the interface, you switch on the same watermark per session with showAIAvatarDisclosure, set when your server creates the session token.

Whoever draws it, check three things. The label says AI in words — as Anam's page puts it, a company or product name on its own may not tell anyone the avatar is AI-generated. It's there from the first moment. And it survives every state of the interface, minimised or full screen. Anam's page also notes that requirements vary by jurisdiction, audience and use case, which makes it a question for your own counsel as well as your vendor.

Know whose face it is before it talks to your customers

Every stock face in a vendor's library came from somewhere, and a custom face starts from footage or a photo of someone. Before a face speaks for your company, find out which kind it is and what permission stands behind it: for a stock face, what uses the vendor's terms exclude; for a custom one, what the vendor asks of the person on camera.

That question has a guide of its own.

Know where the transcript lands, and who joins it to the customer

A video conversation with a prospect is a sales conversation, and afterwards its value is the transcript. The vendors here either send it to you or wait for you to fetch it.

Tavus sends it: with a callback address set on the conversation, an application.transcription_ready event arrives after the call ends, each turn with its role, its words and when it began. Anam waits to be asked: its API returns a session's transcript on request, and never for a session run under zero data retention. LiveAvatar has a transcript endpoint per session, and Beyond Presence offers webhook events for its managed agents and an endpoint that lists a conversation's transcribed messages.

A transcript is only as useful as the record it lands on. Whichever way it arrives, decide before launch which code receives it, matches it to the person or company it belongs to, and stores it where your team already works.

Runner's website agent is a marked portrait beside a text chat, not a video call

Runner doesn't put a live video call on your website. A two-way video call with a visitor is not offered.

Runner's website agent ships switched off. Once your team turns it on, it appears as a marked portrait beside a text conversation, and whatever name and title you give it, the words AI agent appear beside them unless your own wording already says it's an AI. No setting takes them away.

If a live video call is the job you're buying for, the questions in this guide are the ones to take to each vendor.

Take these questions to every vendor call

Ask each of these, and expect a sentence about the product with a page of the vendor's documentation behind it, never a promise about the roadmap.

• –Where does your code run on our page: in an iframe, as a component inside our page, or through an SDK we build on?
• –Which origin asks the visitor for their microphone, and what does our Content Security Policy need to allow?
• –Can we pin the script's version, and does our API key stay on our server?
• –What starts the meter — creating the conversation, the visitor joining, or the first word — and what ends it?
• –Which session limits can our server set, and what happens when nobody joins or everyone leaves?
• –Who draws the AI label, does it say AI in words, and does it stay on screen in every state?
• –Is this face a stock actor or a custom face, and what permission stands behind it?
• –Is the transcript sent to us or fetched by us, and what's kept when we ask for no retention?