pi05: pi 0.5 (π0.5), the Physical Intelligence vision-language-action model, as a per-call API

pi05 is this platform's name for a metered lane that is not on the public list. The lane serves pi 0.5. That is the vision-language-action model from Physical Intelligence, published as open weights in September 2025. The model is real, public, and open today. Its row sits in the platform's model data, behind the public list, with its rate already set. Nothing serves under this alias today. This page is also the family head. One base model ships as three public checkpoints. The two specialist tunes get their own pages in this family: pi05-droid and pi05-libero.

Last verified: 2026-10-05

What it is

Pi 0.5 is a robot policy model. It reads camera images and a task sentence. It senses the position of the robot's joints. It outputs the joint commands that move the arm. The class name is vision-language-action, or VLA. Per the pi 0.5 paper (Physical Intelligence, April 2025), the model is built for one problem: doing tasks in places it has never seen. In the paper's tests it cleaned kitchens and made beds in real homes. Those homes were not in the training data. Three kitchens and three bedrooms, all new to the model.

The publisher states the goal in plain words. Its own post says the biggest challenge in robotics "is not in performing feats of agility or dexterity, but generalization". That means doing a simple task right in a new room, with new objects. The post also says the model "does not always succeed on the first try". Keep that honesty in mind. This is a research model with a strong record. It is not a finished product.

The name map: pi0.5, π0.5, pi05, and the Pi board

One model, several spellings, and one collision:

The Raspberry Pi collision is common. This page's FAQ owns it. If a search brought you to board pages, the FAQ entry on it explains the mix-up in one read.

The license position needs three separate statements. Three artifacts carry three different terms. The openpi repository code is Apache-2.0. That license file was read directly on October 5, 2026. The LeRobot port card carries a Gemma license tag in its own frontmatter. The PaliGemma backbone brings Google's model terms with it. The tokenizer the model needs, google/paligemma-3b-pt-224, sits behind a license gate on the Hub. You accept its terms and log in before your first run. None of this blocks commercial testing. It does mean a buyer should read the repo license and the port card before shipping a product on the weights. Comparing encumbered robot models in general? The GR00T license guide in our docs covers that decision. It names this family as the open-weights alternative.

The posture on this platform, stated plainly: the row is not on the public list. Nothing answers under pi05 today. This page makes no live-availability claim. The models index is the live catalog. The VLA category page covers the platform's action model family.

pi 0.5 versus pi 0: what actually changed

Pi 0 came first, in October 2024. Pi 0.5 arrived as a paper in April 2025 and as open weights in September 2025. The two share their bones. This is not a size bump.

What stays the same:

• The PaliGemma vision-language backbone, which reads images and text.
• A small action expert, about 300 million parameters, built from scratch, which outputs movement.
• The action chunk horizon of 50 steps, and 10 denoising passes per chunk.
• Flow matching. The expert refines noise into a smooth path instead of picking from fixed bins. That is why it holds up on contact-rich work like insertion and stacking, where the last few millimeters decide the outcome.

What changed:

• The learning signal is cut off. In pi 0, the action expert's training signal flowed back into the backbone. In pi 0.5 it does not. The publisher calls this knowledge insulation. The backbone keeps its language and scene knowledge. A fresh, noisy expert no longer drags it around.
• The backbone learns movement from discrete tokens. The model turns action chunks into token strings. It trains the backbone on them with a plain next-word loss. This trains much faster than pushing continuous action gradients through the whole network.
• The data mixture grew. Robot recordings were mixed with web data such as captioning, with recorded spoken coaching, and with subtask labels like "pick up the pillow" on scenes of unmade beds. The paper's tests say web data matters most for new objects. Data from other robots matters everywhere.
• One caveat for builders. The paper describes a system that first predicts a semantic subtask in words, then generates the actions for it. The open checkpoints ship the low-level half only. Both the openpi repository and the LeRobot port card state this. Subtask prediction, action tokenization, and the RL parts were not released. Fine-tuning pi 0.5 on your arm runs a layered training recipe flat. Expect its reach. Do not expect the robot to narrate its plan.

Use cases

The skill list comes from the paper's tests and the publisher's post:

