# GigaWorld-Policy: Action-Only Inference for Robot Control

> GigaWorld-Policy is a Python world-action model for robot policy learning that uses future visual dynamics during training but decodes actions alone during inference. The README documents an 85 ms result on a local RTX 4090 setup, training, open-loop inference, and a separate wam.cpp runtime.

**open-gigaai/giga-world-policy** — GigaWorld-Policy: An Efficient Action-Centered World–Action Model

- Repository: https://github.com/open-gigaai/giga-world-policy
- Stars: 1,411 · Forks: 108
- Language: Python
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-gigaai-giga-world-policy

## Why GigaWorld-Policy Removes Video Decoding from Robot Inference

GigaWorld-Policy targets a specific cost in world-action model inference. According to the README, existing WAM designs can explicitly generate future videos during inference. That adds computation even though a robot controller ultimately needs an action. GigaWorld-Policy uses an action-centered formulation instead: future visual dynamics help shape the policy during training, while the deployed path decodes actions only.

That distinction is relevant to developers working with robot datasets, post-training, and local inference rather than users seeking a general-purpose video generator. Its stated purpose is to retain dense supervision from future scene evolution without requiring future-video generation at every control request.

The README reports 85 ms inference latency for GigaWorld-Policy-0.5 on a local RTX 4090 setup. That is a project-specific reported result, not a hardware-independent guarantee. The README does not document CPU execution, memory consumption, precision settings, batch sizes, or behavior on other GPUs. Those omissions make hardware and model configuration part of any evaluation.

The repository also offers a GigaWorld-Policy-0 configuration and points to a C++/CUDA runtime through the separate wam.cpp repository. This is not one all-purpose checkpoint format. It presents a Python training and server/client implementation, an older policy configuration, and a route to a conversion and inference stack maintained elsewhere.

## Mixed AC-WM Training and Mixture-of-Transformers Inference

GigaWorld-Policy-0.5 uses future visual information during pretraining and fine-tuning, but changes what is active when actions are requested. According to the README, training combines Action-Conditioned World Modeling, abbreviated AC-WM, with WAM training. This is intended to strengthen the relationship between visual dynamics and robot actions so the resulting action representation transfers to downstream policy learning.

The inference side uses a Mixture-of-Transformers architecture with specialized experts for visual dynamics modeling and action generation. The README says this separation reduces active computation during action-only inference. It does not expose a detailed tensor graph, parameter count, expert-routing algorithm, or configuration reference for each expert. The supported description is therefore architectural: visual dynamics remain part of the training framework, while inference does not generate a future video.

The data path begins with a LeRobot v3.0 dataset. Before training, the repository requires normalization statistics and precomputed T5 text embeddings. The training command receives paths through environment variables, including the dataset, normalization file, WAN base model, T5 embedding directory, initialization checkpoint, and output directory. This keeps the shell interface explicit, but several external assets must be prepared before `scripts/train.py` can launch.

The architecture is a deliberate trade-off. Training consumes more information than an action-only policy because it also learns from future visual dynamics. Inference is designed to avoid paying for future video generation. Whether that balance suits a particular controller depends on the available training data, the importance of visual grounding, and whether the reported local hardware resembles the intended deployment machine.

## Python 3.11 and CUDA 12.6 Installation for GigaWorld-Policy-0.5

The README begins with a Conda environment and pins the core PyTorch packages to the CUDA 12.6 index. Run these commands from the repository root. Conda should create and activate an environment named `gigaworld-policy` using Python 3.11.

```bash
conda create -n gigaworld-policy python=3.11 -y
conda activate gigaworld-policy
```

Next, upgrade the packaging tools and install the PyTorch group documented by the project. The `--index-url` selects `download.pytorch.org/whl/cu126` for these packages.

```bash
python -m pip install --upgrade pip setuptools wheel
python -m pip install \
  torch==2.7.1 torchvision==0.22.1 torchaudio==2.7.1 \
  --index-url https://download.pytorch.org/whl/cu126
```

Install the project requirements and the three editable local packages included under `third_party/`. The `--no-deps` option prevents pip from resolving their dependencies again.

```bash
python -m pip install -r requirements.txt
python -m pip install --no-deps -e ./third_party/giga-train
python -m pip install --no-deps -e ./third_party/giga-models
python -m pip install --no-deps -e ./third_party/giga-datasets
```

