# WorldFoundry, five console scripts and one shared entry point

> WorldFoundry is an open-source stack for world models: a shared layer over dozens of video generation, 3D, and action policy runners, with inference exposed through a TUI, a CLI, a Studio, an MCP server, and a benchmark evaluator. The README sells model coverage, but the more revealing details are in the packaging, where five console scripts share two implementations and the version comes from a repository with no tags.

**OpenEnvision/WorldFoundry** — Unified World Model Inference & Evaluation Infrastructure

- Repository: https://github.com/OpenEnvision/WorldFoundry
- Website: https://openenvision.github.io/WorldFoundry/
- Stars: 318 · Forks: 23
- Language: Python
- License: not declared
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openenvision-worldfoundry

## Two console scripts are the same function

There are five entry points declared, and they resolve to three implementations.

worldfoundry and worldfoundry-eval both map to worldfoundry.cli:main. Two names, one entry function, and no documentation of what the shorter name does differently, since it is the same code path.

The other three are distinct. worldfoundry-mcp maps to worldfoundry.mcp:main, worldfoundry-studio to worldfoundry.studio.cli:main, and worldfoundry-tui to worldfoundry.cli.tui:main. Note that the TUI lives under a cli.tui submodule while the general CLI sits at cli, which means the terminal interface is a separate program that the general one may or may not call into.

The duplication of the eval name is harmless in practice and slightly confusing in documentation. It reads as though there is an evaluation-specific CLI when in fact evaluation is reached through the same main function, possibly by subcommand.

The presence of an MCP entry point is the more consequential one. It means the same runners and assets can be driven by an assistant through the protocol, which puts tool descriptions and argument names in a path where a typo becomes a failed call rather than a typo.

## The version comes from tags and there are none

The build backend is setuptools with setuptools-scm for versioning, and the repository has no releases.

The project section marks the version as dynamic, which is the correct pairing with scm-based versioning: the number is derived from the git history rather than written in the file. Scm versioning also records the exact commit in the built artifact, which is the right behaviour for a project that pins specific model checkpoints.

The problem is the input. Scm derives a version from tags, and this repository has no GitHub releases and no release tags in the visible history. The v0.2.0 named in the news section is a heading in the README rather than a tag anyone can check out.

What you get from a clone is therefore a development version derived from whatever the fallback behaviour is, not 0.2.0. That is a real difference when you are writing a requirements file or a container pin, and it is a five second check that will tell you which of the two you have.

Everything else in the metadata is modern. The licence is declared as an SPDX expression with a separate licence-files entry, and requires-python is bounded at >=3.10,<3.14. The classifiers, though, list only Python 3.10.

## Five dependencies at the core and the rest behind extras

The core install is tiny for a project that integrates this many models.

The core dependencies are msgpack, packaging, pyyaml, tqdm, and websockets. Five entries, none of them a machine learning library. Everything that touches a checkpoint lives in an optional group.

There are three of the visible ones. The api group brings dashscope, openai at 1 or newer, pillow, qwen-vl-utils, and requests. The hf group brings huggingface-hub with its CLI extra, modelscope, and sortedcontainers. The video group is where the weight sits, with accelerate, albumentations, av, decord, imageio and its ffmpeg build, omegaconf, onnxruntime, opencv-python, openpyxl, and a long tail of training and media libraries.

Three dependency surfaces in total: environment.yml for conda, a requirements/ directory, and the extras in pyproject.toml. That is one more thing to keep in step than a single file would be, and the first day workflow step says to bootstrap conda, which suggests the conda file is the path of least resistance.

A separate build, a separate requirements directory, and separate extras is a normal shape for a project whose optional surface is this large. It is also three places where a version can drift.

## Two exact pins sit inside the video extra

The video group is long and almost entirely unpinned, with two exceptions that are pinned exactly.

moviepy is pinned to 1.0.3 and lightning to 2.6.1, both with equality rather than a range. Every other entry in the group is a bare name or a lower bound: accelerate, attrs, av, dm-tree, easydict, einops, ftfy, h5py, hydra-core, iopath, librosa, lmdb, loguru, nvidia-ml-py, numpy, and onnxruntime among them.

Exact pins in an extra are usually there because an upstream API changed and the code has not caught up. That is a fair reason, and it is also a trap for anyone who needs a different version of that library for their own reasons, because pip will refuse rather than degrade.

The api group shows the other extreme of discipline by comparison. It has the only bounded range in the file, requests at 2.32.0 or newer and below 3.0.0, which is the shape you want for a library whose major versions break callers.

So the dependency policy is: one careful range for HTTP, two hard stops for the media and training stack, and everything else floating. The floating part is fine until it is not.

## make help documents six targets out of twenty

The Makefile is the most complete description of how the project is worked on, and it is mostly a list of names.

There are twenty phony targets. The help target prints six of them: install-core, install-dev, test-fast, docs-check, lint, and preflight. The other fourteen are declared but undocumented there, among them ruff-check, format-check, shell-check, data-check, runtime-registry-check, compile-eval, cli-check, precommit, and precommit-install.

