2026-10-10

Hedra batch_size 1-8 variations vs Sume's one job per request

Hedra's API returns 1 to 8 variations per request; Sume avatar videos are one job each. How to get variations on Sume with previews and keys (read 2026-10-10).

5 min readSume

All posts

Hedra's Generate Asset reference describes a batch_size field of 1 to 8, the number of video variations to generate in one request. Sume has no such field on the avatar endpoint: one POST creates one job, and you get variations by sending several requests, each with its own Idempotency-Key.

Hedra's field is from Generate Asset, read 2026-10-10. Sume's behavior is from Generate avatar video and Jobs and results.

Side by side

Where the Hedra page does not state how a batch is billed, the cell says so rather than guessing.

Variations and retries (Hedra reference read 2026-10-10; Sume per docs.sume.com)
Question	Hedra	Sume Avatar 1.0
Variations per request	`batch_size` 1 to 8	One job per POST
Where the results arrive	`batch_results` when more than one, per the reference	One result per job
Batch billing	Not stated on the page I read	Each job is priced on its own
Retry safety	Not stated on the page I read	Same `Idempotency-Key` returns the same job
Cheaper looks before commit	Not stated	Preview stills first, then final render

Getting variations on Sume

The cheapest way to see three takes of one presenter is the preview stage, not three full renders. POST /v1/avatar-video-previews creates first-frame stills, regenerate refreshes them from the stored request, and only generate-video starts the render. Preview stills are tier-independent, so you can approve a frame once and pick quality afterwards.

If you do want several full renders, for example a 20-second script in three tones, submit three requests with keys like promo-a, promo-b and promo-c. A retry after a timeout then returns the same job instead of billing a second render.

Parallel limits

Sending eight POSTs is fine on Sume, but the workspace has a concurrency limit, so jobs beyond it wait as queued. They are not failures. If you track them with webhooks, one endpoint receives every terminal event, and the job_id in each is your idempotency key on the receiving side.

For a spreadsheet of scripts, Bulk runs is the route built for many rows, rather than a loop of your own.

A simple variation script

A loop that posts three requests with three different keys is all you need. Store each key next to the tone it represents, so you can find it again. Because the same key always returns the same job, you can rerun the loop after a crash without paying twice.

Compare the three results side by side before you scale. When one tone wins, reuse its script for the rest of the series on the same avatar, and spend the premium tier only on the final cut if the standard tier already looks right.

Price a variation set before you run it

Variations multiply cost linearly on Sume because each is a separate job. Three 15-second standard variations are 3 x 15 x $0.184 = $8.28. Eight would be 8 x $2.76 = $22.08. At plus the eight cost 8 x 15 x $0.245 = $29.40.

So preview stills are the economical way to explore. Use them to settle composition, then spend on one final render at the tier you need, rather than rendering eight finals and discarding seven.

When one request for many would help

A single request returning several takes is convenient for a human at a keyboard: one call, one wait, one set to compare. The Sume equivalent trades that convenience for control. You decide how many to start, each has its own status and failure, and a bad script costs you one job, not a whole batch. For large sets of different scripts, queue them through a worker pool and let the workspace concurrency limit smooth the load.