Tavus max_participants counts the face: seats vs a shareable clip

In a Tavus conversation the face counts as a participant, so max_participants: 2 allows one human plus one face. A third viewer cannot join once the limit is reached. A Sume avatar video has no seats: it is a finished MP4, and the limit you plan around is how many render jobs your workspace can run, not how many people watch.

This matters when the plan is a demo for a group: a live session is one conversation per room, while a rendered clip is a file you can send to everyone.

What the Tavus parameter says

Tavus's participant-limits page defines max_participants as the control on how many participants are allowed in a conversation, notes that faces are counted, and says that when the limit is reached additional users cannot join. The page does not state a default or a numeric maximum (Tavus docs: Participant Limits). If you need an audience larger than one, ask Tavus what your plan allows before building the flow.

What limits Sume instead

Sume limits paid generation by processing concurrency and queue capacity: Free runs 1 and queues 5, Pro runs 4 and queues 20, Startup 8 and 40, Scale 20 and 100. A full processing limit does not reject submits; valid jobs wait as queued until a slot opens, and only a full queue returns 429 queue_full (Generation admission).

So a campaign that personalises one clip for 200 recipients is a 200-job plan, paced by the queue, and the audience for each finished clip is whatever you decide.

• Live and rendered can be combined: a live session for the first call, a rendered recap clip for the people who were not on it.
• Treat the media URL as shareable: store the media.sume.com URL and serve or embed it yourself.

Choosing by audience size

One viewer who needs to ask questions is a live conversation. Many viewers who need the same message is a rendered clip. In between, such as a small group meeting, the number of seats matters and you should confirm it with Tavus.

For rendered clips the cost is per job, not per viewer, so reuse is free. Generate once, host the file and share the URL. Only personalise per recipient when the personalisation changes the words, because each variant is a separate paid render.

Whichever you pick, test the experience for the last allowed viewer, not only for the first.

A planning example

Say a team wants 50 prospects to see a personalised greeting. On a live platform that is 50 conversations, each with a seat for the prospect and one for the face. On Sume it is 50 render jobs, queued as capacity allows, and 50 files that each prospect can open at any time afterwards.

The second approach moves the bottleneck from attendance to rendering, which you can schedule overnight. The first gives richer interaction but needs the prospect to be present.