Prompt, props or photo avatar: all three cost $0.95 on Sume

Creating a Sume Avatar 1.0 avatar costs a flat $0.95 whichever of the three inputs you use: a text prompt, structured profile traits (the API's props) or a reference image (photo). The pricing page and rate card list one creation price per avatar.

The three inputs

All three go to POST /v1/avatar-1.0/generate with a top-level avatar_handle and an input union. Each request creates a job; poll it until it completes and the avatar becomes a reusable resource.

Rules that differ by input

The price is the same, but the constraints are not. For a photo, image_url must be a fetchable public HTTPS URL; Sume rejects localhost, private-network and non-HTTPS URLs, and non-image responses before it submits. A prompt and a profile have no URL to validate.

• 10 prompt + 10 props + 10 photo avatars: 30 x $0.95 = $28.50.
• Handles can start with @; Sume stores them without it.
• Add the Idempotency-Key header so a retried request returns the same job and does not create a second avatar.

Choosing an input

Use a photo when you hold the rights to that face and need the avatar to look like that person. Use a prompt or props when you want an invented presenter. Since the fee is identical, choose on rights and look, not cost. The video spend afterwards is where the money goes: one 30-second Plus clip is 30 x $0.245 = $7.35, about 7.7 times the avatar fee.

Practical notes

Reading results. A completed result can include public media.sume.com video artifacts, and for avatar videos also public-safe preview fields such as preview_image_url and scene_previews. You can list or read finished videos with GET /v1/avatar-videos and GET /v1/avatar-videos/{id}. Store the job id and the video id together so a billing line can be traced back to a creative.

Reusable avatars. An avatar is created once, for a flat $0.95, and then referenced by its avatar_handle on every later request. Sume normalizes a leading @ away and stores the handle without it. Treat the handle as a stable identifier in your own system, and keep one record per handle noting who the avatar represents and what it may be used for.

Idempotency. The docs examples send an Idempotency-Key header on every create call. Use one key per intended job and reuse it only when you retry the same request. A network timeout followed by a fresh submit with a new key is the one path that can create, and bill, a second job. Keep keys human-readable, such as the campaign and scene, so a support lookup is easy.

Job lifecycle. Every Sume avatar request is job-backed. You submit, store the job id, and poll GET /v1/jobs/{id}/status until it completes, then read GET /v1/jobs/{id}/result. The shared lifecycle also lets you wait with sync or subscribe mode for a limited time instead of polling, and the result carries Sume-hosted artifacts rather than provider URLs, so you never handle a provider queue id. Plan your client around the job, not around a single blocking response.