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.

5 min readSume
All posts

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.

Which action for which change, read 2026-10-02
You want to changeActionSame preview id?
Nothing, just a different stillPOST /regenerateYes
Final render tierPOST /generate-video with qualityYes
Script or video_inputsNew previewNo
Avatar handleNew previewNo
Scene or aspect ratioNew previewNo
Captions styleSet at preview create; applied at generate-videoStored 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

All Sume Avatar 1.0 posts

Written by Sume