PAID, and the cost MULTIPLIES BY THE NUMBER OF ANIMATIONS (each is its own image-to-video call, ~400 credits at defaults). This is real motion — a walk cycle, an attack, an idle bob — not the 1-frame still that create_animation_from_pose produces. Read the character's gameType and use the standard animation names for it (get_character shows what already exists); the project gameType is irrelevant after character creation. A topdown character inside a platformer project still uses top-down prompts and directional behavior. A name that already exists is NEVER replaced: the server allocates the next numeric slug (walk → walk_2 → walk_3), and the returned animations list contains the resolved names. Ask the user which animations they want before spending: 4 animations cost 4x. Every animation defaults to 2 seconds, including walks, runs, attacks, and loops. Omit animDurations and customAnims[].duration unless the user explicitly asks for a different clip length; never infer a longer duration from the motion or from the fact that it loops. If the character came from a 2x2 create, there are at least four siblings and animating is per-character: show the user the characterPreviews from get_job and have them pick one before you spend. For multi-direction sets, mirrorAnims gives you FREE flipped copies of a direction generated in the same call (walk_left from walk_right) — prefer a real generation when the character is asymmetric, because a held item switches sides under a mirror. The server chooses the release-new-animation-pipeline rollout for this API-key owner; there is no flag argument to set. When the user wants stored poses as the actual video endpoints, call list_character_poses and pass their ids through poseFirstFrameIds / poseLastFrameIds. Omit those maps to let the server plan anchors automatically; never pass a pose URL. Before each new clip the server classifies the effective anchor as empty-handed, held, or unclear and adds the matching inventory-preservation lock automatically; there is no inventory argument to send. For topdown/isometric clips with targetFacings, automatic planning uses one cached standing internal 360 rotation for every action, including custom actions; its one-time surcharge is included in the dry-run quote. Do NOT call generate_character_turn merely to prepare an animation — that explicit visible turn is a separate action. When that internal 360 is needed, the job pauses at waiting_approval before any animation video starts. Present directionalPoseReview from get_job and call approve_directional_poses only after the user accepts all eight candidates. The dry-run response includes animationPipelineAssignmentToken; copy it verbatim into the confirmed call so the quoted rollout decision cannot change while the user is deciding. If it expires, run the same dry-run again. The same response includes preflight with per-animation resolved names, durations and credits; setup and total credits; model resolution; runtime frame size; and explicit unknown-until-generated frame count/FPS/ETA. Show that structured preview instead of inventing precision. For free treatment accounts only, the server may allow ONE activation request beyond the 600-credit rolling limit when this call requests exactly one fresh playable animation (no reuse, edit, or mirror), the full preflight total is at most 1000 credits, fewer than two distinct net-paid generation jobs occurred in the rolling window, and no playable animation has succeeded before. Required internal pose/360 setup is included in that same claimed job and remains authorized across its approval pause. This is server-decided and shown in dryRun.freeCreditLimit.firstAnimationAllowance. Explicit turn/turn_ rotations, reuse, edit, mirror, and multi-animation requests do not qualify; a failed fully-refunded claim is reusable only if it produced no playable animation. Never split calls, omit requested work, or retry to game it. Returns { jobId, animations } — poll get_job. When the job reaches done, it returns an animationQualityGate requiring get_character; finish that review/repair loop before exporting or saying the animation is ready. A prompt that composes too long for the model is rejected with PROMPT_TOO_LONG before anything is charged, and the response names the animation. Check isTemplate on that entry: false means YOUR text is what is long, so shorten it; true means the shipped template is over the ceiling and no prompt you send can fix it — report it rather than retrying. DEFAULTS TO A COST PREVIEW — see the dryRun argument.