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.

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.
| Field | standard (default) | fast |
|---|---|---|
| Queue | Fabric 1.0 queue | Fabric 1.0 fast queue |
| Price | Per audio second by resolution (rate card lists $0.1875 per audio second (720p)) | Same rate; pricing takes audio seconds and resolution only |
| Audio length | 1 to 300 seconds | 1 to 300 seconds |
| Resolution | 480p 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
- YouTube likeness detection: setup, limits, AI avatars
YouTube likeness detection finds videos that alter or fake your face. Who can enroll, what it scans, review actions, and what it means for avatars.
- 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.
- Avatar video previews: approve the first frame before rendering
Create an avatar video preview to get first-frame stills, regenerate them if needed, then call generate-video on the preview id to render the final video.
Written by Sume