Why a Kling motion control job shows type avatar_image_to_video

A Kling motion control job on Sume has type: "avatar_image_to_video" and model: "kling/3.0/motion-control". That is on purpose: motion control shares the job type of the VEED Fabric still-plus-audio product, and the public model id is what separates the two. If you filter your job list by type alone, you will mix them.

What is stored

All four submit routes create the same kind of job: POST /v1/kling/3.0/motion-control, POST /v1/avatar-1.0/motion-control, and the two model-run twins under /v1/models/. The face-control alias and its model-run twin never store sume/avatar-1.0/motion-control. They store the Kling id as well, so a report of your jobs by model shows one name no matter which route you called.

The submit envelope returns job.id, status_url, result_url, job.model and usage.billable_amount_usd_micros, the same shape as every other Sume submit.

What it means for your code

Do three things in a pipeline that tracks cost or concurrency.

• Group by model, not by type. kling/3.0/motion-control is the key for a motion job; veed/fabric-1.0 is the key for a talking still.
• Do not expect a new job type. There is none for motion control, and Sume does not plan one in the doc that defines the surface.
• Use the job id as your join key. The lifecycle is the standard GET /v1/jobs/:id/status and GET /v1/jobs/:id/result for both.

Three jobs, one type

A reporting query

A spend report that wants motion control only should select rows where model = 'kling/3.0/motion-control'. A report that wants every image-to-avatar job can select the type. Pick the key that matches the question, and the numbers do not get mixed.

The same rule helps when you read the Sume docs. The page that defines motion control says it is not Video 1.0 kling-3 (text or frame to video) and not the Fabric product. Three look-alike surfaces, three different model ids.

A common mistake

The mistake to avoid is a dashboard that counts every avatar_image_to_video job as a talking head. A team that adds motion control to an existing Fabric pipeline will see the count go up, and the cost per job change too, because motion control bills per second of output while Fabric bills on its own card. The type is the same, the economics are not, so the model id is the safe column to group on.

Concurrency works on the same principle. Slots are held by job type, so a motion control job and a Fabric job compete for the same slot class. If you run both at volume, plan for the slots together, and read the page on job types and concurrency for the current numbers.