The requirement file is tightly pinned rather than broadly versioned. It includes `deepspeed==0.17.4`, `diffusers==0.36.0`, `lerobot==0.4.4`, `transformers==4.54.1`, `xformers==0.0.31.post1`, and `torchao==0.14.1`. Expect compatibility work to center on Python 3.11, CUDA 12.6, the selected GPU driver, and these exact package versions. The repository license is listed as unknown, so reuse and distribution terms cannot be determined from this repository.

## Preparing LeRobot Data, T5 Embeddings, and Pretrained Weights

The first substantive task is data preparation. For the 0.5 model, compute normalization values with action dimension 32 and action horizon 48. Replace the two angle-bracket placeholders with the dataset root and output file chosen for the run.

```bash
python scripts/compute_wam_task_norm.py \
  --data-root <lerobot_v3_dataset_root> \
  --output <norm_stats_json> \
  --model-dim 32 \
  --action-horizon 48
```

The next script computes T5 embeddings and writes them under the `t5_embedding` folder associated with the dataset. Its documented invocation requests CUDA execution and identifies the WAN T5 model through `wan_path`.

```bash
python scripts/compute_t5_embedding.py \
  --root <lerobot_v3_dataset_root> \
  --wan_path <wan_t5_model_root> \
  --device cuda \
  --t5_folder_name t5_embedding
```

GigaWorld-Policy-0.5 weights are available through the Hugging Face model identifier `open-gigaai/Giga-World-Policy-0.5`. The README documents both the Hugging Face CLI and a Python download call. The Python option writes to `./Giga-World-Policy-0.5`.

```python
from huggingface_hub import snapshot_download

snapshot_download(
    repo_id="open-gigaai/Giga-World-Policy-0.5",
    local_dir="./Giga-World-Policy-0.5",
)
```

This setup is substantial. A LeRobot v3.0 dataset, a WAN T5 model root, a WAN diffusers model or path, and a GWP initialization checkpoint are separate inputs. The README does not document dataset schema validation, download sizes, storage requirements, or whether a user can train without the pretrained external models. Those points need verification against the user's data and hardware before committing storage or compute.

## Launching GigaWorld-Policy-0.5 Post-Training

Training is configured through environment variables and a named configuration file. The paths below are copied from the README's 0.5 workflow. `GWP05_TRANSFORMER_PRETRAINED` identifies the initialization checkpoint, while `GWP05_PROJECT_DIR` receives the output.

```bash
export GWP_AGILEX_DATA_PATHS=<lerobot_v3_dataset_root>
export GWP_NORM_STATS_PATH=<norm_stats_json>
export GWP_WAN_PRETRAINED=<wan_diffusers_model_or_path>
export GWP_T5_LOAD_FROM=dir
export GWP_T5_EMBEDDING_DIR=<lerobot_v3_dataset_root>/t5_embedding
export GWP05_TRANSFORMER_PRETRAINED=<gwp05_init_transformer_checkpoint>
export GWP05_PROJECT_DIR=<output_dir_for_gwp05>
```

With those values set, launch the AgileX fine-tuning configuration documented by the repository.

```bash
python scripts/train.py --config giga_world_policy_0_5_agilex_finetune
```

A separate `giga_world_policy_0_agilex_finetune` configuration is documented for GigaWorld-Policy-0. The configuration names indicate an AgileX fine-tuning path, but the README does not provide training duration, GPU count, batch size, checkpoint cadence, memory requirements, or recovery instructions. Those settings must be read from `configs/` and the relevant scripts rather than inferred from the short command.

Upgrade cost comes partly from fixed dependencies. A future Python, PyTorch, CUDA, `lerobot`, `transformers`, or `xformers` change is not automatically covered by the documentation. Maintain a long-lived training environment with the documented pins first, then test changes against the training and inference scripts. The README also describes an agent-based AutoResearch pipeline for searching training configurations, but it does not provide enough operational detail here to reproduce that search as a standalone workflow.

## Running the Documented Open-Loop Server and Client

The Python inference example is explicitly open-loop and uses two processes. First, export the trained checkpoint, normalization file, dataset path, and WAN base model in the shell that will start the runtime.

```bash
export CHECKPOINT=<trained_transformer_checkpoint>
export NORM_STATS=<norm_stats_json>
export DATA_PATH=<lerobot_v3_dataset_root>
export BASE_MODEL=<wan_diffusers_model_or_path>
```

