Introducing V0.5

Today, we are releasing Verne V0.5, an open-weight world action model built to accelerate the deployment of general-purpose robots in industrial settings. On the LIBERO and RoboTwin 2.0 benchmarks, V0.5 is the leading open-weight model developed by a US company at the time of publication. We are opening its weights because we believe the future of robotics is in post-training and deployment, where a capable model learns a real job in a real facility. A company that puts general-purpose robots to work should be able to build on an open, shared model and adapt it on its own terms. We want the US to have a strong one.

Verne deploys robots that help American businesses build more and dream bigger. Our robots do more than lower costs. They push out the Pareto frontier of productivity, taking on demanding, exhausting work in semiconductor cleanrooms, cold-storage facilities, and large warehouses. This deployment experience shapes both the models we develop and the tools we build around them.

At Verne, we believe every business can benefit from general-purpose robots. Bringing robots to every business takes many teams with deep operational expertise. With V0.5, these teams start from a frontier model instead of training one from scratch.

Our commitment to this platform comes from the requirements we encounter in our own deployments: learning new tasks efficiently, adapting to different environments, and operating reliably in production. We will continue pushing the frontier of world action models while improving the tools that help teams turn those capabilities into successful deployments.

Alongside the open weights, we are launching a fine-tuning platform that enables teams to adapt V0.5 to their own tasks using their own demonstrations. We also offer bespoke deployment services for partners who want to work directly with us on their use cases. Together, the model, platform, and services give teams a foundation they can build on independently, with Verne’s expertise and support available as they bring robots into production.

In this post, we share the technical details of V0.5, the Verne stack, and what we learned building them.

Problem

Our goal is for dual-arm mobile robots to do the complex, long-horizon tasks that are common in industry. These tasks have many steps and span large work areas. The robot must track its progress through the task and recover from failures. As jobs change, robots must adapt while keeping production speed and accuracy.

The Verne stack is built for this. It has three parts: the V0.5 model, a data and training system, and inference and control software. Together they deliver four capabilities:

• Long-horizon autonomy. Chain short language instructions into new long tasks and track progress.
• Full-body manipulation. Move the base and both arms together, so the robot can reach work across a large area. A full shift of work does not fit on one table, and bringing it to a fixed robot takes conveyors or manual handling.
• Rapid learning with robust error recovery. Learn a new task, or a new step of a longer task, from under two hours of demonstrations and human corrections, building on what the model already knows, and recover from errors. The less teaching a task takes, the more tasks are worth automating.
• Fast, precise execution. Meet the cycle time and the accuracy of the line. Inference and control work together, so the motion stays continuous, fluid, and responsive.

Methods

System Overview

At runtime, V0.5 and our inference and control software form four layers. A task goal goes in at the top, and motor commands come out at the bottom. V0.5 is the policy layer, the second of the four. The other three are the high-level reasoning layer, the execution layer, and the controller.

1. High-level reasoning layer. An off-the-shelf vision-language model. It reads the task goal and the camera images, and gives V0.5 the next language instruction. A long task becomes a sequence of short instructions.
2. Policy layer: Verne V0.5. A world action model with two transformers: a video transformer that learns how a scene changes, and an action transformer that predicts robot motion. They train jointly. At runtime the model generates actions only. It takes the current camera images, memory, robot state, and the language instruction. It outputs an action chunk of 30 Hz targets, each with end-effector poses, gripper commands, and a base position (Figure 2). It also outputs its progress on the current instruction.
3. Execution layer. Turns each action chunk into a joint trajectory for the specific robot. V0.5 plans the next chunk while the robot executes the current one. The new chunk starts from where the robot will be when inference ends, so the motion does not stop or jump between chunks.
4. Controller. Turns the joint trajectory into motor commands for the actuators. It runs in real time at 500 Hz, independent of model inference.

The split between the high-level reasoning layer and the policy layer follows the two systems of human thinking: System 1 is fast and automatic, and System 2 is slow and deliberate.¹ The policy layer, V0.5, is System 1. The high-level reasoning layer is System 2. NVIDIA's GR00T N1 and Figure's Helix use similar dual-system designs.^2,3

Data

Our data collection targets industrial workflows. We pretrained V0.5 on over 1.7 million demonstrations from data vendors, open-source datasets, and our own collection. Within the pretraining corpus, we primarily focus on teleoperation data and data from handheld grippers (similar to the UMI gripper).⁴ Beyond pretraining, we record our own post-training data with teleoperation and with handheld grippers that we co-designed with the robot’s end effector. Task-specific post-training on our robots uses Verne data only.

Data quality in both pre- and post-training is essential to the success of our models. To support that, we have created an automated data quality pipeline. We check each recording’s timing, motion quality, and whether its instruction correctly describes the demonstrated action.

Data labeling and annotation are critical to the success of our post-training process to ensure robust language steerability. To that end, we have created a semi-automated labeling pipeline that provides grounded sub-task language annotations for our post-training demonstration episodes. We take the learnings from BLADE and apply semi-automated annotation to find the sub-tasks that the robot performs.⁵

