Managing renders + costs
Where renders live, how long provider video links last, how to download them, and how to keep spend under control with caps and your own keys.
Managing renders + costs
Every stitched MP4 lives in the gallery at /app/gallery (the Renders
filter — the old Renders tab now redirects there) with a download link,
the duration, and the per-render cost in dollars. On BYOK there's no
markup — what fal/ElevenLabs/etc. bill is what you see. On Varosity
Credits a render costs the provider's list price.
Per-render cost
Each shot's cost_cents is stamped at completion based on the
registry's pricePerSec × duration. The Renders view sums them per
project for the total.
Heads-up: provider pricing changes. The registry is updated in migrations; if your in-flight bill diverges from what we display, the provider's number wins.
Daily spend cap (API keys)
Each API key (vsk_…) has its own daily spend cap, set per key at
/app/keys/api-keys. It applies to calls made with that key (REST, MCP,
CLI); signed-in use in the studio is not capped. The day resets at
00:00 UTC.
- Each call reserves its estimated cost against the key's day before
- anything is generated.
- Media-driven models (OmniHuman, lip-sync, LivePortrait, Wan Animate,
- HeyGen, D-ID) bill the real length of the supplied audio or video, and
- so do transcription, dubbing and the voice changer. On
- Varosity Credits that real charge is added to the key's day when the
- job finishes, so the key's next call can be refused even though the
- previous one was accepted.
- A REST call over the cap returns HTTP 429 with
-
code: "daily_cap_exceeded"(plusspent_today_centsand -
daily_cap_centson video, voice and music) and noRetry-After - header; an MCP tool call fails with an error saying the cap is exceeded.
- Retrying does not help: it keeps failing until the 00:00 UTC reset or
- until you raise the cap.
- If the cap can't be checked,
POST /api/v1/video/generate,/api/v1/tts - and
/api/v1/musicreturn HTTP 503 withcode: "spend_guard_error"and - nothing is generated.
Held renders (not enough credits)
On Varosity Credits, a render that finishes when your balance can't cover
it is held, not delivered. Polling GET /api/v1/jobs/{jobId} keeps
returning status: "rendering" (or "queued") with
code: "insufficient_credits", outputUrl: null and an error message
giving the amount. Add credits at /app/credits and poll again: the next
poll charges it and returns succeeded with the URL. A held render is
kept for 24 hours.
Cleanup
Images, voice, ElevenLabs Music and stitched project videos are stored by Varosity. A single shot's video URL is the provider's own link, which the provider may delete: Replicate removes outputs after about an hour, and other providers keep them for a limited time. Download a video you want to keep as soon as it finishes. Delete from the gallery when you don't need an item. There is no storage charge.
Why a render failed
The shot card shows the provider's reason inline when it helps (e.g.
Invalid prompt: must be < 2000 chars, or a moderation refusal).
Internal errors — stack traces, adapter messages, database text — are
replaced with a plain "Something went wrong with this render" and you
aren't charged for the failed render.