• Household tasks in unseen rooms. The paper's headline. Cleaning kitchens and bedrooms. Items in drawers, laundry in the basket, dishes in the sink. All in homes never visited during training.
• Long-horizon work. Tasks of two to five minutes, strung from many small steps, with no human in the loop.
• Language-driven rerouting. One checkpoint serves several phrasings of a task. The task sentence is genuinely read, not matched.
• Contact-rich moves. The flow-matching head emits smooth continuous paths. There is no bin edge under the last millimeters of an insertion.
• A fine-tuning base for your robot. The base checkpoint exists to be tuned on your demos. The wider ecosystem treats it as the strongest open generalist base of its class.

Where it is the wrong tool: fast reactive work. Tracking a moving object needs many decisions per second. A model whose chunk takes a tenth of a second or more to compute is the wrong shape for that job. A small dedicated policy fits better. So does a perception model feeding your own controller. The sibling pages in this family cover models picked for exactly those jobs.

The embodiment family: base, DROID, and LIBERO

One released model, three public checkpoints. Choosing among them is the first real decision a buyer makes. Almost nothing on the open web explains it. The full checkpoint table lives in the openpi repository:

The practical rule: run base only if you have demos to tune on. Run the DROID tune if your robot is close to a Franka-class arm with two cameras. Run it too if you want the broadest out-of-the-box behavior the publisher reports. Run the LIBERO tune if your work is the LIBERO benchmark itself. An embodiment is the specific robot: its joint count, its cameras, its action ranges. Each checkpoint carries norm stats. These translate the model's output into your robot's units. Wrong stats produce wrong motion. That is why the endpoint contract on this platform returns the stats it applied with every answer.

Action chunks and control rate

Pi 0.5 does not decide one move at a time. Each call returns an action chunk: a batch of up to 50 future joint commands, built together by 10 denoising passes. The robot runs the chunk while the next one is computed. That is how a large model drives a fast control loop.

The timing math belongs to the pi 0 paper (2025; table read October 5, 2026). It uses the same design and publishes its table. On an RTX 4090: image encoders 14 milliseconds, the observation pass 32, the 10-pass action head 27. That is 73 milliseconds on board, 86 with a network hop. Those 73 milliseconds buy 50 actions, not one. On a 50 Hz loop the paper re-runs inference every half second, after 25 actions.

This is also why latency claims for this model disagree so much. One page reports a figure per action step. Another reports it per chunk. A network hop may or may not sit inside the number. Before you compare, ask which unit the number counts. Want the chunk joins to disappear? Real-Time Chunking is the named fix. The next chunk is computed while the current one runs. Its start is guided to line up with the tail of the last chunk. Intel's robotics docs and the LeRobot project both describe it for pi 0.5. LeRobot ships it for the port.

API usage

The lane's contract speaks the platform's action route. It is POST /v1/action, with a Bearer key from the console. Multipart form data goes in. JSON comes out. The model id is pi05.

One served request returns three things. actions is the action chunk, a list of actuator deltas in the checkpoint's own shape. normalization is the norm stats the endpoint applied, passed through untouched. Your driver uses them to convert back to your units. usage is ours: the call count and the cost of the call, returned with every answer. Metering is per call, not per token. One served request is one billed call. A refused request bills nothing. The prepaid wallet balance is the spending stop. Every field, error code, and limit lives in the run-action reference.

Already running the openpi policy server? The shapes line up. The openpi remote pattern is a websocket policy server on port 8000. It takes an observation dict of images, state, and prompt. It returns an action chunk. Normalization happens on the server side in that pattern. This endpoint follows the same law: it states the stats it applied, in the response. Your robot loop can talk to either.

The honesty line, repeated: this alias is not on the public list. Nothing answers under it today. The tabs below are the contract the lane ships under. Client code can be written and tested against the shape now.

curl

curl -X POST "https://api.ironstratum.com/v1/action" \
  -H "Authorization: Bearer $KEY" \
  -F "model=pi05" \
  -F "instruction=pick up the green cube and drop it in the bowl" \
  -F 'state=[0.0, 0.12, -0.4, 0.0, 0.5, 0.1, 0.0]' \
  -F "image=@scene.jpg" \
  -F "image=@wrist.jpg"

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/action",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    data={
        "model": "pi05",
        "instruction": "pick up the green cube and drop it in the bowl",
        "state": "[0.0, 0.12, -0.4, 0.0, 0.5, 0.1, 0.0]",
    },
    files=[
        ("image", ("scene.jpg", open("scene.jpg", "rb"), "image/jpeg")),
        ("image", ("wrist.jpg", open("wrist.jpg", "rb"), "image/jpeg")),
    ],
    timeout=30,
)
resp.raise_for_status()

