Skip to main content

What costs credits

Generation is the only paid step. Rendering - stitching your generated clips into the final video - is free, and it’s reuse-aware: it folds in clips you already generated and never re-charges them. So “generate the scenes, then render the video” costs exactly the scenes, and re-rendering to tweak the edit or audio is free. Use estimate_cost to see the price before you spend.

How limits actually work

Every paid generation goes through a server-side credit gate:
  1. The API estimates the action’s credit cost from the model + duration (or text length, for voice).
  2. It reserves that many credits from your balance. Reserve fails → immediate 402 insufficient_credits with the exact needed / have you can show in your UI.
  3. The work runs and the hold is settled to what was actually delivered: every clip we produced is charged (it’s a clip the provider billed us for), and any clip that never generated is released.
That means you only pay for clips actually produced. A render that fails after making some clips charges only for those - you keep them and re-render for free - and one that produces nothing costs nothing. A timeout, a model outage, or a content-policy rejection on a clip never charges for that clip.

What hitting the limit looks like

HTTP/1.1 402 Payment Required

{
  "error": {
    "code":    "insufficient_credits",
    "message": "Need 10 credits, you have 4.",
    "needed":  10,
    "have":    4,
    "plan":    "starter",
    "topup_url": "/Pricing"
  }
}
The SDK and the canvas both surface a “Top up” CTA on this code, clicking it sends the user straight to Pricing.

Per-plan ceiling

PlanMonthly creditsHits zero?
Free45Top up or wait for the monthly refill
Starter200Top up or upgrade
Creator450Top up or upgrade
Studio1200Top up or upgrade
Unspent credits carry over every month, the monthly refill tops you back up to the plan ceiling, it doesn’t reset you to zero.

Allowlisted accounts

Internal accounts on a server-side allowlist bypass the credit gate entirely. The monthly USD cap still applies, it’s not a free pass to infinite spend.

The reserve / settle pattern

Every paid action holds credits first, then settles to what was delivered:
       reserve(amount)  ───────────▶ token + hold placed

       settle(token, delivered/reserved)

            ├── all delivered  ▶ full amount debited
            ├── some delivered ▶ charge that fraction, release the rest
            └── none delivered ▶ full release (free)
Why hold first? Because a multi-scene generation can fail mid-flight. Reserving up front ensures you can’t oversell credits even if 50 renders fire in parallel and one hits a model timeout 90 seconds in. Settling to the delivered fraction means a partial failure charges only for the clips that were actually produced - never a blanket refund of work the provider already billed us for, and never a charge for clips you never got. The SDK does this for you transparently. Agents talking to the API directly just reserve before generating; the server settles the hold when the job reaches a terminal state.

Plans

PlanMonthly creditsPriceMax resolutionNotes
Free45$0720pOnboarding
Starter200$19720pPersonal projects
Creator450$391080pMost popular
Studio1200$994KTeams
Unspent credits carry over month to month. The “monthly pool” just refills up to the plan cap, it doesn’t reset to zero.

Per-action cost

Costs are denominated in credits, not dollars, so we can adjust upstream pricing without you re-budgeting. Roughly:
  • 720p video, 5 s: 5-10 credits depending on the model picked
  • Voiceover, 30 s: 2 credits
  • Music bed, 30 s: 3 credits
  • Still image: 1 credit
The authoritative per-model numbers come from get_status, your agent should read those before committing a multi-shot plan.

Monthly cost cap

Independent of credits, every account has a monthly upstream cost ceiling. When that ceiling is hit, paid endpoints return 402 monthly_cost_cap until the next month rolls over. This is a safety belt for autonomous agents, even an unlimited plan won’t let a runaway loop burn an arbitrary amount of money in a weekend. See GET /v1/usage/monthly and the cost-aware skill.

Per-video limits

Independent of credits and the monthly cap, every single generation is bounded by two hard guardrails so a prompt - or a runaway agent - can’t queue an absurdly long or expensive video:
LimitDefaultEnv var
Max final-video duration3 min (180 s)MAX_VIDEO_DURATION_SEC
Max upstream spend per generation$30MAX_VIDEO_GENERATION_USD
The duration cap is the sum of all scene durations; the budget cap is the estimated upstream cost of the clips actually being generated (reused clips cost nothing). create_render, generate_scene, and the single-clip video endpoint all enforce them before queuing, returning 400 video_too_long or 402 video_over_budget with an actionable message. Both are operator-tunable via the env vars above - no code change needed to raise or lower them. Call estimate_cost first to see where a workflow sits against these limits before you spend.