X-VLA: a cross-embodiment vision-language-action model built on soft prompts

One backbone, many robot bodies, and the soft prompt in between

The problem X-VLA addresses is stated at the top of the readme. Successful generalist Vision-Language-Action models depend on scalable, cross-platform training across diverse robotic embodiments, and the difficulty is the heterogeneity of large-scale robot datasets.

The mechanism the project introduces is a soft prompt, described as embodiment-specific learnable embeddings that guide a unified Transformer backbone toward effective multi-domain policy learning. The idea is that instead of building a separate policy per robot, or forcing one tokenisation to cover every embodiment, each body gets a small set of learned embeddings that tells the shared backbone how to interpret what it is seeing.

That is the whole architectural claim, and it is a modest, tractable one. It says the backbone can stay fixed and the embodiment-specific part can be small and learned, which is what makes a single checkpoint set usable across bodies.

The resulting model is X-VLA-0.9B, and the readme claims it achieves state-of-the-art generalization across six simulation platforms and three real-world robots, surpassing prior VLA approaches in dexterity, adaptability and efficiency. The repository description identifies it as the official implementation of the paper Soft-Prompted Transformer as Scalable Cross-Embodiment Vision-Language-Action Model, with the full research on arXiv as 2510.10274, and a project page with demos at thu-air-dream.github.io/X-VLA.

The server and client split that keeps simulator dependencies out

For deployment, X-VLA adopts a Server-Client architecture in order to separate the model environment from simulation or robot-specific dependencies. The stated reason is that this design avoids package conflicts, and it supports distributed inference across GPUs, SLURM clusters, or edge devices.

That separation is the practical decision most users will feel first. A simulation like LIBERO or CALVIN pulls in its own version of a dozen libraries, and a robot SDK pulls in another set, and neither has any interest in matching the versions the model wants. Splitting the process means the model environment can be pinned once and the client can be rebuilt for each environment.

The repository layout matches. There is a deploy.py at the top level next to train.py and peft_train.py, and separate directories for models/, datasets/, evaluation/ and the top-level configuration files. The requirements.txt pins the server side dependencies tightly, including uvicorn at 0.34.3, peft at 0.17.1, numpy at 1.26.3, transformers at 4.51.3 or lower, and av, json_numpy, safetensors, scipy, einops, timm, mmengine, pyarrow, h5py, accelerate and mediapy.

The presence of uvicorn and fastapi in that list is the visible sign of the server side, and it is why the pinning is so strict. The server is a long-lived process that has to keep working, so its environment is frozen rather than resolved.

Getting the code and the environment in place

The installation path is a clone and a conda environment. First the repository:

# Clone the repository
git clone https://github.com/2toinf/X-VLA.git
cd X-VLA

Then either a hand-built environment:

# Create and activate Conda environment
conda create -n XVLA python=3.10 -y
conda activate XVLA

# Install dependencies
pip install -r requirements.txt

Or the provided environment file, which is the reproducible route:

conda env create -f environment.yml
conda activate xvla-stable

The Python version is 3.10 in both cases, which matters more than usual here because of the pins in requirements.txt, and the environment file names a different environment, xvla-stable, from the manually created one, XVLA.

The readme also records that X-VLA is now natively integrated into the LeRobot platform from Hugging Face, which is the more convenient path for anyone already in that ecosystem, since the weights and the training recipe are then consumed by an existing harness rather than by this repository's scripts.

The checkpoint table, and which numbers belong to which body

The model table is the most useful part of the readme, and it is a per-embodiment map rather than a single score. Each row names a model id on Hugging Face, the embodiment it targets, what it was trained on, a performance figure, and a link to the evaluation guidance for that benchmark.

