Does a bigger Sume plan make each video cheaper? Rates vs concurrency

The per-model rate does not change with the plan: Sume bills usage at each model's published rate, so a clip uses the same amount of credit on Pro as on Scale. What a bigger plan changes is capacity and how much usage the monthly fee includes. On capacity: Pro allows 4 concurrent jobs, Startup 8 and Scale 20, against 1 on the Free plan.

That distinction matters when you budget. A plan is a decision about how fast you can run, not about the unit price of a render. This post lays out the plan numbers from Sume's plan catalog, explains what a top-up does and does not change, and gives a way to pick a plan from your batch size.

Prices and limits in the table are the plan catalog values read on 2026-10-02. Confirm them on the pricing page before you buy.

What do the plans actually differ in?

The public plan grid describes product access and concurrency. Sume's own comment in the pricing code says usage is billed at each model's published rate, so the public plan grid does not list credit allotments. The plan catalog in the repo does give each paid plan an included monthly usage amount: $40 on Pro, $140 on Startup and $800 on Scale. That is a different thing from a lower unit rate, and it can change what each clip costs you in cash, so confirm the current figures on the pricing page before you rely on them.

Yearly billing exists as well, but this post sticks to the monthly figures so the comparison is like for like.

Does a top-up raise my concurrency?

No. A top-up adds dollars to the wallet, and the wallet pays for work. The number of jobs that can run at once is a property of the plan. If you buy more credit on a small plan, the extra jobs queue behind the plan limit instead of running in parallel.

When the queue is full the API answers 429 queue_full, and Sume releases the hold for that request. The fix is to retry with the same idempotency key after capacity frees up, or to move to a plan with a higher limit.

It is worth designing the client for this from the start. Submit with an idempotency key, honor any retry hint in the response and pace your submits instead of firing the whole batch at once.

How do I pick a plan for a batch?

Estimate the wall-clock time. If each job takes about 2 minutes and you have 200 to run, a plan with 4 concurrent slots needs roughly 100 minutes and one with 20 slots needs about 20. These are your own numbers, not Sume benchmarks, so use your measured job time.

The usage for the batch is the same on both: 200 jobs times the unit price. The plan changes how long you wait, the monthly fee and how much usage that fee includes.

Remember that concurrency counts running jobs, not your account's total volume. A plan with 4 slots can still complete thousands of jobs a month if you can wait for them.

jobs, minutes_each = 200, 2
for plan, slots in [("Pro", 4), ("Startup", 8), ("Scale", 20)]:
    wall = jobs * minutes_each / slots
    print(f"{plan}: about {wall:.0f} minutes of wall clock")

Should I upgrade to save money?

Upgrade to save time, or to unlock capacity you need for a launch. Do not expect a lower per-second rate, because the catalog has one rate per SKU; any saving would come from the usage included in the plan fee, which you should compare against your own monthly volume. If your only goal is to cut cost, look at the tier you render on, the length of your clips and your retake rate instead.

If you are on the Free plan, note that it is described as being for trying image generation, with limited Sume Agent access. Check the plan page for what a paid plan adds before you plan a video workload.

What should I check before I commit?

• The plan page on the day you buy, because plan prices and limits can change.
• Your own job duration, measured on a real run rather than guessed.
• The retry behaviour of your client, so that a 429 queue_full does not turn into a retry storm.