Kling motion control not working: causes and fixes

When Kling motion control gives a clip that is shorter than your upload, stops at a cut, or animates the wrong person, the guide ties each of these to the motion reference video. Kling's guide says cuts and camera moves can truncate the result, and that fast or complex action can shorten it.

Causes below come from Kling's own Motion Control User Guide, read 2026-09-29. Errors from Sume's endpoint come from the Sume API reference and the API reference docs.

Why is my Kling motion control video shorter than the upload?

Kling says that if the action is highly complex or very fast, the result can be shorter than the original upload, because the model extracts only the valid, continuous action segments. A result can be generated as long as at least 3 seconds of usable continuous motion is found. The fix Kling gives is to adjust the action's difficulty and speed.

Why does the clip stop at a cut or camera move?

The guide asks for a single continuous shot with the character visible throughout, and warns that with cuts, shot changes or camera movements the video may be truncated. Re-record or trim the reference so that one unbroken take carries the motion.

If the wrong person moves, check how many people are in the frame: with two or more, Kling uses the character with the largest portion of the frame.

Do I lose credits when the result is shorter?

Kling states that in the shortened-result case the consumed credits are non-refundable. That is Kling's own app and credit system.

On Sume, the core workflow docs say provider-backed generation can refund on failure or cancellation before capture, and that /v1/balance and /v1/usage show the balance and ledger. Sume's docs do not say how a shortened Kling result is billed, so read the ledger entry for the job.

What errors can Sume's motion control endpoint return?

If the request itself is refused, the status code says why.

How do I check whether the job itself failed?

Poll the job's status until it is terminal, then read the result. The jobs docs list five statuses: queued, processing, completed, failed and canceled, and tell you to stop polling on the last three and not to resubmit the paid request just because a local process timed out.

A failed job reached a terminal failure with a public error. The same page lists /v1/jobs/{id}/events for a timeline of the job when you need to debug it.