Character still first, then Kling 3.0 motion control

Make the character still first, check it, and only then send it to Kling 3.0 motion control. The route needs two inputs: a public HTTPS still (or a ready avatar) that supplies who the character is, and a motion reference video that drives all of the output motion. Because the still sets the identity, a weak still wastes the full price of the motion job, while a rejected still costs you the price of an image.

Sume's route is POST /v1/kling/3.0/motion-control. It is not the Video Router kling-3 text and frame model. This page is about the order of work that keeps the expensive step as the last step.

Why the order matters

A motion-control job is billed per second of the motion video, so the clip you pay for scales with the length of the reference, up to 30 seconds. Every seconds of that clip carries whatever your still looks like. The three things worth fixing before you submit are the face and body in frame, the clothing and props, and the framing, because the motion reference drives the movement but cannot change who is in the picture.

A short checklist before you approve a still helps. Zoom to full size and look at the hands, the edges of the clothing and the face, since these are the places where a generated image is most likely to carry an error that a moving clip will then repeat on every frame. Compare the still with the first frame of the motion video: if the reference starts with arms raised and your still has them down, the opening frames will have to bridge the gap, and that is where odd transitions come from. Pick a still that starts in a pose close to the reference.

• Pose and framing: a still that shows the body parts the motion needs, such as full body for a dance.
• Clothing and props: the output keeps what the still shows.
• Background: it comes from the still, so make or choose the scene first.
• Resolution of the still: use a clean source, not a crop of a crop.

The two-step workflow

Step one is the image. Generate it with the image API (POST /v1/images) or use a photo you own, look at it at full size, and fix problems with an image edit instead of a video re-roll. Step two is the motion job. The request below uses the still as image_url, the driving clip as motion_video_url, and the length of that clip as duration_seconds.

curl -X POST "https://api.sume.com/v1/kling/3.0/motion-control" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Idempotency-Key: mascot-wave-v1" \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://example.com/mascot-approved.png",
    "motion_video_url": "https://example.com/wave.mp4",
    "duration_seconds": 5,
    "keep_original_sound": true,
    "character_orientation": "video",
    "mode": "async"
  }'

Fields to settle before submit

Three fields in this body have a decision behind them, and the docs fix their values.

Price of a motion job

The price is ceil(duration_seconds) times $0.126 per second times the 1.25 house margin, which is $0.1575 per second. Sume reserves the amount at admission, captures it when the job completes and refunds it on failure. A 5 second reference is $0.7875, a 10 second reference is $1.575 and a full 30 second one is $4.725. The reserve is why it pays to check the still first: the money for the job is held before the first frame is made.

Test the pairing cheaply when you can. Cut the first two or three seconds of the reference into its own file and submit that with the still. The reserve is for the declared length, so a 3 second test holds $0.4725 instead of the full amount, and the result shows whether the still and the motion belong together before you commit to the long version.

The prompt is for appearance only. Motion comes from the reference video, which is covered in what the motion control prompt does and ignores, and the Python version of the call is in the motion control API in Python.