Performance improves during pretraining. With no fine-tuning, RoboTwin 2.0 success rose from 23% to 51% as pretraining went from 29% to 100% of the data (Figure 3). We observe a strong scaling law, similar to those reported by Generalist AI, Physical Intelligence, and NVIDIA. We are now scaling our data by a factor of 10.

Policy Layer: Verne V0.5

V0.5 is a world action model (WAM): it learns to predict both what the robot will see next and what it should do. Learning how a scene changes helps the model learn how to act in it. In training, a video transformer and an action transformer exchange information through masked attention and learn together, each with its own flow-matching objective (Figure 4). Fast-WAM, Motus, and VPP2 are related video–action models.^6,7,8

Video generation models are a strong starting point for learning how scenes change. But robot manipulation is out of distribution for them: the camera views, the motions, and the contact with objects look little like the videos they learned from. VPP2 shows this gap, and the gain from adapting the video model to manipulation.⁸ V0.5 starts from the Wan2.2 video model.⁹ We expand its architecture and pretrain it on over 1.7 million demonstrations. We train V0.5 in three stages, from robot video to robot control to the specific task (Figure 5):

1. Robot-video pretraining. Adapt the video model to robot observations, so it learns how manipulation changes a scene.
2. Joint video and action pretraining. Train the video and action transformers together on paired observations and actions, so that visual prediction connects to the motion the robot makes.
3. Task-specific post-training. Adapt the model to the deployment task with a small amount of Verne data, through fine-tuning, human corrections, and reinforcement learning. Each cycle starts from an evaluation on the robot.

At runtime, V0.5 generates actions directly, without generating future video. Video-planning methods such as VPP2 first predict a future visual representation, then use an inverse dynamics model to find the actions that lead to it.⁸ V0.5 keeps video prediction as a training signal and skips its cost at runtime, the same principle as Fast-WAM.⁶

V0.5 acts in end-effector space, not in joint space (Figure 6). Demonstrations from different rigs then share one description of motion, whatever their joints, as in the interface design of UMI.⁴

High-Level Reasoning Layer: Planning with a Vision-Language Model

V0.5 follows one short language instruction at a time, such as “pick up the cup.” The high-level reasoning layer breaks a long task into a sequence of these instructions. An off-the-shelf vision-language model reads the task goal, the camera images, and context such as memory and maps. It gives V0.5 the next instruction and updates the plan. V0.5 reports its progress on each instruction. This design draws on STACK, BLADE, and hierarchical planning.^5,10,11

Together, the two layers do tasks that neither can do alone. In Figure 7, the high-level reasoning layer builds a makeup kit one step at a time. Each step is one instruction, so the reasoning layer can pack orders with different quantities of each product. It also recovers from errors: it counts the items in the bag, and when an item drops, it tells V0.5 to pick the item up again. In the bin-picking clip, it sees when a bin is empty and tells V0.5 to put the bin back on the shelf. It can also notify a person that the bin needs to be refilled. The reasoning layer gives V0.5 its instructions in plain language, so a new task built from steps V0.5 already knows needs only a new task goal. In the two-robot clip in Figure 1, one reasoning layer directs both robots.

Execution Layer: Action Chunking

The execution layer turns each action chunk into a timed joint trajectory for the robot and joins it to the motion already in progress.

With real-time chunking, the robot keeps moving while the model plans. While V0.5 computes the next chunk, the robot runs targets that are already committed to the queue. V0.5 takes those targets as given and plans the rest of the chunk after them, so the new chunk joins the motion with no pause and no jump (Figure 8).¹²

There are three common ways to join chunks. Synchronous replacement stops the robot while the model plans. Linear blending fades from the old chunk to the new one across the seam. When the two chunks disagree, the average is a motion that neither chunk planned. Real-time chunking keeps the committed targets and plans after them.

Controller

V0.5 streams action chunks, and the execution layer turns them into joint targets. The controller turns these joint targets into motor commands. It keeps the arm on its targets, even when the load or the contact changes.

The right controller depends on the actuator. Harmonic drives give precise, low-backlash positioning, but their high reduction adds friction and reflected motor inertia. Quasi-direct-drive (QDD) actuators pair high-torque motors with low reduction, so the joints are backdrivable and respond quickly to force.^13,14

Most of our robots use QDD: it handles contact well and costs much less than harmonic drives. Harmonic drives with joint torque sensors handle contact well too, but today, at fleet scale, their cost is often prohibitive. The weak point of QDD is tracking. Gravity, payload changes, and coupling between joints show up as motion that nobody commanded. More damping slows tracking, and more stiffness pushes harder on whatever the arm touches. So the remaining accuracy has to come from the command, not from the gains.

The controller is a C++ process, separate from model inference. It runs on a real-time Linux kernel, with real-time priority and locked memory. Timing matters: training and execution share one clock, anchored to camera capture, so every action lines up with the frame it came from. If the controller drifts, the policy sees commands and observations that never happened together, and the error compounds.

At policy execution time, the controller plays targets from a queue filled ahead of time, so inference time and network jitter never reach the motors. It also models the arm’s dynamics and feeds forward joint velocity, acceleration, and torque, so it acts before a tracking error builds up, not after. Figure 9 shows the same V0.5 policy on the same task with the stock YAM controller and with ours.

