Regenerate avatar preview stills, or start a new preview?
Regenerate refreshes first-frame stills from the stored preview request. Changing script, avatar, scene or aspect ratio needs a new preview. The full rule.
Call POST /v1/avatar-video-previews/:id/regenerate when you only want different first-frame stills for the same request. It reuses the stored preview request (avatar, script or video_inputs, scene, quality and aspect ratio) and returns the same avatar_video_preview_id with a new preview-only job. If you need to change any of those structural fields, create a new preview instead.
This follows Avatar video previews; the final-render side is in Generate avatar video.
What can change without a new preview?
Two things. First, regenerating refreshes the stills. Second, generate-video can take an optional quality that overrides the final render tier only. The docs say preview stills are tier-independent and always reused, so approving a preview and then going up or down a tier does not need a new one. An empty body or {} keeps the quality chosen at preview create.
What forces a new preview?
The docs list the structural fields: script, video_inputs, avatar_handle, scene and aspect_ratio. They require a new preview because the first frame depends on them.
| You want to change | Action | Same preview id? |
|---|---|---|
| Nothing, just a different still | POST /regenerate | Yes |
| Final render tier | POST /generate-video with quality | Yes |
| Script or video_inputs | New preview | No |
| Avatar handle | New preview | No |
| Scene or aspect ratio | New preview | No |
| Captions style | Set at preview create; applied at generate-video | Stored with the preview |
How do the stills behave for multi-scene requests?
Previews return preview_image_url for the primary still (scene 0 for multi-scene) and scene_previews[], one still per input scene when available. For a multi-scene request with a shared scene, the docs say later scene stills are pose-anchored continuations of the first frame. The docs do not spell out how regenerate treats each scene still, so look at scene_previews[] after every regenerate.
What does the full loop look like?
Create the preview, poll its job, read GET /v1/avatar-video-previews/:id, regenerate until the framing is right, then call generate-video. Sume reuses the preview first frame when available. Captions stored on the preview are applied at that last step; preview stills are never caption-burned. The cheaper habit is in previewing before paying for a render; this post only adds the rule for what regenerate can and cannot touch.
How do I decide when stills are good enough?
Check the things a still can show: face framing, how the avatar sits in the scene, product visibility if you passed product_image, and how the background reads at your target aspect ratio. A still cannot show speech timing or lip movement, so a preview approves composition only.
If two regenerations in a row still miss, stop regenerating. The stored request is the same each time, so a persistent problem usually sits in the scene or the script, and the fix is a new preview with a changed structural field.
What does this cost in practice?
This post does not quote prices. The docs say the preview stage generates the first-frame still without starting the full render, and that generate-video admission, pre-spend and ledger reservation use the effective quality tier. For the numbers, use a dry run or your dashboard; see avatar video cost by quality tier.
Sources
Related posts
More in Sume Avatar 1.0
- Sume Avatar API: canonical routes vs the legacy model-run aliases
Which Avatar 1.0 endpoint should a new integration call? The canonical /v1/avatar-1.0 routes, with the legacy aliases kept for compatibility. All paths listed.
- Tavus Memory Stores vs Sume: personalizing avatar video per person
Tavus PALs now keep persistent memory per participant. Sume avatar videos are one-shot renders, so personalization is in the script you send. Here is the split.
- Introducing Sume Avatar 1.0
Sume Avatar 1.0 is a multi-agent orchestration system as a single avatar model.
- Avatar Face Swap API (Beta): apply an avatar face to a video
Avatar Face Swap 1.0 is a Beta Sume endpoint that applies a ready avatar's face to a short public source video. Required fields, limits, and polling.
Written by Sume