Skeleton-driven motion, measured

October 2026, on a v3 character (64×64, pixen_v3), each billed exactly 3 generations and finished in about two minutes:

• POST /animate-with-skeleton-v3 (pixelkiln's animate-skeleton): 8 hand-edited poses on a 64×64 sprite returned 8 frames at 64×64, matching PixelLab's anchor (8 frames = 3). description and action are both required. Sent with neither, the endpoint answers 422 with a field error for each, and a failed request bills nothing. The completed job's last_response carries images (base64, width, height), flow_kind, and billing_usage beside the top-level usage.
• POST /characters/animations, mode: "skeleton-v3" with no template_animation_id (PixelLab's new custom motion): a one-sentence action_description and frame_count 8 returned 8 frames at 96×96 (the character's own canvas grows from 64) in one job for south, saved onto the character as an animation (animation_id, animation_group_id), and billed 3. The submit answers { background_job_ids, directions, animation_group_id, status, enhanced_prompt, enhance_usage }. The finished job's last_response has images, storage_urls.frames, generation_model: "skeleton-v3_custom", animation_description, and billing_usage: {usd: 0, type: "generations", generations: 3}, the same nested field as the other character jobs, which is where poll looks when the top-level amount is a dollar zero. PixelLab says the action is written into one 3D motion that every direction is drawn from, so later directions added with animation_group_id move the same way (humanoids). pixelkiln sends this mode for a character loop with mode: "skeleton-v3", a prompt, and no template (docs/CHARACTERS.md, "Loops from a sentence"), one request per direction asset. The first direction of a directions loop is sent without animation_group_id; each later one is sent after it with the leader's recorded animation_group_id and the group's own animation_name (not inherited, so omitting it would rename the group). That append was verified live once (October 2026): adding west to a generated south loop sent the leader's animation_group_id and animation_name, the submit and the finished job both answered with that same group, the job billed 3, and GET /characters/{id} then listed the group under the leader's name with directions south and west (each animation there is { display_name, animation_group_id, directions: { <direction>: ... } }), with the character's other animations untouched. Deleting one direction of a shared group has not been run live. Verified live twice with one south direction on a v3 character, once by a direct call and once through pixelkiln gen (a manifest loop on an adopted character, 8 frames at 96×96, billed 3, then pick and fetch); a standard-engine character is refused (has no stored 3D skeleton).