The foundation model, 2toINF/X-VLA-Pt, is pretrained on large-scale heterogeneous robot, vision and language datasets for general transfer, and has no performance figure attached. The task specific checkpoints are fine-tunes of it: X-VLA-AgiWorld-Challenge for the AgiBot-G1 embodiment, which won Champion at the AgiBot World Challenge at IROS 2025, X-VLA-Calvin-ABC_D for the Franka embodiment with a score of 4.43 on the CALVIN ABC_D subset, X-VLA-Google-Robot with 83.5 percent on VM and 76.4 percent on VA, X-VLA-Libero at 98.1 percent, X-VLA-VLABench at 51.1 score, X-VLA-RoboTwin2 for Agilex dual-arm manipulation at 70 percent with 50 demos for each task, and X-VLA-WidowX at 95.8 percent.

There is also a distinct task, deformable object manipulation. X-VLA-SoftFold, on the Agilex embodiment, is fine-tuned on the Soft-Fold dataset and specialises in cloth folding and control, with a stated 100 percent success rate in 2 hours.

Below the full fine-tunes sit LoRA adapters, released along with the fine-tuning code, checkpoints and inference code. The four LIBERO adapters show how the same base model behaves under different task suites: libero-spatial-peft at 96.2 percent, libero-object-peft at 96 percent, libero-goal-peft at 94.4 percent, and libero-long-peft, whose row is cut off in the readme.

The Hugging Face conversion caveat and the relative action problem

Two warnings in the readme deserve to be read before anyone plans an evaluation.

The first is an unchecked box in the pre-trained models section: the project observed a slight performance drop, around one percent across different datasets, after converting the models to the HF format, and they are actively investigating the cause. That is a small number in isolation, but it applies to every number in the table above, since the table is distributed through Hugging Face.

The second is about action representation, and it is specific to the LIBERO evaluation. For questions about converting relative actions to absolute actions and about the implementation, the readme asks you to refer first to issues #2 and #15, and it points to full preprocessing guidance at evaluation/libero/preprocess.md.

That request to read the issues first is a good signal about the project. Getting a VLA evaluation wrong is usually a data pipeline problem rather than a model problem, and a project that routes you to a specific issue and a preprocessing document before you evaluate is one that has been through a few rounds of this.

The evaluation/ directory mirrors the model table, with a README per benchmark, for calvin, simpler, libero, vlabench, robotwin-2.0 and SoftFold-Agilex. That mapping between checkpoint and evaluation directory is the thing to check before running anything, because the LoRA adapters in particular are benchmark specific.

Fine-tuning code, project status and what the repository does not cover

The training side is three files at the top level, train.py, peft_train.py and deploy.py, with a datasets/ directory, and the LoRA fine-tuning code, checkpoints and associated inference code have all been released.

The project status is strong on paper credentials. X-VLA was accepted to ICLR 2026, and it won first place as Champion at the AgiBot World Challenge at IROS 2025. The primary language field in the repository metadata says C++, though the visible code and configuration are Python, so that entry reflects the native components rather than the scripting layer.

What the repository does not include is the training data itself in a form you can point at. The datasets/ directory exists, but the readme directs users to the Hugging Face collection for models and datasets, and the checkpoints are all pre-trained. The base model X-VLA-Pt is described as pretrained on large-scale heterogeneous robot, vision and language datasets, and the project does not publish the full pretraining corpus or a script to rebuild it.

There is also no GitHub release for the project, so versioning rests on the Hugging Face model ids and the paper. The last push was on 2026-10-20, so the code is being actively changed, and the licence is Apache-2.0.

Editorial conclusion

Adopt X-VLA if your lab works on robot manipulation and wants a single pretrained backbone that transfers across embodiments, because the soft prompt mechanism is what makes one model serve Franka, Agilex, WidowX and Google Robot bodies, and the repository publishes per-embodiment checkpoints rather than asking you to train from scratch. Do not adopt it expecting the released Hugging Face weights to match the paper numbers exactly, since the project states it observed a slight performance drop of around one percent after converting the models to the HF format and is still investigating the cause. Before you evaluate, read the Libero preprocessing guidance linked from the readme, because the project routes relative-to-absolute action conversion questions to specific issues first, and check that the simulator or robot stack you intend to run matches the evaluation directory for that benchmark.

Frequently asked questions

Official sources

1. 2toinf/X-VLA on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README