Varosity
All guides

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" (plus spent_today_cents and
  • daily_cap_cents on video, voice and music) and no Retry-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/music return HTTP 503 with code: "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.