Eight avatars on Sume: $7.60 to create, $117.60 for 24 plus clips

A cast of eight Sume Avatar 1.0 characters costs 8 x $0.95 = $7.60 to create. If each character then appears in three 20-second videos at the plus tier, that is 24 videos x 20 seconds x $0.245 = $117.60, so the whole cast and its first round of videos costs $125.20.

Creation is a one-time line item

The catalog prices avatar creation at $0.95 per avatar, described as one-time creation for reusable Avatar 1.0 video workflows. The docs offer three input types: a text prompt, structured profile traits (the props type) and a reference image (the photo type). The catalog lists a single creation price, so the three paths cost the same.

Each request needs a top-level avatar_handle. A leading @ is accepted and stored without it, so pick handles that are stable keys in your own system.

Plan the handles before you create anything. A leading @ is stripped on storage, so @product_host and product_host are the same handle. Eight distinct handles also keep your records tidy: one row per handle with the creation job id, the input type, and the date.

Video seconds dominate

Creation is 6 percent of the total here ($7.60 of $125.20). The lever is the per-second tier: the same 480 seconds at standard cost 480 x $0.184 = $88.32, and at max 480 x $0.55 = $264.00. Choose creation count by how many distinct faces you need on screen, and choose the tier by how the clips will be used.

The preview flow helps at cast scale. A first-frame preview is a still; it shows the composition before the video render. For 24 videos at 20 seconds, a single wasted plus render costs 20 x $0.245 = $4.90, so checking previews pays for itself after the first caught mistake.

• One resolved avatar appears in each final video, so a two-person scene needs two jobs.
• Use the preview flow to approve first frames before spending on a render.
• Send an Idempotency-Key on every create and render so a retry does not duplicate a charge.

Photo avatars and permission

When you create an avatar from a reference image, the image_url must be a fetchable public HTTPS image. The docs rule on URL safety, not on whose face is in the photo, so keeping a record of who agreed to the use of each likeness is your process, not something the API checks.

Naming and ownership deserve a line in your process. Each avatar is a stored resource you can list with GET /v1/avatar-1.0/avatars and read by id, so a weekly job can reconcile the list against your own register of who is who. If an avatar is no longer wanted, stop using its handle in new requests; the docs describe creation and reading, and they do not describe a price for keeping an avatar, so the cast has no running cost beyond the renders.