100 Kling motion-control clips: the budget, reserve and refund

One hundred 10-second Kling 3.0 motion-control clips on Sume reserve $157.50: the route bills ceil(duration_seconds) times $0.1575 a second, which is the $0.126 list rate in the docs multiplied by Sume's 1.25 margin. The reservation is taken when each job is admitted, captured when it completes, and refunded if it fails, so the final bill equals the clips that rendered.

The rate is the kling/3.0/motion-control price in the Sume catalog (GET /v1/catalog, see the Sume models docs), read 2026-10-06; the $0.126 list rate is the fal list price from 2026-08. Motion control takes a still (or ready avatar) and a motion video from you; the output length follows the motion video, and duration_seconds is the declared length used for admission pricing.

What does each length cost at 100 clips?

What happens at the edges?

Admission rejects a job when the balance cannot cover the reservation, returning 402 insufficient_credits before any provider work starts (Generation admission, read 2026-10-06). That is the failure to plan for in a 100-clip batch: a 30-second clip reserves $4.725, so a balance of $4.00 will refuse it, while a 5-second clip would pass. Top up for the reserve of the jobs you will have in flight, not only for what you expect to capture.

Concurrency is plan-based. The docs list processing limits of 1, 4, 8 and 20 for Free, Pro, Startup and Scale, with default queue capacity of 5, 20, 40 and 100, and accepted jobs beyond the processing limit wait as queued. The docs also give accepted job capacity as concurrency plus queue: 6 on Free, 24 on Pro, 48 on Startup and 120 on Scale. So 100 clips fit in one submit only on Scale. On Pro the 25th simultaneous submit is answered with 429 queue_full, so submit in waves and keep each job's Idempotency-Key stable across retries of the same request.

How do you keep the budget honest?

For a single clip at 12 seconds, the Kling comparison post prices motion control against the prompt-driven model, and the 402 post walks the 30-second reserve. A good habit is to size your balance at the largest wave you will have in flight and read the dashboard after each wave, so the reservation never surprises you.

• Declare the real motion-video length. An over-declared duration reserves more than you need, while the output follows the video.
• Test at 5 seconds first. Approve the look, then scale to the length you ship.
• Record usage.billable_amount_usd_micros from each submit response and compare it with your total before you start the next wave.
• Separate silent from sound. keep_original_sound defaults to true; set false only when you will add audio later.

How should you stage the run?

Do not launch 100 at once. On a Pro plan four jobs run concurrently with a queue of 20, so a flood beyond 24 accepted jobs returns 429 queue_full. Submit in waves sized to your plan, wait for completions through webhooks, and keep a ledger of keys and outcomes. A failed clip is refunded, so your running total should subtract it before you decide to resubmit.

Keep a floor on the balance. Each admitted job reserves its full amount up front, so a balance of $200 does not support 100 clips of 15 seconds at $2.3625 each when they are all in flight; the reserve is held until completion. If a request would exceed the balance you receive 402 insufficient_credits before any provider work begins, which is the cheapest failure available.