LeRobot 0.7: Loading Weights Is Not Resuming Training

LeRobot 0.7 changes a distinction that robot-learning courses should make explicit: loading a model's weights and resuming its training are different operations. The November 5, 2026 release notes say the old FSDP training path is replaced and warn that FSDP checkpoints saved with LeRobot 0.6 or earlier cannot be resumed through the new path, although their model.safetensors weights still load. That is a migration boundary, not a declaration that the learned model has disappeared.

A saved model and a saved training state answer different questions

Weights describe the model parameters being loaded. A training-resume workflow needs the state required by its supported checkpoint mechanism to continue a run. The release's explicit separation of those outcomes is the starting point for reading an older experiment folder. A file being readable does not establish that the whole training process can continue from the same point.

Figure 1 draws an older FSDP checkpoint with two separate questions: whether its model weights can be loaded and whether the legacy run can be resumed under the changed stack. It contains no real checkpoint, model name or pass result. The permitted weights path should not be connected back to the unsupported resume path by an invented conversion arrow.

In a hypothetical course exercise, a learner may want to inspect a previously trained policy rather than continue optimization. That goal differs from reproducing the continuation of the original experiment. Naming the goal first prevents an import success from being presented as evidence that the previous training state was restored.

The converse is also useful: a migration error in the resume path does not by itself demonstrate that the weights are corrupted. The release identifies a known boundary between old and new distributed-training arrangements. A learner should preserve the original files and identify the operation attempted before drawing a conclusion about their contents.

The new stack has its own checkpoint mechanism

The official 0.7 release article describes FSDP2 and HSDP, gradient accumulation and Torch Distributed Checkpoints. It presents them as part of the rebuilt training framework. The announcement's performance observations concern its described experiments; this article does not repeat those numbers as expectations for a different model or machine.

Figure 2 separates the historical training environment from a proposed new training run. Each has its own configuration and checkpoint record. A comparison can connect them through a clearly stated use of weights, but that does not make their histories identical. Starting a new run from learned weights is a new experimental choice and should be documented that way.

A meaningful learning record could identify the originating LeRobot release, training topology and intended continuation operation. If any of those are unknown, leave them unresolved. A directory called checkpoint is not enough to establish which implementation produced it or which state the new version expects.

Configuration changes travel with the framework change

The breaking-change section also identifies new parallelism configuration and a changed mixed-precision configuration location. It notes that old Accelerate YAML and environment configuration is rejected by default. Those details reinforce that a migration is not simply a different executable opening the same folder with unchanged assumptions.

For an explicitly hypothetical migration review, the instructor could compare the old experiment description with the new documented configuration, marking what is supported, what has moved and what must become a separate experiment. This article provides no commands to bypass configuration checks and does not alter an existing environment.

Other changes in the release, including experiment tracking, are separate from checkpoint compatibility. A successful connection to a tracking interface would not prove a training state resumed correctly. Likewise, a training process starting without an error does not show it recovered the intended step, optimizer state or data progression. The relevant observations depend on the supported workflow.

When later comparing learning curves, record whether a run was continued or restarted from weights. Combining the two labels can obscure why curves begin at different points or have different histories. No curves were measured here, and no accuracy or convergence improvement is claimed.

Make the learning objective explicit before choosing an operation

A student might need inference, evaluation, further fine-tuning or a faithful training continuation. Those goals may use overlapping artifacts while requiring different state. A clear exercise asks the student to identify the goal and evidence before selecting a workflow. It should not reward a generic success message detached from the operation being studied.

No model was downloaded, no GPU job was started and no external generation service was used in preparing this article. The diagrams are original conceptual artwork. They make the release's compatibility boundary visible without inventing a conversion procedure or claiming a legacy experiment was recovered.

Our robot-learning release notes follows changes that affect courses and experiments, while the learning-path reference supports their interpretation. LeRobot 0.7's warning is precise: retain the distinction between loading weights and resuming the historical training process.