For GigaWorld-Policy-0.5, open one terminal in `scripts` and start the server.

```bash
cd scripts
./run_inference_openloop.sh server
```

Open a second terminal, enter the same repository `scripts` directory, and start the client. The README says the client connects to the server, although it does not document the transport endpoint or client configuration.

```bash
cd scripts
./run_inference_openloop.sh client
```

GigaWorld-Policy-0 has separate launcher names, `run_inference_openloop_gwp0.sh`, with the same `server` and `client` arguments. This is an important boundary: the documented Python path is not a closed-loop controller, and the README does not show how predicted actions are sent back into a robot simulator or physical platform.

For local deployment work, the README points to `wam.cpp`. According to the README, it converts GigaWorld-Policy-0.5 checkpoints to GGUF, predicts actions through a pinned llama.cpp/ggml backend, and remains server-side compatible with this repository's open-loop client. Conversion is therefore part of the deployment path, not an optional detail. The README does not document the conversion command, so users must follow the wam.cpp repository for that procedure.

## Maintenance Signals, Limitations, and the wam.cpp Alternative

The repository is not archived, and its last push was on 2026-07-21. The release list contains `teaser (demo_video)` dated 2026-03-03, while the README identifies the paper as arXiv preprint `2607.13960`. The last-push date is the available maintenance signal; the release list does not provide a conventional sequence of versioned software releases. The repository includes `report-gigaworld-policy-0.5.pdf`, but its contents are not available for further claims.

GigaWorld-Policy is the wrong tool when the requirement is a fully documented closed-loop robot deployment, because the shown Python inference procedure is server/client and open-loop. It is also a poor fit for a minimal CPU-only installation, since the documented path calls for CUDA 12.6 PyTorch wheels, T5 preprocessing on CUDA, deep learning dependencies, and an RTX 4090 latency reference. The README does not promise support for macOS, Windows, or alternative GPU families.

The genuine alternative is wam.cpp, which changes the runtime path from the Python server/client implementation to a C++/CUDA stack using a pinned llama.cpp/ggml backend and GGUF checkpoint conversion. That can matter when local deployment and runtime format are the priority, but it adds a separate conversion and compatibility boundary. Developers should compare the Python path's direct use of repository checkpoints against wam.cpp's conversion workflow rather than treating them as interchangeable installations.

License status remains unresolved. The repository information says the license is unknown, and no license identifier is provided in the README information. Before incorporating code or weights into a product, verify the license for both the repository and each downloaded model separately.

## Conclusion

Adopt GigaWorld-Policy if the target is local robot-control inference with visual dynamics retained as a training signal and the RTX 4090, CUDA 12.6 package set, LeRobot v3.0 data, and pretrained WAN and GWP checkpoints are available. Do not choose it for closed-loop deployment without validating the documented open-loop path first, or for a lightweight environment that cannot accommodate the pinned deep learning stack. The first checks are checkpoint conversion for wam.cpp, compatibility between the dataset and task configuration, and reproduction of the repository's stated 85 ms result on the intended local hardware.

## FAQ

### How do I install GigaWorld-Policy for Python 3.11?

Create the documented Conda environment, install the CUDA 12.6 PyTorch packages, then install `requirements.txt` and the three editable packages under `third_party/`. The README specifies exact package versions, so start with those pins rather than substituting current releases.

### What files are needed before training GigaWorld-Policy-0.5?

The documented workflow requires a LeRobot v3.0 dataset, normalization statistics, a WAN diffusers model or path, T5 embeddings, and a GigaWorld-Policy-0.5 initialization checkpoint. The training command also requires an output directory through `GWP05_PROJECT_DIR`.

### Does GigaWorld-Policy support closed-loop robot inference?

The README documents open-loop inference through separate server and client commands. It does not document a closed-loop controller or explain how actions are returned to a robot, so closed-loop use needs separate verification.

## Sources

- [Issues](https://github.com/open-gigaai/giga-world-policy/issues)
- [open-gigaai/giga-world-policy on GitHub](https://github.com/open-gigaai/giga-world-policy)
- [README](https://github.com/open-gigaai/giga-world-policy/blob/main/README.md)
- [Releases](https://github.com/open-gigaai/giga-world-policy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-gigaai-giga-world-policy
