Providers

Kimodo on your own GPU, Uthana hosted — what each gives you, what it costs, and where it stops.

Two routes today. They differ in more than price: one is reproducible and one is not, and that difference decides what a Motion Definition even means.

	Kimodo	Uthana
Where it runs	Your machine, another machine on your network, or a GPU you rent	Uthana's service, on your own account
Cost	Free locally. Per hour on a rented GPU	Metered — per generated second, or per downloaded second on a subscription
Seed	Yes — a definition is a recipe	No
Native frame rate	30	60
Fingers	None. One fixed relaxed pose for the whole clip	Provided
Foot contacts	Baked from the model's own contact prediction	Not provided
Licence tier	Free, closed source	Open source

Kimodo — local and reproducible

Runs NVIDIA's Kimodo model in Docker on hardware you control. Free to run locally, honours a seed, and therefore turns a Motion Definition into something that can be regenerated identically — which is not true of Uthana.

What it costs to run

Cost follows where it runs:

This machine — free.
Another machine on your network — free.
A rented GPU — per hour at the price Runpod reported, billing while the pod is up whether or not anything is generating.

That last clause is the expensive one. A rented pod bills for existing, not for working. Stop it from the hub's Runners tab when you are done.

Generate starts a stopped runner

If the local runner is stopped, Generate starts it — Docker Desktop first if it is closed, then the container, then a wait for the text encoder — rather than refusing.

It never rents or starts anything that bills. Starting something free is a convenience; starting something metered would be a decision.

Speed depends on more than the GPU

Generation takes seconds to minutes depending on hardware. The honest version of that number: with the right precision setting it is around fourteen seconds; without it, five to seven minutes, because the prompt encoder is the slow part rather than the diffusion.

Both figures are true, and neither is true alone.

Settings, under Kimodo's own names

model (three checkpoints, chosen per request), seed (-1 picks a new one per take and records it), diffusion_steps (100; 10–500), postprocess, split_prompt_into_beats, and under Advanced cfg_type, cfg_text, cfg_constraint, where poses come from, and the timeline's pose type.

Limits

A beat is at most 10 seconds; a whole clip at most 60.
No finger animation at all — the model has no finger joints, and hands are filled from one fixed relaxed pose for the entire clip. This is the single most important limitation of the provider.
No prompt rewriter.
Verified against the Narrative mannequin family. Other target skeletons are configurable but unverified.

Setup

The Kimodo Runner panel — Tools ▸ Kimodo Runner, or Kimodo.Panel — has three targets: This machine, Another machine, and A rented GPU.

It manages the Docker lifecycle itself: install detection, starting Docker Desktop, compose up/start/stop/down, and image-signature drift detection that flags a rebuild as needed rather than leaving a mismatched runner silently wrong.

Setup steps are measured, not assumed: where it runs, Docker Desktop, the Hugging Face token, access to Llama 3, the runner image, the runner, and renting a GPU instead.

Both providers declare their setup the same way, so Get started can put them side by side and let you pick on evidence:

Step 1 of MotionForge's Get started, 'Where motion is made', with Uthana selected and marked Ready. Two cards sit side by side. The Kimodo (local) card is headed 'Starts when you generate', costs 'free, runs on this machine', and lists measured rows: where it runs, Docker Desktop running with its version, a Hugging Face token stored in the system credential vault, Access to Llama 3 'not checked yet — a token alone installs fine and fails later, so this is worth checking', the runner image, the runner not running with a Start runner button, and renting a GPU instead. The Uthana card costs 'pay as you go, $0.10 a generated second, Uthana's published price', and lists its API key, the plan, one uploaded character in this project, and a connection that is 'not tested yet — testing is free'. — Two providers, the same measured rows, one decision. Every amber row states what is unverified rather than assuming it is fine: Llama 3 access is 'not checked yet', the Uthana connection is 'not tested yet — testing is free'.

The cost line sits at the top of each card, before any of the setup. Kimodo reads "free, runs on this machine"; Uthana reads "pay as you go, $0.10 a generated second, Uthana's published price" — the published-price note appearing exactly where the choice between them is made.

Llama 3 access is measured too. Hugging Face is asked whether your stored token can actually read the gated Meta-Llama-3-8B-Instruct model, and the answer — granted, not granted, token refused, no token, unknown — is shown with the link to request access.

A key that exists is not a key that works. Gated models need access, not just a token, and discovering that at generation time wastes a run.

Kimodo Runner offers This machine, Another machine and Rented GPU, with This machine selected. It reports Not answering: Docker is running but the runner container is stopped. The image is up to date and a Hugging Face token is stored. Llama 3 access says not checked yet, with Model page and Check links. Start is available and Stop is disabled. — Docker running, a runner image and a stored token are separate facts. Here the container is stopped and Llama 3 access is 'not checked yet' — the panel does not present a stored token as proof of access.

Another machine — one GPU for the team

Point the project at a runner on somebody else's workstation. Nothing is installed or started on your machine, and your project pays for nothing.

The Kimodo Runner panel on its 'Another machine' target. It describes a runner on another computer — a workstation with a big NVIDIA GPU that the whole team generates against — noting nothing is installed or started here and this project pays for nothing. Fields for Address and a Runner token, which reads 'Stored. Type a new one and press Enter to replace it.' Instructions follow for the other machine: install Docker Desktop and a current NVIDIA driver, copy the plugin's Runner folder across, and start it from inside that folder; it needs its own Hugging Face token with Llama 3 access and port 8757 open. A copyable block shows the four environment variables and the docker compose command. Buttons: Generate on that machine, and Show the Runner folder. — The setup for the other machine is given as the commands to run there, not as prose to translate. Note the token field: it says a token is stored without showing it, and replacing it is a deliberate keypress.

