LeRobot v0.6 vs v0.5: What Changed and How to Migrate

Last Updated: September 23, 2026

If you upgrade a working LeRobot 0.5.1 project with a bare pip install -U lerobot, it will most likely fail before it trains a single step. Your dataset loader imports something the lean base install no longer pulls in. Your eval_freq key is silently wrong. Your SAC config names a policy type that no longer exists. That is the practical story of lerobot v0.6 vs v0.5: the headline features are exciting (world-model policies, GR00T N1.7, a DAgger-capable deployment CLI, a reward-model API, six new benchmarks), but the release also rewires packaging, config keys and module names underneath you. Then v0.6.1, tagged on 2026-08-03, added one more rename.

This guide keeps the two stories together. It explains what changed and why it matters for a real robot-learning loop. Then it gives you the exact old-to-new mapping and a migration order that avoids the common traps.

What this covers: the v0.5 baseline, the v0.6 “closed loop” architecture, every breaking change from 0.5.1 to 0.6.1 with before/after, a step-by-step migration, the new DAgger rollout and reward-model workflows, and the failure modes we expect teams to hit.

Context and Background

LeRobot is Hugging Face’s open-source PyTorch library for real-world robot learning. It covers hardware drivers, the LeRobotDataset format on the Hub, policy implementations, training and evaluation. It is now also backed by an ICLR 2026 paper. Its value has always been the full loop: record teleoperated demonstrations on a cheap arm like the SO-101, train a policy such as ACT or Diffusion Policy for robot manipulation, and deploy it back onto the same hardware.

The release cadence has been fast. According to the PyPI release history, v0.5.0 shipped on 2026-03-09 and v0.5.1 on 2026-04-07. v0.6.0 followed on 2026-07-06, with the Hugging Face release blog “Imagine, Evaluate, Improve” going up a day later on 2026-07-07. v0.6.1 shipped on 2026-08-03 and is the current “Latest” release.

v0.5.0 was already a big step. Hugging Face reported over 200 merged PRs and more than 50 new contributors since v0.4.0. It added the first humanoid (full Unitree G1 support), OpenArm and OpenArm Mini, the Earth Rover as the first mobile robot, and the OMX arm, and it unified SO-100 and SO-101 into one codebase. On the policy side it brought Pi0-FAST, Real-Time Chunking (RTC) for the Pi0 family, SmolVLA and Diffusion, Wall-X, X-VLA, the SARM stage-aware reward model and PEFT/LoRA fine-tuning. It also introduced EnvHub, raised the minimum to Python 3.12 and moved to Transformers v5.

v0.5 was a breadth release: more robots and more policies. v0.6 is a loop-closing release. Its thesis, in Hugging Face’s own framing, is policies that imagine, reward models that tell you whether the robot succeeded, and a deployment CLI that turns failures into training data. That thesis explains most of the breaking changes. You cannot bolt a reward-model API, a rollout CLI and language annotations onto a monolithic install without restructuring packaging and schema. If you work with the storage layer, our deep dive on LeRobotDataset v3 chunked Parquet and streaming explains the format that v0.6’s new columns and codecs sit on.

LeRobot v0.6 vs v0.5: The Closed-Loop Architecture

The core difference in LeRobot v0.6 vs v0.5 is that v0.6 turns the library into a closed robot-learning loop. You record with depth and configurable codecs, auto-annotate with a VLM, score episodes with a reward model, and train with FSDP or on HF Jobs. You then evaluate on nine benchmark families and deploy with lerobot-rollout, whose DAgger strategy feeds corrections back into training.

Figure 1: The v0.6 robot-learning loop. In v0.5 the chain stopped at deployment; in v0.6 DAgger corrections flow back into the dataset and the next fine-tune.

Read the figure top to bottom. Recording now captures depth alongside RGB, with codec settings under rgb_encoder. lerobot-annotate adds language structure, and lerobot.rewards writes per-frame progress. Training and evaluation are both faster and more scalable. The new part is the return edge: rollout with a human in the loop produces intervention-tagged frames that go straight back to the Hub and into the next training run.

