Hedra Elements library vs Sume avatar handles: reusing one character

To use the same character in many videos on Sume you create an avatar once and then pass its avatar_handle (or avatar_id) to every later request. Hedra's page lists Elements, described as a library of characters, outfits and environments. The two ideas overlap on characters; the difference is that Sume stores a single avatar identity with a voice, and it does not list a catalog of outfits or environments.

What is listed

The Hedra description is from its June 1, 2026 announcements page. The Sume facts come from the Avatar docs and the repo.

Set up a reusable character on Sume

Treat the creation as a one-time step and keep the handle in your own config.

• Create the avatar with POST /v1/avatar-1.0/generate, using a Prompt, a Profile or a photo.
• Wait for the job to finish. The docs describe a 4 second voice-sample video at 480p and a 5 second idle video at 720p as part of creation.
• Store the returned handle. A failed avatar releases its handle, so you can retry the same name.
• Pass the handle in POST /v1/avatar-1.0/talking-video, or on the lip-sync route in place of image_url.
• Keep the script short: talking videos run 4 to 60 seconds in the Avatar 1.0 docs.

What Sume does not do

There is no outfit or environment library in the Sume Avatar docs. To change the setting you use a scene prompt or a scene photo on the talking video, and to change the character's look you create another avatar. Hedra's Elements listing is the more catalog-like feature; Sume's is the more explicit one, because the handle names exactly which identity a request used.

If you need many looks of one person, plan one avatar per look, and name them so you can tell them apart. The handle is a stable key for logs, consent records and billing reports.

Handles in the request

A short example shows the shape. The talking-video body takes a script and an avatar handle, and the lip-sync body takes the same handle in place of an image. Both routes are asynchronous, so you create the job, keep its id, and read the result from the jobs endpoints. Use an Idempotency-Key on each create call; the stored posts on avatar creation show that a retry with the same key is charged once.

Handle names are also useful for QA. When a reviewer sees a clip, the handle in your log tells them which avatar was used, which is harder to say about a pick made from a visual library.

A note on consent

Whenever a face comes from a real person, keep the consent record next to the handle. A handle makes that simple: one row per handle, with who agreed and when. That is a habit worth having before you scale to dozens of looks.