The token for that runner lives in this computer's vault, not in the project — so pointing at a shared workstation does not put its credential into source control.

Renting a GPU

Provision, start, stop, check and terminate a pod from inside the editor. GPU selection is ranked by real per-datacenter stock and a price ceiling (default $1.50/hr, 24 GB VRAM minimum).

Weights persist on a network volume, so a stopped pod restarts in roughly 76 seconds instead of a 15-minute rebuild.

The Kimodo Runner panel on its Rented GPU target. Three rows report readiness: Runpod 'API key set', Hugging Face token 'stored, and passed to the pod', and in amber Llama 3 access 'not checked yet — a token alone installs fine and fails later', with Model page and Check links. Below: 'Nothing rented. Renting creates storage for the weights and a GPU to run them on, and points this project at the pod — which is what makes Kimodo say it is billed rather than free.' Four buttons follow: Rent storage and a GPU, highlighted, with Release the GPU, Refresh and Delete everything all greyed out. — The sentence under the rows is the billing mechanism stated plainly: renting points this project at the pod, and that is what makes Kimodo report itself as billed rather than free. The cost line elsewhere in MotionForge changes because of this switch, not because of a setting you type.

Storage and the GPU are two things, and only one of them stops. Release the GPU ends the hourly charge; the network volume holding the weights stays, which is what makes the next start take about 76 seconds instead of fifteen minutes. Delete everything is the one that removes the storage too.

Both are greyed out above because nothing is rented yet — the panel will not offer you a release for something that does not exist.

Note the middle row: the Hugging Face token is "stored, and passed to the pod". Your token travels to the rented machine, because the pod downloads the gated weights itself. That is also why Llama 3 access is checked here and not only on this machine.

Constraints — pinning a pose

Kimodo takes poses as generation constraints. You can:

Capture a pose from the selected, posed actor (Kimodo.CapturePose).
Author from an existing animation's frames (Kimodo.AuthorPose).
Harvest from a Level Sequence's keyed rig — a transient, never-saved bake sampled only at keyed times.
Drive a key from a reusable pose asset.

Plus list, clear, preview, measure and verify tools, so you can check what was authored before spending a generation.

23 console commands, all prefixed Kimodo..

Uthana — hosted

Hosted generation on your own Uthana account, with async jobs and per-character retargeting on the service side.

Only the asynchronous text-to-motion-3.0 model is implemented — declared as 4–10 seconds. The synchronous text-to-motion-2.0, which exposes seed, cfg_scale and steps, is not.

A Motion Definition using Uthana. The Prompt section is headed '5 s, 1 beat' and the length field notes 'Uthana makes 4 s to 10 s.' The Character section warns that Narrative Biped has a provider rig but no Retargeter, so a clip could not be moved onto the game's skeleton, offering Import directly, Upload again and Import Uthana's rig. The Generate section's provider dropdown reads 'Uthana — pay as you go, $0.10 a generated second', described as hosted, generating on your own uploaded character, with good hands, 4 to 10 seconds a take. The takes table lists Take 2 as ready and Take 1 as in the game, with the Seed, Length and Cost columns empty. — Three Uthana facts the prose can only assert: its own length range on the field that sets it, the published price named in the dropdown that selects it, and an empty Seed column — because this model has no seed, so these takes can never be regenerated.

The amber block in that capture is the failure retargeting is about: "has a provider rig but no Retargeter, so a clip could not be moved onto the game's skeleton." It is raised on the definition, before a generation is paid for — not after one arrives on the wrong rig.

No seed, and what follows from it

Uthana's implemented model has no seed. Two consequences, both deliberate:

MotionForge never prunes candidates for Uthana. A discarded take can never be regenerated, so its bytes are the only copy that will ever exist.
A Uthana definition is a request, not a recipe. Re-running it gives you something new.

Billing, declared by the provider

Pay as you go — bills per generated second, and fetching is free, so takes play in the editor before you choose.
Subscription — bills per downloaded second, so the provider's viewer link is the free way to look, and an import says what quota it will use and asks first.

The rate starts at Uthana's published price ($0.10/s). While it is still that price, every cost line says so — "Uthana's published price; set your own on the MotionForge Uthana settings page."

That page is where you make the figures match your actual account:

Project Settings showing 'Automation Forge — MotionForge Uthana'. Its description reads: how your Uthana account is billed, so every cost line and confirmation in MotionForge states the right price before you spend. Set the plan to match your account; the two plans reverse the right way to work. A note says these settings are saved in DefaultEditor.ini, which is currently writable. Under Billing: plan is 'pay as you go', Rate Per Generated Second is 0.1, Rate Per Downloaded Second is greyed out at 0.0, and Currency is USD. — Rate Per Downloaded Second is greyed out because the plan is pay as you go — on that plan fetching is free, so the field cannot apply. Switch the plan and the two swap over, which is what 'the two plans reverse the right way to work' means in practice.

This is a project setting, not a per-person one: what your team is billed is a fact about the project, so it belongs in a committed file. Contrast the key itself, which is per person and never in an .ini — see the three tiers.

Neither choice is permanent. The definition survives the switch, and it keeps each provider's settings separately.