OpenWorldLib: one codebase for a fast moving field of world models

The problem: every world model lives in its own repository

World models have become one of the most active areas of machine learning research, and they have become it in a way that makes reuse difficult. Each significant result arrives as its own repository, with its own environment, its own entry point, its own naming for the same concepts and its own checkpoint format. A paper that wants to compare three video generation methods spends most of its engineering time on that comparison rather than on the research.

OpenWorldLib is an attempt to change that. The project description is a unified codebase for advanced world models, and the stated goal is establishing a unified and standardized world model framework to make the invocation of existing world-model-related code more consistent and well-structured, together with integrating open-source world model research outcomes and systematically curating related papers for researchers' reference and use.

The audience is therefore a research group rather than an application team. This is a library for people who want to run other people's models, want them to look the same at the interface, and want to add their own method to a structure other people already understand.

The second half of the project, the curation of papers and open source projects into an awesome list document, is not a side note. It is half the value, because in a field moving this fast, knowing which method to reach for is often harder than running it.

The licence is Apache-2.0, the language is Python, the default branch is main, and the last push was on 2026-09-23. There are no GitHub releases, and the package version in the project metadata is 0.1.0.

The definition it adopts, and the three tasks that follow from it

The project defines a world model as a model or framework centered on perception, equipped with interaction and long-term memory capabilities, for understanding and predicting the complex world. That definition is worth reading slowly, because the three capabilities in it are what the framework is organised around.

From that definition the project derives its sub-tasks: multimodal understanding, visual action prediction, and visual generation. Each of those is a research direction with its own methods, and the framework's job is to make a method in any of them callable the same way.

The mapping appears in the supported tasks table. Video Generation covers Navigation Generation, with methods including lingbot, matrix-game, hunyuan-worldplay and genie3; Long Video Generation, with sora-2, veo-3 and wan; and Egocentric Interaction Generation, with Hand2World. 3D Scene Generation lists flash-world and vggt. Reasoning covers VQA, the visual question answering task, with spatialVLM and omnivinci and other vision language models with world understanding, and VLA, the vision-language-action task, with pi-0, pi-0.5 and giga-brain.

So the taxonomy is by capability rather than by model family, and the two axes of the table are a task category and a sub-task, with representative methods named in the third column. That structure is how a caller finds a method: you know whether you want navigation generation or visual question answering, and the framework tells you which methods implement it.

The gallery in the project description lines up with that table, showing named systems including Matrix-Game-2, Hunyuan-GameCraft, Hunyuan-Worldplay, Lingbot-World, YUME-1.5, FlashWorld, Wan-2.2-IT2V, WoW, Cosmos-Predict-2.5 and Pi3, alongside the benchmark environments Libero and Ai2-THOR.

The package layout, and why there are five sets of extras

The project metadata is where the integration design becomes concrete, and the package itself is deliberately thin.

name = "openworldlib"
version = "0.1.0"
dynamic = ["dependencies"]

The dependencies are dynamic, taken from a requirements.txt file, and the optional dependencies are declared as named extras. There are five of them, and the names say what problem each solves.

transformers_low and transformers_high offer two ranges of the same stack, with the low set pinning transformers to 4.39.3 through 4.45.1 and diffusers to 0.31.0, and the high set allowing transformers from 4.49.0 to 4.57.3 with diffusers at 0.36.0. The 3d_ply_default extra matches the high transformers range and adds plyfile, which is the point cloud format used by the 3D scene generation work. The audio_default extra adds qwen_omni_utils and soundfile, and audio_generation_default pulls in a much heavier stack: lightning, prefigure, k_diffusion, a git dependency on descript-audio-codec, alias_free_torch, vector_quantize_pytorch, einops, google, protobuf, tiktoken and colorlog.

That last extra is where the project stops being a uniform framework and starts being a set of environments, because audio generation needs a vocoder, an audio codec and a training stack that the video models do not.

The base requirements file is a full research stack: opencv-python, diffusers, transformers, huggingface_hub with the CLI extra, tokenizers, accelerate, pandas, numpy, einops, tqdm, loguru, imageio with imageio-ffmpeg, safetensors, peft, deepspeed, pyarrow, tensorboard, xformer, qwen_vl_utils, dashscope, wandb, omegaconf, open_clip_torch, pycocotools, lmdb, sentencepiece, pydantic, scikit-image, modelscope, dominate, pycuda, flask with flask-socketio, gradio, Pillow, psutil, decord and librosa. Several of these are pinned exactly, including einops at 0.7.0, tqdm at 4.66.2, imageio at 2.34.0, deepspeed at 0.15.1, pyarrow at 14.0.1 and gradio at 4.14.0.

Exact pins across a stack this wide are what a framework does to keep a dozen upstream methods reproducible, and they are also what a user inherits when they install.

