PRTS: a contrastive value head trained inside a VLA backbone

What the contrastive value head adds to behaviour cloning

PRTS stands for Primitive Reasoning and Tasking System, and the project describes itself as the official implementation of a Vision-Language-Action foundation model that scales reward-label-free contrastive RL into VLA pre-training itself.

The problem it attacks is stated in the readme with unusual bluntness. Most VLA models pretrain by behaviour cloning. They learn what to do, but never internalise how close the current state is to satisfying the instruction. PRTS reframes pre-training as a goal-conditioned RL problem and supervises a language-conditioned contrastive value alongside the action loss, using only the temporal structure of offline trajectory data.

That last clause is the important one. There are no per-episode success labels and no curated value-training corpus. The supervision comes purely from the ordering of demonstrations, which is what makes it reward-label-free.

The geometry the model is supposed to converge to is given as an equation: the inner product of the state-action embedding and the goal embedding tracks the log-discounted goal-occupancy along expert rollouts. It rises as the policy approaches the language goal and stays flat under a mismatched instruction. The readme backs this with a concrete example on a held-out Pick Shoes rollout: with the correct instruction the value climbs to 0.57 over the episode with local peaks at each subgoal, and with a wrong instruction naming objects absent from the scene the score stays between 0.04 and 0.20 and never crosses the correct curve. The readme states that the signal is computed by the pre-trained checkpoint without any post-training adaptation.

The value head is co-trained inside the same Qwen3-VL backbone the policy uses. There is no separate value network, no offline-RL post-training loop, and no reward dataset to obtain.

The release plan, and the part that is still behind a curtain

The readme carries an explicit checklist of what has been open-sourced, and reading it is the fastest way to understand the state of the project.

Done: the arXiv preprint at arXiv:2604.27472, the pre-trained PRTS-4B checkpoint on Hugging Face as TeleEmbodied/PRTS-4B, a standard LIBERO LeRobot-v2.1 dataset for example fine-tuning as TeleEmbodied/libero_4_suites, the minimal SFT post-training code for LIBERO and real-robot platforms, the LIBERO evaluation, a project page with video demos and benchmark cards, and a post-trained LIBERO checkpoint as TeleEmbodied/PRTS-4B-LIBERO for one-click reproduction of the paper's LIBERO numbers.

Still to come: CRL value visualization scripts, and a post-trained checkpoint for SimplerEnv WidowX.

And two entries are commented out in the readme rather than left unchecked. One covers post-trained checkpoints for the RealMan dual-arm and Flexiv single-arm real-robot suites. The other is the one that matters most for an evaluator: pre-training code, described as the CRL data pipeline plus a role-aware CuTe-FlashAttention kernel, marked as gated on internal review.

So the public repository is the post-training and evaluation half of the system, not the pre-training half. A team that wants to retrain PRTS-4B from scratch with the contrastive objective cannot, because the objective's data pipeline and its custom attention kernel are not in the tree. A team that wants to fine-tune the released checkpoint and evaluate it can.

The naming convention in the repository listing matches that split. There is a prts/ package, a configs/ directory, an examples/ directory with a libero/ subdirectory, a scripts/ directory that contains the fine-tuning launchers including scripts/ft/launch_finetune_droid.sh, and a third_party/ directory holding local editable dependencies.

Setting up the environment for fine-tuning

The documented setup is explicit about versions, which is what you want in a repository where the training kernel is version-sensitive.

The stated targets are CUDA 12.6, PyTorch 2.11 and transformers 4.57.3, and a fresh conda environment on Python 3.11 is recommended. The clone and environment steps are:

# 1) Clone
git clone https://github.com/TeleHuman/PRTS.git
cd PRTS

conda create -n prts python=3.11 -y
conda activate prts
pip install lerobot==0.3.3
pip install -r requirements.txt
MAX_JOBS=8 pip install flash-attn==2.8.3 --no-build

The ordering matters and the readme says so. LeRobot is installed first, then the rest of the requirements, and FlashAttention last with MAX_JOBS=8 to cap the parallelism of the build. The readme notes that FlashAttention-3 is the default attention implementation in the training, passed as `--attn-implementation flash_attention_3`.

The requirements file pins the numeric stack hard: torch 2.11.0, torchvision 0.26.0, torchcodec 0.11.0, transformers 4.57.3, accelerate, and then the training and optimisation group with deepspeed, wandb 0.15.0 or newer, tensorboard and tqdm. The data and utility group adds pyyaml, qwen-vl-utils 0.0.14, numba 0.63.1, scipy 1.17.0, numpydantic 1.7.0, pandas 3.0.0, tyro 1.0.9, ujson and colorlog. The last line is a local editable dependency on ./third_party/openpi-client, which is a client library for the OpenPI robot platform and is a hint about which hardware the fine-tuning path expects.

The requirements file also carries commented guidance about CUDA 12.6 wheels for torch and torchvision with an extra-index-url so that PyPI stays the default index for transformers and the rest.