Deployment is now a first-class workflow, not a recording hack

In v0.5, running a trained policy on hardware was done through the recording tooling. The v0.6 blog describes deployment as having been “a hack on top of lerobot-record.” That coupling mattered. Recording assumes a human drives the robot. Deployment assumes the policy drives, and you only want data when something interesting happens.

lerobot-rollout separates the two concerns. It ships five strategies. base just runs the policy. sentry records continuously, rotating episodes and uploading to the Hub as it goes. highlight keeps a ring buffer and saves the last N seconds when you press a key. episodic mirrors the classic episode-and-reset recording flow. dagger turns deployment into data collection. The CLI also supports pluggable inference backends, including Real-Time Chunking (--inference.type=rtc) for large, slow VLAs whose inference latency would otherwise make motion stutter between action chunks.

The design choice worth noticing is that the data capture policy is now a strategy parameter, not a separate program. A fleet of arms can run sentry for passive logging during a pilot, then switch to dagger for a correction campaign without changing the rest of the stack.

Reward models give the loop a success signal

Imitation learning has a quiet weakness: it has no idea whether a demonstration was good. v0.6 adds lerobot.rewards, a unified API that mirrors the policies API. It puts four reward models behind one interface: the HIL-SERL reward classifier, SARM (added in v0.5), and two new ones, Robometer and TOPReward.

Robometer (lerobot/Robometer-4B) is a pretrained, general-purpose reward model built on Qwen3-VL-4B. It was trained via trajectory comparisons over a dataset of more than one million robot trajectories and is described in an RSS 2026 paper. TOPReward needs no reward weights at all. It wraps an off-the-shelf Qwen3-VL model and reads the log-probability of the token “True” given the trajectory video and the task instruction. We return to how these plug into training later in this guide.

World-model policies arrive, but you mostly consume them as checkpoints

v0.6 adds three world-model policies: VLA-JEPA, LingBot-VA and FastWAM. Each learns to predict the future during training and takes a different path to keep inference affordable. We covered the modelling ideas separately in world action models vs VLA: Cosmos 3, VLA-JEPA and FastWAM, so here we only note what matters for the upgrade.

VLA-JEPA is built on Qwen3-VL-2B and drops its JEPA world model at inference. You pay for world-model supervision in training, not at run time. A DROID-pretrained base, lerobot/VLA-JEPA-Pretrain, is on the Hub for fine-tuning. LingBot-VA is an autoregressive video-action model that predicts video and actions chunk by chunk. Inference runs on a single 24–32 GB GPU, and --policy.save_predicted_video=true saves what the robot imagined so you can compare it with reality. FastWAM pairs a roughly 5B-parameter video expert with a compact action expert, skips imagination at inference, and fine-tunes from lerobot/fastwam_base.

The practical consequence: each of these has its own install extra (vla-jepa, lingbot-va, fastwam on PyPI). None of them come with the base install.

What Else Is New in v0.6: VLAs, Data, Benchmarks and Training

Beyond the loop, v0.6 changes the model zoo, the data path, evaluation and training scale. These are the areas where your existing configs will interact with new defaults.

The VLA zoo: GR00T N1.7 replaces N1.5

The most consequential model change is NVIDIA GR00T. v0.6 upgrades the integration to GR00T N1.7. N1.7 swaps the previous VLM for Cosmos-Reason2-2B, which is built on Qwen3-VL, and feeds a flow-matching action head. Hugging Face says the integration is parity-tested against NVIDIA’s original Isaac-GR00T implementation: same inputs, same outputs. Flash-attention is now optional, so pip install 'lerobot[groot]' works without a custom build. You can load NVIDIA’s published nvidia/GR00T-N1.7-3B checkpoint directly.

The catch is that N1.7 replaces N1.5. There is no side-by-side. If you have a fine-tuned N1.5 checkpoint in production, the official guidance is to pin lerobot==0.5.1. For how GR00T compares with Pi0 and Gemini Robotics as a family, see our VLA models comparison of GR00T, Gemini Robotics and Pi0.