Getting started: the installation document and the extension repositories

The project documentation names four documents as essential to it, and the first of them is the installation guide.

docs/installation.md provides installation instructions for different methods in OpenWorldLib, which is the right place to start, because the choice of extra determines which models you can actually run. docs/planning.md tracks the short-term optimization goals and future development plans, and docs/awesome_world_models.md records recent research, related surveys, and open-source projects on world models. The fourth is the Development Guide, hosted outside GitHub, which provides a framework template for OpenWorldLib intended to serve as a reference for code integration for developers in the world model community.

The extension repositories are the other half of the contribution model. There is a separate repository for 3D generation, one for VLA and one for a simulator, each with its own maintainers. The core repository is the integration layer and the shared conventions, and a heavy domain lives in an extension that can be versioned on its own.

That arrangement is what makes the project plausible to attempt. Integrating a video diffusion model, a 3D reconstruction model and a robot policy into one repository would be an enormous amount of dependency management, and the extension split lets each area carry its own versions.

The examples directory shows what the integration looks like in practice, and the file names are informative: pipeline_load_mapping.py and pipeline_infer_mapping.py for loading and running a method, run_benchmark.py for evaluation, run_longlive_from_json.py and run_rolling_forcing_from_json.py for the long-running generation modes, json_chunk_utils.py for handling the chunked payloads, and an evaluation_tasks/ directory. The presence of a separate test_stream/ directory and a scripts/ directory alongside src/, data/ and tools/ suggests the project is designed to be driven from the command line over a stream rather than only from a notebook.

The documents that carry the project, and the paper behind it

Because the repository is mostly a framework and a bibliography, the documents are the product, and it is worth knowing which one to read for what.

The planning document is the closest thing to a roadmap, tracking short-term optimization goals and future development plans, so it tells you where the maintainers are pushing. The awesome list is the reference half, recording recent research, related surveys and open-source projects on world models, which is the artefact a newcomer reads first and the artefact that goes stale if nobody maintains it.

The development guide is the third pillar, and it is hosted on a Feishu wiki rather than in the repository. That choice has a consequence worth naming. A wiki behind a vendor account is easier to update than a repository document, and it avoids merge conflicts with the code, but it is also a document that can disappear with an account, and it is not versioned with the code it describes. For a project whose value is a set of integration conventions, that is a real fragility, and a fork or a mirror of the conventions in the repository would be more durable.

The project also has a paper, arXiv 2604.04707, and a WeChat contact is offered alongside the GitHub issue tracker, with a Chinese and an English README. The invitation in the documentation is to share views on the framework in the Issues section, to submit valuable world-model-related methods through pull requests, or to document and submit them to the awesome list, so the contribution paths are three and distinct: method code, method documentation, and discussion of the framework itself.

Licence, maintenance and where OpenWorldLib is the wrong tool

The licence is Apache-2.0, with the LICENSE file at the root of the repository, which is the permissive choice and the right one for a collection that repackages other people's research code.

The maintenance picture needs reading carefully. The repository is not archived and the last push was on 2026-09-23, so the work is happening. There are no GitHub releases, the package version is 0.1.0, and the dependencies are declared as dynamic and sourced from a requirements file with many exact pins. In practice that means the library version tells you almost nothing, and the pinned stack in the requirements file is the thing that determines whether a method still runs. The current pins for gradio, deepspeed, pyarrow and einops are from different years of the ecosystem, and a new release of any of them will not be picked up until the pins are deliberately moved.

That is the right trade for reproducibility of a benchmark, and the wrong trade for anything that needs current models. The extras exist partly to let a user pick a different range, which is the release valve.

Where OpenWorldLib is the wrong tool is easier to state. If you need a production inference service, this is a research collection with a 0.1.0 version and no release discipline. If you need one model rather than a taxonomy, the abstraction costs you an extra layer to work around. And if you need the result of a paper rather than the code, the awesome list and the paper are the artefacts, and the library is a convenience on top.

The judgement is that the value is in the conventions and the catalogue, not in the code. Before you adopt it, read the installation document and pick the extra that matches your task, then check whether the pinned dependency versions still install on your cluster, because a research collection that cannot resolve its environment is a collection you cannot run.

Editorial conclusion

Adopt OpenWorldLib if you are doing world model research and want to compare and reuse published methods through one set of conventions rather than a dozen separate repositories. Do not adopt it if you need a production inference service, since the package is version 0.1.0 with dynamic dependencies and no published releases. Before you build on it, read docs/installation.md, pick the extra that matches your task, and check the pinned versions in the requirements file, because the pins are exact for several packages and will not float with a new release.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. OpenDCAI/OpenWorldLib on GitHub
4. README