VEED Fabric speed_tier fast: what it changes on Sume

On Sume's VEED Fabric 1.0 route, speed_tier fast picks the fast queue. Same fields, same per-second rate, same 300 s limit. What changes and what does not.

4 min readSume
All posts

On POST /v1/veed/fabric-1.0, speed_tier: "fast" sends the job to the Fabric 1.0 fast queue instead of the standard one. It does not change the price: Sume bills Fabric per second of audio, with one rate for 480p and one for 720p (480p $0.10/s, 720p $0.1875/s), and the current pricing code reads only the audio length and the resolution.

The field description is from Sume's Sume API reference and the Models overview; the pricing and payload behavior is from Sume's API code, read 2026-09-29. Sume's docs do not publish queue wait times for either tier, so this post puts no number on them.

What does speed_tier fast change?

Only the queue the render goes to. The request body is otherwise the same, and the fields Sume forwards for the render are the still, the audio URL and the resolution.

Fabric 1.0 request, from the Sume API reference, the Models docs and API code, read 2026-09-29.
Fieldstandard (default)fast
QueueFabric 1.0 queueFabric 1.0 fast queue
PricePer audio second by resolution (rate card lists $0.1875 per audio second (720p))Same rate; pricing takes audio seconds and resolution only
Audio length1 to 300 seconds1 to 300 seconds
Resolution480p or 720p (default)480p or 720p (default)

Does fast cost more?

No, not in current code. Admission prices a Fabric job from duration_seconds rounded up to a whole second and the resolution; the speed tier changes the queue label on the estimate but not the rate. Because the amount reserved at admission comes from the duration_seconds you send, send the measured length of the audio, not a guess.

Should I send fast or leave the default?

Leave it off unless a queue wait is hurting you, for example while iterating on a script with a person waiting. Since the price is identical, there is no cost reason to avoid it, but the docs also give no quality reason to prefer it. Nothing in the Sume docs or the payload code describes a visual difference, so compare one clip of each on your own still before you switch a production flow.

curl -X POST https://api.sume.com/v1/veed/fabric-1.0 \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://example.com/presenter.png",
    "audio_url": "https://media.sume.com/example/narration.mp3",
    "duration_seconds": 12,
    "resolution": "720p",
    "speed_tier": "fast"
  }'

Can I wait for a fast render in one request?

No. mode: "sync" blocks for at most wait_timeout_seconds (30 at most) and then returns the current job state, so a Fabric render that runs longer is still finished through the job's status URL. Use mode: "webhook" with a webhook_url to be called once when the job completes, fails or is canceled, and keep polling available as a backup.

Which other limits stay the same?

The audio must be on the Sume media host and no larger than 10 MB; other hosts are rejected. Send exactly one visual source: image_url or an avatar id or handle. The still-plus-audio body is shared with the H3 Max lip-sync route, which has its own audio window of 5 to 14.8 seconds. For the full request, see lip sync from a photo and audio.

Sources

Related posts

More in Sume Avatar 1.0

All Sume Avatar 1.0 posts

Written by Sume