Four more VLAs arrive:

Policy	Backbone / size	What stands out
MolmoAct2 (AI2)	~12 GB inference at bf16	Full lifecycle; LoRA fine-tuning fits on one 24 GB GPU; zero-shot SO-100/101 checkpoints
EO-1	Qwen2.5-VL-3B + flow matching	`--policy.type=eo1`; pretrained on interleaved vision-text-action data
Multitask DiT	~450M diffusion transformer	TRI Large Behavior Models recipe; CLIP vision and language conditioning
EVO1	0.77B, InternVL3-1B backbone	Two-stage fine-tuning; RTC support out of the box

Note that the release notes publish no benchmark success rates for these new policies. Treat any leaderboard numbers you see in secondhand recaps with suspicion until you reproduce them with lerobot-eval.

Data: codecs, depth and language

Three changes to the data path matter for migration.

Codec control moved. v0.6 adds --dataset.rgb_encoder.* options that expose codec, quality, pixel format, GOP and presets. Setting vcodec=auto probes for hardware encoders (NVENC, VideoToolbox, VAAPI, QSV) and falls back to software AV1. The old --dataset.vcodec flag is renamed to --dataset.rgb_encoder.vcodec, so RGB and depth streams can use different codecs. Existing datasets can be re-encoded with lerobot-edit-dataset --operation.type reencode_videos.

Depth is end to end. With an Intel RealSense and use_depth: true, depth is captured in millimetres, stored as compact 12-bit depth video beside the RGB streams, and decoded back to physical units at training time. The blog lists SO-100/101, Koch, OpenArm, reBot and Unitree G1 among supported robots.

Language becomes structured. Datasets now natively store timestamped subtasks, plans, memory, corrections, speech and per-camera VQA pairs. The lerobot-annotate CLI fills these in with a VLM that watches your episodes, and v0.6.1 lets it run on HF Jobs. The legacy per-frame subtask_index annotation is superseded by these columns.

Loading is faster too. Multi-camera frames decode in parallel, workers pass compact uint8 frames with four times less inter-process memory, and persistent workers keep decoder caches alive. Hugging Face reports training on video datasets up to about 2x faster. Loading an episode subset dropped from 275 s to 0.06 s in their benchmark. Sampling is now deterministic and resumable, so an interrupted run restarts sample-exact.

Benchmarks: nine families under one CLI

v0.5 positioned LeRobot as an evaluation hub. v0.6 adds six simulation benchmarks, all under lerobot-eval, each with a docs page, a Docker image and a SmolVLA baseline smoke-tested in CI:

Benchmark	Scope (per HF release blog)
LIBERO-plus	~10,000 perturbed LIBERO variants across seven axes
RoboTwin 2.0	50 bimanual tasks on SAPIEN; 100k+ trajectories on the Hub
RoboCasa365	365 kitchen tasks in 2,500 procedurally generated kitchens
RoboCerebra	Long-horizon episodes of 3 to 6 sub-goals; 6,660-episode dataset
RoboMME	Memory exam: 16 tasks across 4 memory suites
VLABench	Knowledge and reasoning in manipulation

Add LIBERO, Meta-World and NVIDIA IsaacLab-Arena and you have nine benchmark families. Parallel evaluation now defaults to async vectorized environments, benchmarked at up to 2x faster. That default change is itself a behavioural difference worth testing if you compare eval numbers across versions.

Training: FSDP, HF Jobs and real bf16

Training gains FSDP through Accelerate. Parameters, gradients and optimizer state shard across GPUs, and checkpoints are gathered back into a single model.safetensors that loads like any other policy. You can also resume an FSDP run on a different GPU count. --job.target=a10g-small sends the same lerobot-train command to HF Jobs, with hardware from a T4 up to 8x H200 billed pay-as-you-go. --policy.dtype=bfloat16 now drives real mixed-precision training through Accelerate.

Every Breaking Change from 0.5.1 to 0.6.1