Autonomous 1× 0:00 / 0:00

Stock YAM controller

Autonomous 1× 0:00 / 0:00

Verne controller

Play Replay

We measured how closely each controller follows the commanded end effector over 20 LEGO runs per controller (Figure 10). The stock YAM controller sends each target as a position with zero target velocity. Its damping then pulls against every motion, so the arm trails the command by 52 to 60 ms at every speed. The faster the arm moves, the farther it falls behind: the median error grows from 9 mm to 26 mm. With the Verne controller, the arm trails by 4 to 12 ms, and the median error stays between 2.2 and 3.5 mm at every speed.

At 30 Hz, 60 ms is almost two command targets. This delay undermines real-time chunking (Figure 8), which assumes that the arm reaches each committed target on time. V0.5 and the controller work together: the model plans from where the arm will be, and the controller puts the arm there on time.

Results

We compare V0.5 with published results on two public simulation benchmarks, LIBERO and RoboTwin 2.0.^15,16 For each, we fine-tuned V0.5 on the benchmark’s own training demonstrations and ran its standard protocol. We compare against other world action models and vision-language-action models, including π0.5 and π0.^17,18

Simulation Benchmarks

LIBERO has four suites of ten tasks: Spatial, Object, Goal, and Long. V0.5 succeeds in 99.3% of episodes on average over the four suites, and in 99.2% on the multi-step Long suite (Figure 11). π0.5 succeeds in 96.85% and π0 in 94.15%. ABot-M0.5 has a slightly higher average, 99.4%, and a lower Long score, 98.4%.

RoboTwin 2.0 has 50 two-arm tasks. Its protocol fine-tunes each policy on 2,500 clean-scene demonstrations, 50 per task. It then evaluates the policy in clean scenes and in randomized scenes with clutter, new textures, other lighting, and other table heights. V0.5 succeeds in 81.0% of clean and 73.4% of randomized episodes (Figure 12). π0.5 succeeds in 70.7% and 46.0%.

Among open-weight models developed by US companies, V0.5 leads on LIBERO and RoboTwin 2.0, as of November 1, 2026. The closest are Cosmos Policy from NVIDIA on LIBERO, at 98.5%, and π0.5 from Physical Intelligence on RoboTwin 2.0.

Hard Tasks and Randomized Scenes

Compared with π0.5, a top open-weight model, V0.5 gains the most where π0.5 is weakest. On LIBERO, V0.5 and π0.5 tie on Spatial at 98.8%. On Long, the suite of multi-step tasks, V0.5 leads by 6.8 points. On RoboTwin 2.0, we compared the two models on each of the 100 pairs of task and scene type, grouped by how often π0.5 succeeds (Figure 13). Where π0.5 succeeds less than 30% of the time, V0.5 leads by 38.5 points on average. Where π0.5 already succeeds 90% of the time or more, V0.5 is 4.4 points behind.

V0.5 holds up in randomized scenes. Clutter, new textures, other lighting, and other table heights cost V0.5 7.6 points on average and π0.5 24.7 points, so our lead grows from 10.3 points in clean scenes to 27.4 in randomized ones. π0.5 loses 40 points or more on 11 of the 50 tasks. V0.5 does not lose that much on any task. When V0.5 solves a task in clean scenes, it usually solves it in randomized scenes too (Figure 14).

Conclusion

The next frontier for artificial intelligence is helping people build a better physical world. Robots expand what we can make, take on dangerous and exhausting work, and turn more human ideas into reality. We are here to help build that future.

We work toward our mission in three ways, starting today. We release the V0.5 weights, so anyone can build on them. We are launching a fine-tuning platform, so developers, scientists, and researchers can teach V0.5 their own tasks with their own demonstrations. We give our partners bespoke service to deploy V0.5 into their use cases, from small startups to experienced automation teams inside manufacturers.

We are building the Verne stack around developers, to make it easier to collect data, train models, and deploy robots. In the coming months, we will also release our handheld grippers, so you can record demonstrations of the work you want robots to learn.

Bringing a robot to every American business takes many teams and increasingly capable intelligence. Our next model is already training. It is larger, and it learns from even more diverse data.

Above all, we want to help build a US-led, open robotics effort that people everywhere can build on. Fourteen months ago, Physical Intelligence opened the weights of π0.5 and pushed the frontier. NVIDIA’s work on Cosmos and related models is another major contribution. We deeply respect their open-source efforts. V0.5 is our part in this effort.

If you are excited to turn these advances into robots that do useful work, join us. Build on V0.5, teach a robot something new, or come build with us at Verne.

Let’s give everyone the tools to build the world of their dreams.

Citation

Please consider citing this work as:

Verne Team, “Verne V0.5: An Open-Weight World Action Model to Accelerate Industrial Robot Deployments”, 2026.

Or use the BibTeX citation:

@misc{verne2026v05,
  title  = {Verne V0.5: An Open-Weight World Action Model to Accelerate Industrial Robot Deployments},
  author = {{Verne Team}},
  year   = {2026},
  url    = {https://vernerobotics.com/research/verne-v0-5}
}