AI video generator API pricing: where to read what a Sume clip costs

The price of a Sume video clip shows up in three places, and they answer three different questions: what will it cost, what is held right now, and what was I charged. Mixing them up is how people get a bill that looks different from their estimate.

1. Before you submit: the catalog

GET /v1/videos/models returns pricing_skus for each model, and GET /v1/video-router/models returns a pricing object with the list rate and the billable margin. Sume bills list times 1.25 on every video model. For per-second models, multiply the rate by the seconds and round up to the cent. The API pricing page says video rates are pass-through: provider list rates times the Sume margin, with per-model rates in the catalog.

2. At submit: the reservation

When Sume accepts the job it reserves the estimated amount from the balance. The usage ledger shows this as a reserved row. A reservation is not spend: the summary.held_usd_micros field is explicitly "not spend yet", and a refunded hold "is not spend" either.

3. After: what was charged

The poll response includes usage.cost, the Sume billable amount. For the whole picture of one job, call GET /v1/usage?job_id=.... The response adds a summary, and the docs tell you to quote debited_usd:

A habit that avoids surprises

Estimate from the catalog, submit with an idempotency key, then reconcile usage.cost against your estimate once per batch. The usage docs say never to sum the rows yourself, because a refunded row keeps its hold amount in the billable field. Use the summary.

A worked example of the three numbers

Take a 5-second Wan 3.0 clip at 720p. The catalog lists $0.10 a second, so list for five seconds is $0.50. Sume's billable amount is list times 1.25, which is $0.625, and the catalog formula rounds it up to $0.63. At submit, the ledger shows a reserved row for that estimate. When the job completes, the poll response shows usage.cost and the ledger row is captured. If the job had failed, the hold would be refunded and debited_usd would be zero.

Those are the same number at three moments. If they differ, something changed between the estimate and the request, usually the resolution or the duration.

The API pricing page is generated from the same pricing constants that the API uses for bills, according to the usage docs. For video, it shows Video Router as pass-through with per-model rates in the catalog. So the pricing page is where you learn the rule, and the catalog is where you read the model's rate. Do not copy a rate from a blog post, including this one, into production code without reading the live catalog first.

Before you ship anything, read the live pages again: the catalog is public, the pricing page is public, and the docs describe the request fields. A blog post is a snapshot. The catalog, the plan grid and the error table are the things that change, so write your code to read them instead of copying numbers from a page, and re-check when a new model is added.

A good habit is a small log line per submit with the model, resolution, duration, estimated cost, job id and the Idempotency-Key you used. When a job misbehaves, those six fields answer most of the questions support will ask, and they let you compare your estimate with usage.cost and the usage ledger without re-running anything.