The repository ships checkpoint evaluation and one fixed simulation
Code-as-World's checkout exposes 2 model sizes and 1 fixed simulation. The evaluation module loads the released 4B or 9B video-language checkpoint, reads QuantiPhy questions from CSV, samples video frames, and writes predictions plus metric summaries. A separate simulation module replays a bundled ballistic-soccer scene in MuJoCo. Those pieces let a researcher inspect model answers and an executable physical representation without reconstructing every detail from the paper.
The exact snapshot assessed by our lab was commit 87d4159 in a 3-CPU, 8 GB unprivileged container. That commit is titled "Add standalone inference and simulation release," which is a useful description of the repository's practical boundary. The README discusses an agentic process that discovers states, dynamics, and mechanisms, while the downloadable code centers on checkpoint inference, QuantiPhy evaluation, and one already prepared scene. It does not expose a general video-to-simulator command.
The 4B and 9B checkpoints require CUDA and outside assets
The README requires Python 3.10 or 3.11 on a CUDA host before installation begins. The inference requirements pin Transformers 5.11.0, vLLM 0.19.1, qwen-vl-utils 0.0.14, and decord 0.6.0. Users then download either or both Code-as-World-VL checkpoints from Hugging Face. The evaluation is not self-contained because it also needs the QuantiPhy repository, its validation CSV, and a separate validation-video dataset.
The documented vLLM command configures a 4,608-token model length, 16 sampled video frames, and 90% GPU-memory utilization. Those settings are a starting recipe, not evidence that a particular GPU will fit the 4B or 9B model. Our 8 GB sandbox result cannot answer that hardware question because the lab never reached execution. Before adopting the project, verify weight size, supported CUDA stack, and memory use on the exact accelerator intended for evaluation.
What happened when we ran it
Our sandbox did not run Code-as-World. On 2026-08-30, the lab cloned commit 87d4159 into an unprivileged container with 3 CPUs and 8 GB of RAM, then classified the Python repository as having no supported ecosystem in the harness. The checkout also had no Dockerfile. As a result, the measurement contains no install duration, package count, build result, test result, or failure log.
The absence of a run is the finding. The recorded image was n/a, and the container had no secrets. We cannot say that the README installation works, that the two requirement sets resolve together, or that the Python modules pass tests. We also cannot call any step failed because no supported step started. For commit 87d4159, the honest lab result is an execution gap rather than a disguised pass.
MuJoCo 3.3 replays a prepared ballistic-soccer scene
The simulation requirements accept MuJoCo 3.3 through the current major line, NumPy 1.26 or newer, and imageio with FFmpeg support. Running the module loads the checked-in ballistic-soccer JSON and XML, initializes object states, applies recorded forces and contact events, and writes a rendered video plus trajectory data. A no-render flag keeps the trajectory path available when a display backend is inconvenient.
That example is valuable because the physical representation can be inspected as data rather than watched only as a generated clip. It is still one prepared case. The August 30 lab snapshot at commit 87d4159 gives no evidence that users can feed in a different video and receive a new scene automatically. Anyone extending it must understand the scene schema, object states, coordinate conversion, and event handling visible in the Python source.
Four days of activity cannot establish maintenance history
GitHub showed 276 stars and 1 open issue or pull request when we fetched the repository on August 31, 2026. The project was created on August 27 and last pushed on August 31. GitHub's latest-release API returned 404, so there was no versioned release to compare with the active branch. The Apache-2.0 license is clear, but the project's age leaves little evidence about upgrade policy or response to bug reports.
The only issue was active on August 31 and concerned a Hugging Face demo, not a defect. A Hugging Face team member transferred the working Space to the MirroS-Lab organization after the maintainer accepted it. That is useful early activity, yet it says nothing about how a 3-CPU, 8 GB development setup, CUDA incompatibility, or model regression will be handled. Recheck issue traffic after users have tried the released checkpoints outside the authors' environment.
The released research artifact still needs production packaging
Code-as-World releases 2 model sizes alongside the QuantiPhy runner, raw-output files, and MuJoCo case. That is enough material for researchers to inspect the claim and compare behavior. The repository is less convincing as an application dependency because it has no versioned release, general discovery command, container path, or lab-verified execution result.
Teams with CUDA hardware and a QuantiPhy comparison in mind have a specific reason to try it now. If your starting point resembles our unprivileged 3-CPU, 8 GB sandbox, the repository offers no verified route from clone to result in our lab. Treat commit 87d4159 as a research snapshot, pin every external asset, and require your own installation and regression checks before building a service around it.