buaacyw/code-world-model: what the CWM inference repo actually ships

What Code World Model is, and what this repository actually contains

The README titles the project "Code World Model: Coding Agent as World Brain" and credits authors from AGI Lab at Westlake University and Nanyang Technological University, with links to a project page and an arXiv entry. That is the research framing. The code in this repository is narrower than the name suggests. The package is called cwm-minimax-h3-inference, version 0.1.0, and its description reads "MiniMax H3 Ref2VA inference with a fixed first frame and Retake34 continuation". So the shipped artifact is an inference harness for one released LoRA checkpoint, not a general world-model framework and not a training codebase.

That distinction matters when you decide whether to clone it. If you arrived from searches about code world models in general, or from the Meta and DeepMind material that uses similar phrasing, this repository is not that. It is the official release repository for one specific model configuration, and its job is to let someone else reproduce the published outputs from fixed inputs. The README is explicit that a released configuration should be run "without changing its inputs, prompts, or seed".

The intended audience is therefore small: researchers who want to inspect or extend the inference pipeline, and engineers evaluating whether the released LoRA behaves as described. Nothing in the repository targets production deployment.

The three-stage pipeline: validate, prepare, generate

The mechanism visible in the README is a three-command pipeline driven by a JSON config. Validate checks the configuration. Prepare does the expensive setup work, including loading the model and LoRA and building caches. Generate produces the output. Each stage reads the same config file, and the README's instruction to use "a new cache directory and output path for every changed experiment" tells you that caches are keyed to the config rather than regenerated automatically.

The config examples live at examples/config.example.json and examples/config.multiwindow.example.json, and the released configs live under examples/example_01 through the expanded set. The repository layout also shows a patches/ directory and a pinned requirements-h800-cu128-py310.txt, which is the clearest signal of the target hardware: an H800 GPU with CUDA 12.8 and Python 3.10. The package itself declares requires-python >=3.10,<3.13, so 3.13 is out.

The format expansion is the part that catches people. The README states that the Hugging Face examples "contain compact NPZ conditions, not caches or output videos; the installation script performs the required local format expansion." So the download is not directly runnable. You need the install script to turn the compact conditions into whatever the prepare stage expects. Skipping that step and pointing a config at the raw download will not work.

Runtime dependencies are deliberately small: av, numpy, pillow and safetensors. The heavy machinery, including the model itself, comes from the download script and the environment guide rather than from PyPI.

Installing the release assets and running example_01

The README points at ENVIRONMENT.md for the environment and installation guide, and that file is where the actual CUDA, driver and model setup lives. What the README itself gives is the asset step. Run this from the repository root, and note the quoted argument: the script takes the target directory for the expanded release, not a flag.

./scripts/install_release_assets.sh "$PWD/release"

That single command downloads the public CWM LoRA from the NTU-yiwen Hugging Face repository and deterministically expands the 40 compact examples from the NTU-yiwen dataset. Expect a release directory containing an examples/ tree plus the model and LoRA assets.

From there you enter the prepared directory and run one configuration through all three stages. The README uses example_01 as the reference case.

cd release
CONFIG=examples/example_01/config.json
python -m cwm_h3_inference validate --config "$CONFIG"
CUDA_VISIBLE_DEVICES=0 python -m cwm_h3_inference prepare --config "$CONFIG"
CUDA_VISIBLE_DEVICES=0 python -m cwm_h3_inference generate --config "$CONFIG"

The validate stage should pass without touching the GPU. Prepare and generate are the CUDA-bound stages, which is why the README pins CUDA_VISIBLE_DEVICES=0 on both. The package also installs a console script named cwm-h3-inference, so the same subcommands are reachable as cwm-h3-inference validate --config ... if you install the wheel rather than running from the source tree. Run one example end to end before changing anything, because the README's warning about fresh cache directories applies the moment you edit a config.

The frozen-input constraint is a real limitation, not a suggestion

The README asks you to run a released configuration "without changing its inputs, prompts, or seed". Read that as a statement about what the release can support. The 40 examples are fixed, the LoRA is a single published checkpoint, and the pipeline is built around reproducing those outputs. There is no documented path for swapping in your own prompt and expecting a meaningful result, and no evaluation harness for judging outputs you generate yourself.

The cache design reinforces this. Because each changed experiment needs a new cache directory and output path, iterating on a configuration means paying the prepare cost again. On an H800 that may be tolerable. On smaller hardware it is the difference between a quick loop and an overnight job, and the repository gives no guidance on what the minimum viable GPU is.

The packaging also tells a story. The classifier is Development Status :: 2 - Pre-Alpha, and the supported operating system is listed as POSIX Linux only. There is no Windows or macOS claim, no Dockerfile in the top-level entries, and no server or API entry point in pyproject.toml. If your plan is to wrap this in a service, you are writing that layer yourself, and the pre-alpha status means the internal structure it would depend on can move.

Finally, the README does not document rollback, checkpoint resumption, or what happens when prepare fails partway through. Treat long runs as all-or-nothing until you have read INFERENCE.md.

How this differs from a general video or world-model toolkit

The obvious comparison is with general-purpose generative video and world-model toolkits that accept arbitrary prompts through a stable interface. The difference here is the opposite of flexibility: this repository fixes the first frame and uses a Retake34 continuation scheme, per the package description, and it ships exactly one LoRA. A general toolkit optimizes for breadth of inputs and lets you trade determinism for variety. This one optimizes for determinism and gives up breadth.

That makes the choice straightforward. If you want to generate video from your own prompts, a general toolkit is the better fit and this repository will frustrate you. If you want to check whether the released CWM LoRA reproduces the published examples on your hardware, a general toolkit cannot answer that question at all, because the checkpoint and the exact configuration are the point.

A second comparison is with the model repositories that host the weights. Hugging Face gives you the LoRA and the compact NPZ conditions, but the README is clear that those conditions are not runnable as-is. The value this repository adds is the expansion step and the three-stage runner around them. Downloading the weights alone gets you assets without a pipeline.

Licence, third-party notices and upgrade cost

The project is Apache-2.0, and pyproject.toml declares license-files covering LICENSE, NOTICE and THIRD_PARTY_NOTICES.md. All three ship in the source distribution. If you redistribute the package or a derivative, those files travel with it, and THIRD_PARTY_NOTICES.md is where the bundled or downloaded components are attributed. The LoRA and the example dataset are hosted separately on Hugging Face, so their terms are not necessarily the same as the Apache-2.0 licence on this code. Check the model and dataset cards before you redistribute weights or examples. This is a description of what the repository states, not legal advice.

Upgrade cost is currently low but not zero. There are no retrieved releases, so there is no changelog to follow and no versioned migration path. The version is 0.1.0. The last push to main was on 2026-08-27, which is recent enough that the code is moving, but a pre-alpha package with no releases means you should pin the commit you validated rather than tracking main. The pinned requirements-h800-cu128-py310.txt is your best anchor for a reproducible environment; deviating from it moves you outside what the README documents.

Editorial conclusion

Adopt it if you want to reproduce the released CWM LoRA outputs on the 40 published examples and inspect the pipeline stage by stage, and you have a Linux CUDA machine with the H800-era environment from ENVIRONMENT.md. Do not adopt it if you need to train a world model, serve an API, or run on macOS or Windows, since pyproject.toml classifies the package as POSIX Linux only and declares no server entry point. Verify first that the install_release_assets.sh script can reach both Hugging Face repositories from your network, and that you can reproduce example_01 end to end before touching any other config.

Frequently asked questions

Official sources

1. buaacyw/code-world-model on GitHub
2. Issues
3. License: Apache-2.0
4. README