What open-source video generation costs

The per-second rate card

Six open-weight video models, with the publisher's official per-second rate alongside ours and the cost of a five-second clip. Every one of these carries a licence that permits third-party hosting -- that is a precondition for being listed, not a feature.

Three incompatible billing units in one market

The reason video pricing is hard to compare is that nobody agrees on what to charge for. Three units are in active use, and converting between them requires information the buyer usually does not have.

Per second of output is the only unit that lets you budget from a rate card, because seconds of finished video is the thing you actually want. Per video is blunt: it either overcharges a short clip or leaves the duration and resolution unstated. Per GPU-second is the hardest to plan against, because the cost of a request depends on how long the model happened to run -- a cold start or an unlucky prompt costs more, and there is no number you can multiply to get a monthly figure.

Our video calls are fixed at five seconds, and the API refuses anything else

This is the most important thing to know before you integrate, and it is a limitation rather than a feature. The gateway bills video through a flat price per call that does not scale with any request parameter. There is no mechanism in it for charging a 10-second render more than a 1-second one.

That leaves two options and only two. Either every accepted request runs for exactly the duration the price was set for, and the number quoted is exact -- or a variable duration is accepted and a 1-second request is charged the same as a 10-second one, which is a confidently wrong number rather than an approximate one. We do not ship the second kind of number.

So the price on file is set for exactly five seconds, and the video endpoint validates duration before the request reaches the gateway. Five because every model in the catalogue supports at least that much, and because it is the default our own docs and examples already request. Any other value is refused with a 400 that names the constraint, rather than silently billed at the wrong rate.

curl https://router.xark.io/api/v1/video/generations \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{"model":"alibaba/wan-2.2-t2v-a14b","prompt":"a paper boat in the rain","duration":8}'

# {
#   "error": {
#     "message": "During this rollout phase, Wan 2.2 T2V A14B generations run at a
#                 fixed 5-second duration so the price you were quoted is exact.
#                 You requested 8s. Omit 'duration' or set it to 5 to proceed.",
#     "type": "invalid_request_error",
#     "param": "duration",
#     "code": "fixed_duration_required"
#   }
# }

What that limitation costs you

It is worth stating plainly which side of this trade you are on. A ten-second sequence is two calls and two clips you have to join. A three-second clip is billed as five. If your workload is mostly short clips, a provider with genuine per-second billing charges you less than we do for the same footage right now, and Novita's per-second video pricing is real and published.

Where the fixed duration is neutral or better is the case where you were going to generate five-second clips anyway -- social cutdowns, product B-roll, variant testing at volume -- and you want the cost of a batch to be a multiplication rather than an estimate. Ten thousand five-second Wan 2.2 clips is $1,450, exactly, and that number does not move because a cold start ran long.

Variable-length billing needs a per-parameter pricing mechanism the gateway does not currently have. It is a real gap, not a design principle, and the endpoint says so in the error rather than in a footnote.

The price is quoted before the GPU spins

Video generation is asynchronous: the endpoint returns 202 with a job id, and the estimated cost comes back on that first response, before any GPU time is spent. On a product whose argument is that video pricing is opaque everywhere else, telling somebody what a render costs only after billing them would undercut the whole position.

Status is derived from elapsed time, so a poll always reflects wall-clock progress rather than a cached state. It moves queued to processing to succeeded, and url stays null until succeeded rather than returning a placeholder a client could 404 on.

# Submit. 202, with the cost stated up front.
# {
#   "id": "vid-b0a0405d07d74acaba42",
#   "object": "video.generation",
#   "model": "alibaba/wan-2.2-t2v-a14b",
#   "status": "queued",
#   "duration_seconds": 5,
#   "estimated_cost_usd": 0.145,
#   "estimated_ready_in_seconds": 26,
#   "url": null
# }

curl https://router.xark.io/api/v1/video/generations/vid-b0a0405d07d74acaba42 \
  -H "Authorization: Bearer sk-..."

The video models we will not sell you

Sora, Veo, Runway and Kling are closed-weight. No licence exists that lets a third party resell access to them, so any gateway advertising them is either misrepresenting what it serves or serving it in breach of somebody's terms.

The entry worth reading twice is Wan. Wan 2.1 and Wan 2.2 are Apache 2.0, which is why we serve 2.2. Wan 2.5 and 2.6 are API-only products from the same publisher and the weights were never released -- so a developer who has been running Wan 2.2 locally and assumes the next version continues the arrangement is assuming wrong.

Availability, stated plainly

The catalogue above describes the lineup and its pricing. As of this writing the video models are not yet served by a configured upstream -- the rate card was set before capacity was in place, and the model pages and the models endpoint both mark which models are callable today rather than letting a copy-runnable snippet fail at the moment of use.

Check the models endpoint before you build against a specific model. It is unauthenticated and returns the current lineup, so it is the honest answer rather than a marketing page.

curl "https://router.xark.io/api/v1/models?type=video"

Rate limits and the shape of a batch job

Video generation is limited to 10 requests per minute per key, against 60 per minute for chat. That is a capacity constraint rather than an anti-abuse one, and it means a ten-thousand-clip batch is a scheduling problem: at the limit it takes about seventeen hours of wall clock, so the job needs to be a queue with retries rather than a loop.

The 429 rules are the same as everywhere else on this API. Read error.code before you back off -- rate_limit_exceeded means wait, insufficient_credits means top up, and retrying the second one forever is the failure this contract exists to prevent.