# nano-world-model trains a diffusion world model you can read end to end

> The nano-world-model repository is a deliberately small research codebase for training video world models on diffusion-forcing, with one locked environment, hydra configurations, published checkpoints and ablation tables so the design choices can be checked rather than taken on trust.

**simchowitzlabpublic/nano-world-model** — A Minimalist, Batteries-included Repository for Advancing World Model Science.

- Repository: https://github.com/simchowitzlabpublic/nano-world-model
- Website: https://simchowitzlabpublic.github.io/nano-world-model/
- Stars: 766 · Forks: 51
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/simchowitzlabpublic-nano-world-model

## The scope is deliberately small and the configuration is deliberately strict

The repository describes itself as a minimalist, batteries-included repository for advancing world model science, and the code is training video world models based on diffusion-forcing. The word minimalist is a design constraint rather than a marketing word, and it is visible in the environment setup. The supported Linux x86_64 environment uses one committed lock for Python, PyTorch, CUDA wheels and all dependencies, and the instructions ask you to install uv first. The pyproject pins the interpreter range tightly, to Python 3.11 but not 3.12, and pins torch at 2.7.1 with a comment noting that cu128 supports Ampere and Blackwell. Almost every dependency carries a comment explaining why the version is what it is, such as Lightning 1.9 importing pkg_resources, the NumPy 1 ABI needed by decord and the legacy simulator stack, and diffusers 0.29.2 being compatible with LeRobot 0.3.3 and modern huggingface-hub. That annotation is the most useful thing in the file, because it turns a lock file into a set of decisions someone else had to make.

## One wrapper script does sync, doctor and run

The entry point is a script called nanowm, and the setup is three commands.

```bash
git clone https://github.com/simchowitzlabpublic/nano-world-model.git
cd nano-world-model
./nanowm sync
./nanowm doctor --require-cuda
```

The doctor check is the interesting one, because it verifies the environment against the committed lock and fails loudly if the CUDA stack does not match what the code expects. There is a separate path for the RT-1 and LeRobot dependencies with ./nanowm sync --extra rt1, and the readme warns not to install lerobot-datasets, since that is a dataset format version rather than a PyPI package. For anyone without a Linux GPU box, there is a Colab quickstart notebook that downloads the official Point Maze checkpoint and previews predictions beside recorded validation frames, and it uses the same lock. The repository is careful to say the supported environment is Linux x86_64, so the Colab path is a preview route rather than a full training route.

## Hydra configuration is how every experiment is expressed

Training runs are expressed as combinations of an experiment, a dataset and a model, and that is the whole interface. The PushT run with the NanoWM-B/2 model and default settings.

```bash
./nanowm python src/main.py experiment=dino_wm_pusht dataset=dino_wm/pusht model=nanowm_b2
```

The CSGO run with the L/2 model.

```bash
./nanowm python src/main.py experiment=csgo dataset=game/csgo model=nanowm_l2_csgo
```

And the RT-1 fractal main run.

```bash
./nanowm python src/main.py experiment=rt1 dataset=rt1/rt1 model=nanowm_b2
```

The readme explains the three-way split, with pred-v for the prediction target, additive for the injection mode and cosine plus ZTSNR for the noise schedule, and the feature list mentions that the unified pipeline covers training, validation and evaluation managed with clean hydra-based configuration systems. There is a documented config system covering the hydra layout, overrides and environment variables, and a path configuration mechanism where the committed templates point at a gitignored src/configs/local/paths.yaml file, with the data directories set through environment variables instead.

## The published numbers let you check the claims

The readme publishes quantitative results on 256 fixed samples with seed 42, 250 DDIM steps and sequential scheduling with frame-by-frame autoregressive denoising, across five metrics. The Point Maze model at 30k steps has PSNR 36.74, SSIM 0.984, LPIPS 0.019 and FID 9.66. The Wall model at 15k steps has the best SSIM at 0.994 and a FID of 2.64. PushT at 100k steps sits at PSNR 33.19 with FID 13.63, while Rope and Granular at 15k steps are lower at FID 35.20 and 40.05, and RT-1 at 300k steps is the weakest on every metric with PSNR 24.36, SSIM 0.787, LPIPS 0.180 and FID 35.08. The trend is the useful part, since the smaller and more controlled environments score best and the long robot manipulation task scores worst. The readme also points to per-domain methodology in docs/evaluation.md and to RT-1 ablation tables with checkpoint paths in the training guide, so the comparison is meant to be checked rather than believed.