The setup.py declares the package as PRTS at version 0.1.0 with a Development Status of 3 - Alpha, and it deliberately leaves install_requires commented out, because the requirements file is the source of truth for the pinned environment.

What the efficiency claims actually cover

The readme makes three quantitative claims, and they are worth separating because they describe different things.

The first is about attention cost. A role-aware causal mask is fused into FlashAttention through a custom CuTe kernel, which the readme says keeps per-layer attention within 1.18 times that of vanilla FA3, against a range of 2.7 to 8.8 times for off-the-shelf FlexAttention. That is a kernel-level comparison, and it is the piece of engineering the commented-out pre-training entry refers to as the role-aware CuTe-FlashAttention kernel.

The second is about scaling. End-to-end pre-training scales at 85 percent linear efficiency or better on 64 H100s.

The third is about downstream quality. On five simulation suites and 14 real-world tasks, the readme says PRTS matches or exceeds the strongest prior VLAs at a quarter to an eighth of the post-training compute, and that the gap widens as evaluation moves further off-distribution, citing novel-instruction following at +38.8 over the pi-0.5 model, long-horizon execution, and recovery under human intervention.

None of these numbers are reproduced by the repository itself, and the readme does not present a script that regenerates them. What it does provide is the leaderboard position and the launcher that produced one of them. The MolmoSpaces leaderboard result is dated 2026/06, where PRTS-Droid ranks third with a 42.4 percent success rate, ahead of NVIDIA's DreamZero at 40.7, MolmoAct2 at 38.6 and pi-0.5, with the top five shared with X Square Robot, PsiBot, NVIDIA GEAR and AI2. The readme is explicit about the provenance of that checkpoint: it is trained with the DROID fine-tuning launcher at scripts/ft/launch_finetune_droid.sh.

So the honest reading is that the efficiency claims come from the paper and the leaderboard, and the repository gives you the means to reproduce the post-training side of one of them, the DROID launcher, plus the LIBERO checkpoint for one-click reproduction of the LIBERO numbers.

Where PRTS is the wrong tool

The first limitation is the missing half. The public code is the SFT and evaluation half. Pre-training code is described as gated on internal review, and the CRL value visualization scripts are listed as still to come, which means the central claim of the paper cannot be reproduced from this repository. For a paper whose contribution is a new pre-training objective, that is the decisive point for anyone whose interest is in the method rather than in the checkpoint.

The second is the hardware and software floor. CUDA 12.6, PyTorch 2.11, transformers 4.57.3, LeRobot 0.3.3, a FlashAttention build and 64 H100s for the scaling figure: this is a research-scale setup, and the readme's own efficiency numbers are measured on that hardware. A team without that class of machine can fine-tune and evaluate, but cannot reproduce the pre-training claims, and should treat the performance numbers as reported rather than as something they can check.

The third is the licence ambiguity, which is unusual enough to check before you build on it. The badge in the readme says CC BY-NC 4.0, which is a non-commercial licence, and the licence field on the repository is one GitHub cannot classify. The setup.py, by contrast, carries the classifier License :: OSI Approved :: MIT License, and the source file does not say otherwise. A research artefact released under a non-commercial licence and packaged under MIT classification are two different sets of obligations, and the LICENSE file at the root is the document that settles it. For a commercial robotics company considering the code, that file needs reading first.

The fourth is the state of the checkpoint line. The package version in setup.py is 0.1.0 with a Development Status of 3 - Alpha, the repository publishes no GitHub releases, and the last push was on 2026-08-19. There is also a commented-out set of real-robot checkpoints for RealMan dual-arm and Flexiv single-arm suites, which means the hardware coverage of the released artefacts is narrower than the 14 real-world tasks the readme claims to evaluate on.

The fifth is the practical weight of the dependency on LeRobot and OpenPI. Installing LeRobot 0.3.3 first is a strong hint about the expected fine-tuning harness, and the editable dependency on ./third_party/openpi-client narrows the robot platform support further. A team whose data pipeline is built on something else will spend the integration effort there rather than on the model.

Editorial conclusion

PRTS fits a robotics research group that wants to reproduce or build on reward-label-free contrastive pre-training for a Vision-Language-Action policy, since the arXiv preprint, the pre-trained PRTS-4B checkpoint, the LIBERO dataset, the post-training code and the evaluation harness are all published, and the DROID fine-tuning launcher points at the checkpoint behind the MolmoSpaces result. It is the wrong choice if you need the pre-training pipeline itself, because that part of the stack is listed as upcoming and gated on internal review, and it is the wrong choice without NVIDIA GPUs given the CUDA 12.6, FlashAttention-3 and 64 by H100 requirements. Before adopting it, check the LICENSE file, because the badge says CC BY-NC 4.0 while the setup metadata claims MIT, and note that the last push was on 2026-08-19 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. README
3. TeleHuman/PRTS on GitHub