Code World Model: a 32B open-weights LLM built to reason about program state

CWM is trained to model what a command does to program state

Code World Model is a 32-billion-parameter open-weights language model, and the design goal is narrower than general code generation. The model was mid-trained on observation-action trajectories taken from Python execution traces and from agentic interactions inside containerized environments, which gives it a bias toward representing how code and shell commands change the state of a running system. Post-training added multi-task reinforcement learning in verifiable coding, math and multi-turn software engineering environments. The README points at the accompanying technical report and a separate model card for the full description of uses, risks and limitations. For an engineer, the practical read is that CWM is positioned as a research platform for code and command reasoning rather than a finished assistant, and the repository ships the three artefacts you would need to test that claim for yourself: model weights, the technical report, and starting code to run inference and to reproduce reported numbers on SWE-bench Verified, LiveCodeBench, AIME and MATH.

Three checkpoints split by training stage, three separate download paths

The release publishes weights in three training stages, and the choice between them is the first decision you make. On Hugging Face there is `cwm` for the instruction-tuned model, `cwm-sft` for the supervised fine-tuned stage, and `cwm-pretrain` for the pre-trained checkpoint, and the documentation states the weights are there for use with vLLM. A second distribution channel exists for developers who want to work with the released code directly: PyTorch checkpoints in PyTorch Distributed Checkpoint format, or DCP. Getting the Hugging Face weights is a manual step rather than a script. You visit the repository, read and accept the licence, and once the request is approved you are granted access to all CWM model weights. The documentation is candid that requests used to take up to one hour to be processed, which is a long wait to discover that the hardware plan does not work.

The DCP download script depends on a signed URL that can expire

The PyTorch path works differently, and it is the one to read carefully. Approval is followed by the arrival of a signed URL over email, and that URL is the only credential the download script needs. The links may expire after twenty-four hours or after a fixed number of downloads, so a URL that worked this morning can fail this afternoon, and the documentation tells you to re-request when you see errors such as `403: Forbidden`. The command itself is short, and the whole retrieval step comes down to a single invocation with the URL pasted in:

./download_pytorch.sh <URL>

You should end up with the distributed checkpoint files written locally, ready for the serving code to load. Treat the signed link as a consumable rather than a bookmark. If you are scripting this, you need a path that re-requests the link on failure instead of assuming a stored address stays valid, because the failure mode looks identical to an access problem even when it is only expiry.

Environment setup assumes a multi-GPU machine with RDMA networking

The repository is a Python project with pinned dependencies, and the environment file is the documented way in. The setup command creates a named environment from the checked-in `environment.yaml`, and the documentation notes that a recent micromamba, version 2.2.0 or later, is needed for the environment variables to be set correctly:

micromamba env create -f environment.yaml -n CWM

After that completes you should have an environment named CWM with the pinned stack, including a fixed torch build and its matching attention package, plus evaluation-side libraries such as `swebench` and `modal` and serving libraries `flask` and `openai`. The hardware expectation is stated just as plainly: 160GB of combined GPU VRAM, for example two Nvidia H100 GPUs, plus RDMA with either Mellanox 5 InfiniBand or AWS EFA, is required to run evaluations and demos in their default configurations. That is the cost of a default run, not an optional extra. The requirements file also pins the serving stack exactly rather than tracking a version range.

A dedicated system prompt is treated as a hard requirement

The most surprising line in the setup notes is the short important callout about model use. The documentation states that CWM requires a dedicated system prompt to function optimally during inference, and that without proper prompt configuration the output quality may be significantly degraded. This is not a tuning suggestion but a precondition, and it lands on the person who wants a quick demo: you cannot just point any chat template at the weights and read the result as representative. The repository keeps `PROMPTING_GUIDE.md` and `MODEL_CARD.md` at the top level, so the prompt guidance is in the tree rather than hidden in a wiki. If you are evaluating whether the model is useful for your task, the prompt has to be part of the test harness, and a run without one measures the wrong thing.

Serving, evaluation and demos live in three separate subtrees

The repository layout splits the work by purpose, and the top-level entries make the division visible: a `cwm/` package, a `serve/` directory, an `evals/` directory and a `demos/` directory, each with its own README. The reference implementation is described as a simple serving endpoint that runs inference locally from the PyTorch DCP weights using a Fastgen server, and `serve/README.md` is the starting point. Evaluation work is kept apart too, with the main logic for the agentic and reasoning results in `evals/`, and the documentation points you at that README for reproduction instructions rather than trying to fold the scripts into one entry point. The `demos/` tree is where the project makes a distinct claim: with them you can use CWM as a neural debugger, which is a different product story from the benchmark numbers and is worth trying before you decide what the model is for.

The licence split between code and weights decides where you can go

The licence arrangement is two-tiered, and the repository's own description says so plainly. The code in this repository is released under a BSD-3 licence as found in the LICENSE file, while the model weights are released under a custom licence published on the CWM License page. The licence field on the repository says Other and points at a LICENSE file, which is the classification GitHub applies to a custom licence it cannot label. Practically, this means the inference, evaluation and demo code carries a familiar permissive licence, but using the weights is a separate agreement with its own terms, and the model card is where the weights licence details, along with uses, risks and limitations, are described. Read that page and accept it before the approval request, since the access request and the licence acceptance are the same step. The code licence also does not extend to the checkpoints you fetch from either distribution channel.

A research snapshot with no tagged releases and a fixed dependency set

The repository has no GitHub releases, so there is no version stream to upgrade along, and the project itself is versioned as `cwm` 0.0.1 in `pyproject.toml`, which is the naming a research codebase gets rather than a released library. The dependency list is exact rather than ranged, with `torch==2.7.1`, `xformers==0.0.31.post1`, `flask==3.1.1` and `openai==1.86.0` all pinned, plus one dependency installed straight from a git commit hash of omegaconf to enable a recent antlr version. Those pins mean an upgrade is a patching job, not a pull. The last push was on 2026-07-17, and the README carries a citation block naming the FAIR CodeGen team at Meta with a 2025 year, so the published artifacts carry a fixed version of the research while the code moves on separately.

Editorial conclusion

Adopt CWM if your team is doing research on code generation, program state reasoning, or agentic software engineering and has multi-GPU hardware and time to spend on licence approval, prompt configuration and dataset preparation. Do not adopt it as a general chat model, as a drop-in replacement for a hosted API, or as a component with a predictable upgrade path. Before anything else, verify that your hardware reaches the 160GB of combined VRAM and RDMA networking the default evaluation and demo configurations expect, that you have a dedicated system prompt ready, and that the custom weights licence covers the use you intend.

Frequently asked questions

Official sources

1. facebookresearch/cwm on GitHub
2. Issues
3. README