answer = resp.json()
chunk = answer["actions"]         # the action chunk: a list of actuator deltas
stats = answer["normalization"]   # the norm stats this endpoint applied
print("actions in this chunk:", len(chunk))
print("cost of this call:", answer["usage"].get("cost"))

lerobot

import os
import requests
from lerobot.cameras.opencv import OpenCVCamera

session = requests.Session()
session.headers["Authorization"] = "Bearer " + os.environ["KEY"]

cam = OpenCVCamera(camera_index=0, fps=30, width=640, height=480)
cam.connect()

instruction = "pick up the green cube and drop it in the bowl"
state = [0.0] * 7  # your arm's joint positions, same order on every call

running = True
while running:
    frame = cam.async_read()
    resp = session.post(
        "https://api.ironstratum.com/v1/action",
        data={
            "model": "pi05",
            "instruction": instruction,
            "state": "[" + ", ".join(str(s) for s in state) + "]",
        },
        files={"image": ("scene.jpg", frame, "image/jpeg")},
        timeout=30,
    )
    resp.raise_for_status()

    chunk = resp.json()["actions"]
    for deltas in chunk:
        state, running = arm_step(state, deltas)  # your arm driver goes here
        if not running:
            break

The loop above is the whole pattern. Send frames, instruction, and state. Receive a chunk. Run it at your control rate. Send the new state with the next call. The LeRobot camera class is one way to get frames. Any camera source works. The contract is the form fields, not a client library.

Benchmarks

Three evidence layers, each named and dated. None is this platform's own measurement. Nothing serves under the alias, so there is nothing here to measure. Our numbers publish only after they are measured and held. That refresh is later work, not a promise on this page.

LIBERO, two runs, never averaged. The reference run in the openpi repository reports, for the pi05_libero checkpoint tuned for 30,000 steps: Spatial 98.8, Object 98.2, Goal 98.0, Libero 10 92.4, average 96.85 (repo README, read 2026-10-05). The LeRobot port team tuned the same base for 6,000 more steps. It reports: Spatial 97.0, Object 99.0, Goal 98.0, Libero 10 96.0, average 97.5 (LeRobot pi 0.5 docs, read 2026-10-05). Two honest results for one model. They agree on one point: the port is faithful. Neither tells you how the model behaves on your desk. LIBERO sits near 97 percent. It has mostly stopped separating good policies from each other.

Real homes, from the paper. The test behind the model's name is not a leaderboard. The paper reports cleaning and tidying in three kitchens and three bedrooms of real homes, never seen in training. It also reports controlled mock-room runs. The system drove the robot at 50 Hz. The publisher's post repeats the caveat: the model does not always succeed on the first try.

A community production benchmark. The PhAIL leaderboard, run by Positronic Robotics, was read live on October 5, 2026. It measures single-arm pick-and-place on a DROID setup, with production metrics. On that day's page, open pi 0.5 ranked in the top group, tied at the front of the open models with GR00T N1.6, which scored 46.1 percent, behind only human teleoperation. It scored 44.4 percent success within 30 seconds, plus or minus 4.3, at 15.7 seconds per item. Human teleoperation scored 99.0 percent at 10.4 seconds per item. That is the honest state of open generalist policies on commercial pacing. Far from teleoperation. Exactly the kind of number demo videos never show. Community-run, single source, read on the date named.

Getting started

1. Read the primary sources. The paper, the openpi repository, and the publisher's post are all public. Every identity fact on this page traces to one of them.
2. Pick your checkpoint before your hardware. Base if you have demos to tune on. The DROID tune to run broadly. The LIBERO tune for the benchmark. The table above is the short version. Then check the memory numbers against your GPU. No 8 GB-plus NVIDIA card? The weights path is closed for now. That is exactly the buyer the lane contract exists for.
3. Write your client against the contract now. The tabs above are the shape the lane ships under. The run-action reference documents every field and error. The models index is the live catalog.
4. Open the console when you build. The signup flow opens the wallet, the keys, and the billing history. The loaded balance is the spend bound. Each key revokes alone.