Skip to main content
A training run fine-tunes one policy on one GPU from a LeRobot dataset. You choose the dataset, the policy types, and the GPU tier; Kite provisions the hardware, runs the training, streams you progress, and saves checkpoints. One run trains one policy. A single request can start several — pass more than one entry in policies and you get one run back per policy, all training in parallel on their own GPUs so you can compare them.

​
Create a run

​
Request body

​
string
required
The dataset to train on: a Hugging Face LeRobot repo id such as lerobot/pusht, or a gs:// path to a LeRobot dataset.
​
string[]
required
Policy types to train, one run each. Between 1 and 8 entries. Fetch the list from GET /v1/training_policies.
​
string
The GPU to train on. Defaults to gcp_gpu_t4. Each policy declares a minimum tier — see GET /v1/hardware_tiers.
​
integer
Training steps. Defaults to the policy’s own recommended value.
​
integer
Batch size. Defaults to the policy’s own recommended value.
​
integer
Save a checkpoint every N steps.
​
object
Maps your dataset’s camera keys to the policy’s image slots: each key is a camera key from your dataset, each value the slot to feed it into. Omit it and Kite maps them for you. See Inspect a dataset for your dataset’s camera keys and a worked example.
​
boolean
Push the trained policy to your connected Hugging Face account when the run finishes. Defaults to false.
​
string
The policy name to push under. The namespace is always your connected account.
​
object
Opaque data echoed back on the run and on its webhook events. Use it to tie a run to your own job id.
The call returns one resource per policy, immediately:
Response — 202 Accepted
Runs started in the same request share a group_id, so you can tell which ones were launched together even if their webhooks arrive out of order. Common failures at create time:
  • 400 policy_not_available — an unknown policy, or one that can’t currently be trained
  • 400 hardware_tier_too_small — the tier is below the policy’s minimum; details.min_hardware_tier tells you what it needs
  • 400 hardware_tier_not_available — an unknown or currently disabled tier; details.available_tiers lists the usable ones
  • 402 insufficient_tokens — not enough credits for the whole request
  • 429 concurrency_limit_exceeded — you already have the maximum number of runs in flight
  • 429 capacity_exceeded — Kite is at GPU capacity; retry shortly
  • 503 service_unavailable — cloud GPU training is temporarily down
Validation covers the whole request before anything launches, so a request either starts all of its runs or none of them. See Authentication → Errors for the envelope.

​
Idempotency

Pass a unique Idempotency-Key header to make retries safe. A repeated request with the same key returns the original runs instead of starting duplicates — so a dropped connection or a CI retry never double-charges you.
Reusing a key with a different payload returns 409 Conflict — the key is bound to the first request body it saw.

​
Track progress

Poll the run to watch it move through its lifecycle. progress and metrics come straight from the running trainer.
The status field moves through: phase tells you what a processing run is doing right now — useful, because provisioning a GPU and training on it both look the same from status alone:
Poll every few seconds while a run is active, or register a webhook and skip polling. Kite emits training_run.completed, training_run.failed, and training_run.canceled.
You can also poll any run through the uniform operations view, which works the same for every Kite resource:

​
Read the logs

Returns the last tail lines of the trainer’s output, capped at 1000. Logs stay readable after the run finishes, so this is where you look when a run fails.

​
Get your policy

When status is succeeded, output describes what the run produced.
Response — output
Only the latest checkpoint is summarised inline — list them all at /checkpoints. artifact_uri is the raw storage path, useful if you have your own access to the bucket; otherwise use download_url.

​
Download a checkpoint

List every checkpoint a run saved, oldest first:
Then fetch one as a ZIP of its pretrained_model/ directory:
It unzips to a standard LeRobot checkpoint — the same files the dashboard gives you, and the same ones push_to_hub uploads. Kite streams the archive rather than building it up front, so a multi-GB policy downloads like any other file. Checkpoints are paginated on step: pass the response’s next_cursor back as after, and stop when has_more is false. A run with a small save_freq can have thousands of them.
output.push_to_hub is the other route: set it at create time and the finished policy lands in your Hugging Face account automatically, no download step.
The result is a standard LeRobot policy checkpoint. It’s the same artifact the dashboard produces, so it loads anywhere LeRobot policies load. No proprietary output format, no lock-in.

​
Cancel a run

Stop a run at any time. Cancelling releases the GPU immediately.
Cancelling a run that has already finished returns 409 not_cancelable.

​
Discover policies and GPUs

Rather than hard-coding names, fetch what’s currently trainable. Both lists are small and never paginate.
Each policy reports its min_hardware_tier, min_vram_gb, and recommended default_steps and default_batch_size. A policy with "available": false can’t be trained right now.
Each tier reports its GPU and its tokens_per_hour rate. A tier with "available": false exists but is switched off.

​
Inspect a dataset

Check a dataset is trainable — and get its camera keys — before spending any credits.
camera_keys is what cameras.rename maps from. To feed those two cameras into a policy’s top and wrist slots:
An unreadable dataset returns 400 dataset_not_readable.

​
What a run costs

Every run reserves one GPU-hour of credits up front, at its tier’s rate. A run that trains for longer than an hour is not charged extra. A request that starts several runs reserves for each of them, so training three policies on a T4 costs 1,500 tokens. A run whose GPU never starts — a submission failure — is not charged at all. Preview the cost before committing:
Runs started through the API bill from the same credit balance as the dashboard, and appear in GET /v1/usage under training.

​
List your runs

Returns your API-created runs, newest first. Pass the response’s next_cursor as after to fetch the next page.
Runs you start through the API also appear in the Training section of the dashboard, alongside the ones you start there. It’s one set of runs on one set of GPUs, whichever way you launch them.