This is the table to keep open while you upgrade. The first eight rows come from the v0.6.0 release notes; the rest are v0.6.1 changes that can bite.

Area	v0.5.x (old)	v0.6.x (new)	Action
Install	`pip install lerobot` included dataset and training deps	Lean base, ~40% fewer deps; feature-scoped extras	Install `lerobot[training]`, `lerobot[dataset]`, etc.
Imports	Internal submodule paths worked	Some import paths changed	Use canonical public entry points
GR00T	GR00T N1.5	GR00T N1.7 (`nvidia/GR00T-N1.7-3B`)	Port to N1.7 or pin `lerobot==0.5.1`
PyTorch	Older versions accepted	Minimum 2.7; supported 2.7–2.11	Upgrade torch; check CUDA wheel
Train config	`eval_freq`	`env_eval_freq`	Rename key in configs and scripts
RL policy	`--policy.type=sac`	`gaussian_actor` under modular RL API	Rename type; re-check RL configs
Annotations	Per-frame `subtask_index`	Language columns	Re-annotate or convert
Video codec flag	`--dataset.vcodec`	`--dataset.rgb_encoder.vcodec`	Update record commands
Types module (0.6.1)	`lerobot.types`	`lerobot.lerobot_types`	Update imports
DataLoader (0.6.1)	Platform default start method	`multiprocessing` option, default `spawn`	Make worker code spawn-safe
LIBERO env (0.6.1)	Previous fps default	`LiberoEnvConfig` fps default 20	Pin fps if comparing old results

A few of these deserve more than a row.

The lean install is the one that breaks everything first

Hugging Face says base dependencies dropped by roughly 40%. The intent is good: if you only read LeRobot datasets, you no longer install hardware drivers. The PyPI metadata for 0.6.1 lists extras including dataset, training, hardware, evaluation, core-scripts, viz, per-robot extras such as feetech, dynamixel, unitree-g1 and intelrealsense, and per-policy extras such as groot, smolvla, pi, molmoact2, eo1, evo1, robometer, topreward and hilserl. There is also an all extra.

The blog spells one extra [core_scripts] while PyPI lists core-scripts. Recent pip versions normalize underscores and hyphens in extra names (PEP 685), so both should resolve; use the hyphenated PyPI spelling to be safe with older tooling. Missing-dependency errors now tell you which extra to add, which makes the failure easy to fix once you know to read the message.

The RL rebuild is more than a rename

The v0.6.0 notes say the RL stack was rebuilt and the sac policy type is now gaussian_actor under a new modular RL API. The name suggests the design intent: the actor (a Gaussian policy head) is separated from the algorithm that trains it. If your HIL-SERL pipeline only changed the policy type string, it may launch. If it subclassed SAC internals or imported from old RL module paths, expect real porting work. v0.6.1 also added a multiprocessing option to the RL training pipeline, defaulting to spawn.

v0.6.1: the rename nobody expects in a point release

