Six AI video test clips under $3 across four Sume models

The cheapest way to learn which Sume video model fits your work is to send the same prompt to four models in six short clips. On catalog rates, the grid below costs $2.58 in total. That is one top-up's worth of testing, and it leaves you with real clips to compare instead of a price table.

The grid

Use one prompt and one aspect ratio, so the model is the only variable. Every request is POST /v1/video-router/generate with a catalog model id, or POST /v1/videos with the same ids.

What to compare

• Omni 360p against Omni 720p: is the cheap tier good enough for drafts?
• Wan 480p against Wan 720p: does the price doubling show on screen?
• MiniMax H3 against H3 Max at 768p: Max lists $0.100 a second against $0.075 for H3.
• Audio: per the docs, Omni and the MiniMax H3 models render native audio. Check generate_audio in each model's catalog row for the rest.

Keep the receipts

After each job, call GET /v1/usage?job_id=.... The summary's debited_usd is the amount to quote, and held_usd_micros is only a hold. The docs warn against summing rows yourself.

When the grid is done, put your pick into a script like the estimator, and size your first real top-up from clips per dollar. Prices come from provider list rates and the docs mark them as changeable, so re-read the catalog before you budget a large run.

Reading the results

Put the six clips side by side and score each one on the thing you care about: motion, text, faces, hands, product shape. Note that a single prompt is a weak test. Run the grid twice if the choice is going to drive a larger spend, with a different prompt the second time. At $2.58 a run, a second pass costs about the same as one longer clip on a high-resolution tier.

Then decide by price per keeper, not price per clip. If a $0.32 model gives you one good clip in three and a $0.63 model gives you one in one, the second is cheaper per keeper.

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.

If you are new to the API, start with one clip, one model and the lowest resolution, read the full response once, and only then build a loop around it. Most surprises with video jobs come from fields that were defaulted, not from fields that were set.