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:
- The API estimates the action’s credit cost from the model + duration
(or text length, for voice).
- 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.
- 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
| Plan | Monthly credits | Hits zero? |
|---|
| Free | 45 | Top up or wait for the monthly refill |
| Starter | 200 | Top up or upgrade |
| Creator | 450 | Top up or upgrade |
| Studio | 1200 | Top 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
| Plan | Monthly credits | Price | Max resolution | Notes |
|---|
| Free | 45 | $0 | 720p | Onboarding |
| Starter | 200 | $19 | 720p | Personal projects |
| Creator | 450 | $39 | 1080p | Most popular |
| Studio | 1200 | $99 | 4K | Teams |
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:
| Limit | Default | Env var |
|---|
| Max final-video duration | 3 min (180 s) | MAX_VIDEO_DURATION_SEC |
| Max upstream spend per generation | $30 | MAX_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.