## Checkpoints and the applications built on top

All model checkpoints are published, and the table lists the best-config runs with their step counts. There is a DINO-WM Point Maze checkpoint at 30k steps, DINO-WM Wall and Rope and Granular at 15k, DINO-WM PushT at 100k, RT-1 fractal at 300k, and a CSGO checkpoint at 100k using the larger NanoWM-L/2 model. The applications section lists three downstream uses. Long-horizon rollout is autoregressive generation from the trained checkpoints, and the CSGO 50-frame auto-regressive long rollout is shown as a sample. Video to 3D map uses Depth Anything 3 point cloud reconstruction from rollout videos. And MPC-style planning is cross-entropy-method planning over world model rollouts, which is the point of a world model in the control sense, since the model is used to search over action sequences rather than only to generate video. The library also has a scoring dependency, lpips, and FID evaluation through pytorch-fid, with a separate I3D torchscript for FVD that has to be downloaded by hand.

## Where a research codebase stops being usable

The first limit is the environment. A single committed lock with an exact torch version, a Python minor version pinned to 3.11 and a CUDA build chosen for Ampere and Blackwell is reproducible, and reproducible is not the same as portable. A team on a different GPU generation, a different CUDA or a different platform is not in the supported set, and the readme says the supported environment is Linux x86_64. The second limit is scale. The model sizes in the table are NanoWM-B/2 and NanoWM-L/2, and the configuration exposes a model scale axis, which is good for ablations and not what you would ship. The third is that the design space is a set of discrete choices, with pred-v as the prediction target, additive as the injection mode and cosine plus ZTSNR as the schedule, and the readme describes the contribution as head-to-head ablations across prediction target, action injection and model scale. That is exactly the right shape for a scientific repository and exactly the wrong shape for a framework, because there is no plugin contract and no general entry point beyond the hydra experiment configuration. The fourth is the data. The datasets are DINO-WM environments, RT-1 and CSGO, and the download instructions live in a separate document, so reproducing a number means assembling the same data first, which is the part of world model research that is never shared.

## Conclusion

nano-world-model suits a researcher who wants to understand a diffusion world model implementation rather than call a framework, and it suits a team that wants to reproduce published ablations before building on the approach. It is the wrong tool for a production system, since the code is a research artifact with an experimental API, and it is the wrong tool if you lack a CUDA GPU, since the doctor check requires one. Before running it, read docs/environment.md and the design choices section of docs/training.md, and set the data and results paths through the paths.yaml template rather than editing the committed configuration. The last push was on 2026-09-14 and the repository publishes no releases.

## FAQ

### How do I set up the nano-world-model environment?

Install uv first, clone the repository, then run ./nanowm sync and ./nanowm doctor --require-cuda, which verifies the environment against the committed lock. The supported environment is Linux x86_64, and the RT-1 and LeRobot dependencies need ./nanowm sync --extra rt1.

### How do I start a training run in nano-world-model?

Through the nanowm wrapper with an experiment, a dataset and a model, for example ./nanowm python src/main.py experiment=dino_wm_pusht dataset=dino_wm/pusht model=nanowm_b2. The CSGO variant uses experiment=csgo with model=nanowm_l2_csgo, and the RT-1 run uses experiment=rt1 with dataset=rt1/rt1.

### What results does the nano-world-model README publish?

Metrics on 256 fixed samples with seed 42, 250 DDIM steps and sequential frame-by-frame autoregressive denoising, reported as PSNR, SSIM, LPIPS and FID per domain. Point Maze at 30k steps shows PSNR 36.74, SSIM 0.984, LPIPS 0.019 and FID 9.66, while RT-1 at 300k steps is the weakest at PSNR 24.36 and FID 35.08.

## Sources

- [Issues](https://github.com/simchowitzlabpublic/nano-world-model/issues)
- [License: MIT](https://github.com/simchowitzlabpublic/nano-world-model/blob/main/LICENSE)
- [Project website](https://simchowitzlabpublic.github.io/nano-world-model/)
- [README](https://github.com/simchowitzlabpublic/nano-world-model/blob/main/README.md)
- [simchowitzlabpublic/nano-world-model on GitHub](https://github.com/simchowitzlabpublic/nano-world-model)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/simchowitzlabpublic-nano-world-model