Several of those names describe checks that matter more than they appear to. docs-check is described as validating documented CLI entrypoints, which reads as a test that the commands in the documentation still exist. runtime-registry-check and data-check sound like guards on the model registry and the benchmark data. cli-check writes to tmp/ci-cli-check.

The variables at the top show the same care. PYTHONPATH defaults to the current directory, the eval module is invoked as python -m worldfoundry.cli, and checkpoint storage defaults to a path under the home directory cache rather than anything inside the checkout, which is the same rule the first workflow step states: checkpoints and datasets are staged outside git.

install-core and install-dev both run an editable install of the project; the second adds build, pre-commit, pytest, PyYAML, and ruff.

## test-fast points at a directory the root listing lacks

One inconsistency is visible between the build tooling and the repository contents.

The test-eval-core target runs a fast_eval_core marker over seven named test files under a test/eval_core/ path: API contracts, metric registry, task yaml, run manifest, public namespace, scorecard snapshot, and contract stability.

Those seven names line up exactly with the evaluation discipline the README describes. The day-one workflow says to score only after artifacts match the benchmark layout and to use scorecards for readiness claims. A test called test_scorecard_snapshot and another called test_contract_stability are what enforce those sentences, which makes the repository more rigorous about its own claims than the README gives it credit for.

The problem is the path. The top-level listing has no test directory. It contains docker/, docs/, requirements/, scripts/, thirdparty/, and worldfoundry/, plus the build files. So either the tests live inside the package and those paths are stale, or the target does not resolve from a clean checkout.

Worth confirming before you rely on make test-fast as your first smoke test.

## v0.2.0 is a news heading and not a tag

The news section dates things precisely and one of them cannot be checked out.

The repository was open-sourced on 11 July 2026, passed a hundred stars on 12 July, and the v0.2.0 major infrastructure overhaul is dated 17 July 2026. The last push to main is 10 September 2026, which is also the date of a news entry saying an official update is ready for release and promising broad updates to WorldFoundry and another project the following week, with technical reports and an entirely new open-source documentation set.

There are no GitHub releases. So v0.2.0 exists as prose, and the September update exists as an intention.

What the 0.2.0 entry does contain is the most concrete description of the project anywhere. Core inference was refactored to an inference-only path with Wan, HunyuanVideo, LTX2, Cosmos, perception, and 3D foundation modules integrated. Attention backend selection is unified across FlashAttention 2 and 3, SageAttention, xFormers, and an SDPA fallback. Triton kernel registration, compilation and inference caching are in, along with NVFP4 quantization and GPU selection driven by actual compute capability on A100 and H100. Multi-GPU context and sequence parallel came with memory management. Studio gained conda environment isolation, GPU allocation, and torchrun distributed launch. Benchmarks added LaryBench, WorldReasonBench, and WRBench.

That is a large surface area for six days between open sourcing and the version heading, and the demo gallery answers to it with nine videos checked into the docs tree. The gallery itself carries a caveat: full release claims require the matching run manifest, runtime profile, and validation scorecard.

## Conclusion

WorldFoundry is worth trying if you want one interface across many world model checkpoints rather than per-project integration scripts, and if you are willing to assemble the environment yourself. Check four things first. Whether the extras you need resolve, since the core package installs five dependencies and everything substantial lives behind an extra. Whether the version you get is one you can name, because the build backend reads tags and this repository has no releases. Which entry point you should call, since worldfoundry and worldfoundry-eval are the same function. And whether you accept an alpha-classified project whose own news section promises this project's next release alongside another one's.

## FAQ

### Which interfaces does WorldFoundry expose for running models?

Five console scripts: worldfoundry and worldfoundry-eval, which both map to worldfoundry.cli:main, plus worldfoundry-mcp, worldfoundry-studio, and worldfoundry-tui. Inference is described as reachable through TUI, CLI, scripts, or Studio.

### What does WorldFoundry install by default?

The core package has five dependencies: msgpack, packaging, pyyaml, tqdm, and websockets. Model support lives in optional groups, including api for dashscope, openai, pillow, qwen-vl-utils, and requests, hf for huggingface-hub, modelscope, and sortedcontainers, and a large video group.

### How does WorldFoundry decide which version you installed?

pyproject.toml marks the version as dynamic and the build backend uses setuptools-scm, which derives it from git tags. The repository has no GitHub releases, so v0.2.0 appears in the README news section rather than as a tag you can check out.

### What is the first workflow step in WorldFoundry?

Environment and assets: bootstrap conda and stage checkpoints and datasets outside git. Checkpoints default to a path under the home directory cache. Then you generate and inspect artifacts through TUI, CLI, scripts, or Studio, and only score them once the artifacts match the benchmark layout.

## Sources

- [Issues](https://github.com/OpenEnvision/WorldFoundry/issues)
- [License: Apache-2.0](https://github.com/OpenEnvision/WorldFoundry/blob/main/LICENSE)
- [OpenEnvision/WorldFoundry on GitHub](https://github.com/OpenEnvision/WorldFoundry)
- [Project website](https://openenvision.github.io/WorldFoundry/)
- [README](https://github.com/OpenEnvision/WorldFoundry/blob/main/README.md)

---

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