A point release usually means bug fixes. v0.6.1 renamed lerobot.types to lerobot.lerobot_types (PR #4232). If you upgraded to 0.6.0 in July and pinned lerobot>=0.6,<0.7, a fresh environment built after 2026-08-03 resolves to 0.6.1 and your import breaks. Pin exact versions in production images.

v0.6.1 also added the DataLoader multiprocessing option with spawn as the default (PR #4139), and the same option for the RL pipeline (PR #4140). It refactored Pi0, Pi0.5, Pi0-FAST, EO-1 and SmolVLA onto shared VLA components. Wall-X and X-VLA now subclass native Transformers classes instead of vendoring them. It also added slice support to LeRobotDataset.__getitem__ and gradient checkpointing for Diffusion.

Step-by-Step Migration from 0.5.1 to 0.6.1

The order below matters. It moves from the changes that stop your code importing, to the ones that change behaviour silently.

Figure 2: The upgrade decision tree. Answer each question in order; every “yes” branch is a concrete code or config change.

The tree front-loads the one decision that can block the whole upgrade: GR00T N1.5. If you cannot retrain on N1.7 yet, stop there and pin 0.5.1 for that workload. Every other branch is a mechanical rename.

Step 1: Inventory what you actually use

Before touching versions, grep your repository and configs for the strings that changed: sac, eval_freq, vcodec, subtask_index, lerobot.types, and any groot policy references. Also list every CLI you call (lerobot-record, lerobot-train, lerobot-eval) and every robot and camera type. That list drives which extras you need.

Step 2: Decide on GR00T

If you run a fine-tuned GR00T N1.5 checkpoint, you have two options. Keep that service on lerobot==0.5.1 in its own environment, or retrain from nvidia/GR00T-N1.7-3B. The release notes describe no checkpoint conversion path, and N1.7 uses a different VLM (Cosmos-Reason2-2B), so plan on the weights not being compatible. Budget a real fine-tune and a re-evaluation.

Step 3: Build a clean environment with explicit extras

Create a fresh environment rather than upgrading in place. Stale transitive dependencies from the old fat install can hide missing extras, which then surface later on a clean CI runner. The project now commits a uv.lock as its authoritative dependency spec, and Linux uv installs pin CUDA 12.8 wheels.

# Illustrative: pick the extras that match your inventory
pip install "lerobot[training,dataset,evaluation,feetech,smolvla]==0.6.1"

# GR00T users
pip install "lerobot[groot]==0.6.1"

The extras names above are taken from the PyPI metadata for 0.6.1; the combination is illustrative. Confirm PyTorch is 2.7 or newer inside the environment before going further.

Step 4: Apply the mechanical renames

Update configs and scripts in one commit so the diff is reviewable.

# Illustrative before/after, train config
- eval_freq: 20000
+ env_eval_freq: 20000

# Illustrative before/after, record command
- --dataset.vcodec=h264
+ --dataset.rgb_encoder.vcodec=h264

# Illustrative before/after, RL policy type
- --policy.type=sac
+ --policy.type=gaussian_actor

# v0.6.0 and earlier
from lerobot.types import ...
# v0.6.1 and later
from lerobot.lerobot_types import ...

Also replace any imports from internal submodules with the canonical public entry points the release notes point to. If an import fails after the upgrade, check the docs for the public path before copying a deep path from the source tree. Deep paths are exactly what the release notes told you not to depend on.

Step 5: Handle datasets deliberately

Your v0.5-era datasets still load, but two things need attention. If your training relied on per-frame subtask_index, move to the new language columns, either by running lerobot-annotate or by converting your existing labels. If you want a different codec for old data, use lerobot-edit-dataset --operation.type reencode_videos rather than re-recording.

# Verified command shape from the v0.6.0 release blog
lerobot-edit-dataset \
    --repo_id ${HF_USER}/my_dataset \
    --operation.type reencode_videos \
    --operation.rgb_encoder.vcodec h264 \
    --operation.rgb_encoder.crf 23

Write re-encoded or re-annotated data to a new repo ID. You want the old dataset intact as a control.

Step 6: Re-baseline before you trust any comparison

Retrain one known-good policy on one known-good dataset and evaluate it on 0.6.1. Several defaults changed between versions: async vectorized envs for eval, the spawn DataLoader start method, deterministic sampling and the LIBERO fps default of 20. Any of these can shift your metrics slightly. Only compare new policies against this re-baselined number, not against numbers produced on 0.5.1.

The DAgger Rollout Loop in Practice

DAgger (Dataset Aggregation) is the classic answer to compounding error in imitation learning. A policy trained only on expert demonstrations never sees the states it drifts into when it makes a small mistake. DAgger fixes that by collecting expert labels on the states the policy actually visits. v0.6’s dagger strategy implements a human-gated version of that idea on real hardware.

Figure 3: One DAgger intervention. Only the human-corrected frames carry the intervention flag. Autonomous frames are recorded only if you enable --strategy.record_autonomous=true.

The sequence shows why this is more than recording with a pause button. The operator watches the policy run and presses a key, or a USB foot pedal (--strategy.input_device=pedal), the moment it goes wrong. Actuated leader arms are first driven to the follower’s pose, so the takeover is jerk-free. Correction frames are tagged intervention=True, control goes back to the policy, and the data is pushed to the Hub (every N episodes via --strategy.upload_every_n_episodes, default 5, or on demand).

One default matters here. Per the v0.6.1 deployment docs, the dagger strategy runs in corrections-only mode by default: only the human correction windows are recorded, and each correction becomes its own episode. To keep the autonomous frames around the corrections as well, add --strategy.record_autonomous=true, which switches to continuous recording with time-based episode rotation, as in sentry.

The command shape from the release blog looks like this:

lerobot-rollout \
    --strategy.type=dagger \
    --policy.path=${HF_USER}/my_policy \
    --robot.type=so100_follower \
    --robot.port=/dev/ttyACM0 \
    --teleop.type=so101_leader \
    --teleop.port=/dev/ttyACM1 \
    --dataset.repo_id=${HF_USER}/dagger_corrections \
    --dataset.single_task="Grasp the block"

Why the intervention flag is the valuable part

The flag turns an episode into labelled data about failure. With record_autonomous enabled, you can train on the full mixed dataset. You can also up-weight intervention frames, or filter for them to see which task phases fail most often. Before v0.6, teams built this bookkeeping themselves, usually with a side channel of timestamps that drifted out of sync with the dataset.

What the loop does not solve

Human-gated DAgger has known limits. The operator’s reaction time means the first few frames after a failure are already off-distribution when the takeover starts. Operators also differ in when they intervene; one catches drift early while another waits for a near-collision. That inconsistency ends up in your labels. Finally, the strategy needs an actuated leader. The human-in-the-loop docs say dagger requires teleoperators with active motors that can toggle torque and move to the follower’s pose; they list the SO-100/101 leader, bimanual SO leaders and the bimanual OpenArm Mini as compatible. A purely passive leader arm is not a supported setup.

A sensible cadence is short correction campaigns: deploy, collect a few dozen interventions, fine-tune, re-evaluate, repeat. Evaluate between rounds. A drop in intervention rate is a useful proxy for progress, but it is not a success rate.

Reward Models: From Demonstrations to Measured Progress

The reward API is the least flashy part of v0.6 and possibly the most useful for teams with messy data.

Figure 4: lerobot.rewards puts four reward models behind one interface. Their progress and success signals feed three downstream uses.

All four sit behind the same interface, but their outputs differ. The HIL-SERL classifier predicts success. SARM, Robometer and TOPReward estimate task progress from episode video plus a task instruction, and the release blog says Robometer and TOPReward ship labeling scripts that write per-frame progress curves into your dataset. They also differ in what they cost you up front:

Reward model	Training needed	Best used for
HIL-SERL classifier	Trained per task on your success/failure labels	RL reward on one well-defined task
SARM	Trained on your demonstrations with subtask annotations (added in v0.5)	Multi-stage tasks where progress is uneven
Robometer-4B	None; pretrained on 1M+ trajectories	General progress scoring across datasets
TOPReward	None; zero-shot from a Qwen3-VL model	Quick triage when you have no reward data

Three things to do with a progress curve

Reward-aware behavior cloning (RA-BC). Plain behavior cloning treats every demonstration frame as equally good. RA-BC uses the progress signal to weight frames, so hesitant or backtracking segments count less. For teleoperated data from novice operators, this is the cheapest quality lever available.

Dataset QA. Episodes whose progress curve never approaches completion are candidates for review or removal. On a dataset of several hundred episodes, that turns a manual review of every video into a review of the flagged tail.

Progress-overlay videos. Rendering the curve on top of the video makes failure modes visible to people who do not read loss curves, such as the operators you are trying to coach.

Trusting a zero-shot reward

TOPReward’s mechanism is simple and cheap: read the log-probability of “True” from a VLM given the video and instruction. It inherits the VLM’s blind spots. It may judge a grasp from a camera angle that cannot see contact, or accept a visually similar but wrong object. Robometer was trained specifically on robot trajectories, which should make it more reliable on manipulation, at the cost of running a 4B model. Neither replaces a ground-truth success check in evaluation. Use them to rank and weight data, and validate on a small hand-labelled sample before trusting either one to filter.

Trade-offs, Gotchas, and What Goes Wrong

Most upgrade failures fall into a few recognisable patterns.

Silent config drift. Renamed keys like eval_freq may not raise an error in every config path. Depending on how your config is loaded, an unknown key can fail loudly or be ignored. If it is ignored, you train with no environment evaluation and only notice at the end. Grep for the old names rather than trusting the run to fail.

The spawn DataLoader default. Under spawn, each worker starts a fresh interpreter and re-imports your modules. Code that relied on fork semantics, such as global state set in the parent, un-picklable lambdas in transforms, or module-level side effects, can break or slow down startup. On Linux, where fork has historically been the default start method, this is new behaviour. The new option lets you choose the start method, so you can switch back while you fix the code, but aim to make workers spawn-safe.

Unpinned minor ranges. The lerobot.types rename landed in a point release. Pin exact versions in Dockerfiles and lockfiles, and upgrade on purpose.

GR00T lock-in. Because N1.7 replaces N1.5, any team with an N1.5 production policy now runs two LeRobot versions. Keep them in separate environments and separate images. Do not try to share one dependency set.

GPU memory assumptions. New policies vary widely. MolmoAct2 inference needs about 12 GB at bf16. LingBot-VA needs a 24–32 GB GPU. EVO1 at 0.77B parameters is aimed at modest GPUs. FSDP helps you train models bigger than one GPU, but it does not shrink inference. Check the compute hardware guide’s measured VRAM envelopes before promising a policy on an edge box.

Eval comparability. Six new benchmarks, async vectorized envs and the LIBERO fps default mean numbers from 0.5.1 and 0.6.1 are not directly comparable. Re-run baselines on the new version.

Simulator setup. Each benchmark has its own system dependencies. The docs pages have exact recipes, and every benchmark ships a Docker image. Use the images in CI rather than hand-building simulator stacks.

Annotation cost and quality. lerobot-annotate runs a VLM over every episode. It is cheap in engineering time and not free in compute, which is why v0.6.1 added HF Jobs support. VLM-generated subtasks are also only as good as the model’s understanding of your scene. Spot-check annotations before you train a language-conditioned policy on them.

Practical Recommendations

Treat v0.6 as two projects: a platform upgrade you finish quickly, and a workflow change you adopt gradually. The platform upgrade is mostly renames and extras; in our judgement it is a day or two of work for a typical single-robot project. The workflow change, using rollout, DAgger and reward models, is where the value is. It deserves a few weeks of careful experiments.

Go straight to 0.6.1 rather than stopping at 0.6.0. You would otherwise take the lerobot.types rename as a second migration a month later. Keep one frozen 0.5.1 environment only if you have a GR00T N1.5 dependency or an in-flight experiment that must stay comparable.

Once you are upgraded, adopt features in this order. Use the faster data loading and deterministic sampling immediately; they need no change. Add a reward model for dataset QA next, because it improves the data you already have. Then run a small DAgger campaign on your weakest task. Try the world-model policies and new VLAs last, and only once your evaluation harness is re-baselined.

Checklist:

[ ] Grep for sac, eval_freq, vcodec, subtask_index, lerobot.types and GR00T references
[ ] Decide GR00T N1.5: pin lerobot==0.5.1 or retrain on N1.7
[ ] Fresh environment, PyTorch 2.7+, explicit extras, exact version pin 0.6.1
[ ] Apply renames: env_eval_freq, gaussian_actor, rgb_encoder.vcodec, lerobot_types
[ ] Switch deep imports to canonical public entry points
[ ] Make DataLoader worker code spawn-safe
[ ] Move subtask_index usage to language columns
[ ] Re-baseline one known policy on 0.6.1 before comparing anything
[ ] Replace record-based deployment scripts with lerobot-rollout

Frequently Asked Questions

What is the main difference between LeRobot v0.6 and v0.5?

v0.5 widened hardware and policy coverage, adding the Unitree G1 humanoid, Pi0-FAST, Real-Time Chunking and EnvHub. v0.6 closes the robot-learning loop. It adds world-model policies (VLA-JEPA, LingBot-VA, FastWAM), GR00T N1.7 and four other VLAs, a lerobot.rewards API, six new benchmarks under lerobot-eval, and the lerobot-rollout CLI with a DAgger strategy. It also restructures installation into feature-scoped extras and renames several config keys, flags and modules, so upgrading requires code and config changes, not just a version bump.

Why does my code break after pip install -U lerobot?

Since v0.6.0, pip install lerobot is a lean base install with roughly 40% fewer dependencies. Dataset and training dependencies moved into extras. Install what you need explicitly, for example lerobot[training], lerobot[dataset] or a policy extra like lerobot[groot]. Missing-dependency errors now name the extra to add. If the failure is an import error on lerobot.types, you are on 0.6.1, where the module became lerobot.lerobot_types. Also check that PyTorch is 2.7 or newer.

Can I still use GR00T N1.5 with LeRobot?

Not on v0.6. GR00T N1.7 replaces N1.5 in LeRobot, and the release notes say to pin lerobot==0.5.1 if you need N1.5. N1.7 uses Cosmos-Reason2-2B as its VLM with a flow-matching action head, and the release notes describe no conversion path, so do not expect N1.5 fine-tunes to load as N1.7. To move forward, fine-tune from NVIDIA’s nvidia/GR00T-N1.7-3B checkpoint and re-evaluate. Many teams will run both versions in separate environments during the transition.

How does the lerobot-rollout DAgger strategy work?

You launch lerobot-rollout --strategy.type=dagger with a policy, a follower robot and a teleoperator such as a leader arm. The policy runs autonomously. When it starts to fail, you press a key or a foot pedal. An actuated leader arm is driven to the follower’s pose, you correct the behaviour, and then you hand control back. Correction frames are tagged with an intervention flag and the data is pushed to the Hub, ready for the next fine-tune. By default only the correction windows are recorded; add --strategy.record_autonomous=true to keep the autonomous frames too. The teleoperator must have active motors, such as an SO-100/101 leader.

What replaced the sac policy type in LeRobot?

In v0.6.0 the reinforcement-learning stack was rebuilt around a new modular RL API, and the sac policy type became gaussian_actor. The new name reflects the split between the actor, a Gaussian policy head, and the algorithm that trains it. Configs that only set the policy type need the string changed. Code that subclassed SAC internals or imported old RL module paths needs porting. v0.6.1 also added a multiprocessing option to the RL training pipeline that defaults to spawn.

Should I upgrade to LeRobot 0.6.0 or go straight to 0.6.1?

Go straight to 0.6.1, released on 2026-08-03. It carries one more breaking change, the lerobot.types to lerobot.lerobot_types rename, so upgrading to 0.6.0 first would mean two import migrations. It also adds a spawn-by-default DataLoader option, slice support in LeRobotDataset.__getitem__, HF Jobs support for lerobot-annotate and shared VLA components for the Pi0 family, EO-1 and SmolVLA. Pin the exact version in production.

References

Hugging Face, “LeRobot v0.6.0: Imagine, Evaluate, Improve” (2026-07-07): https://huggingface.co/blog/lerobot-release-v060
LeRobot v0.6.0 GitHub release notes: https://github.com/huggingface/lerobot/releases/tag/v0.6.0
LeRobot GitHub releases, including v0.6.1 and v0.5.x: https://github.com/huggingface/lerobot/releases
Hugging Face, LeRobot v0.5.0 release blog (2026-03-09): https://huggingface.co/blog/lerobot-release-v050
LeRobot on PyPI (release history and extras): https://pypi.org/project/lerobot/
LeRobot documentation: https://huggingface.co/docs/lerobot/index
Robometer paper (RSS 2026): https://arxiv.org/abs/2603.02115

By Riju — about