pi 0.7 (π0.7) access: not open source, no API, and the real pi 0.6 vs 0.7 difference

Pi 0.7 is not open source. As of 2026-10-27 there are no public weights, no checkpoint, and no third-party API anywhere. The publisher, Physical Intelligence, posted the model on April 16, 2026 in a blog post and a paper. It released nothing you can download. The one first-party door is the Pi API beta, opened October 13, 2026. That is a waitlist: you upload demos, they fine-tune on their machines, and the result serves through their gateway. No model ids. No prices. The line's open era stopped at pi 0.5. As of 2026-10-27 this platform has no public listing for a pi 0.7 or pi 0.6 class route either. The models index is the live catalog.

Last verified: 2026-10-27

What it is

Pi 0.7 (written π0.7 or pi0.7) is a vision-language-action model for robot control from Physical Intelligence. Camera images, a task sentence, and extra context go in. Chunks of joint commands that move the arm come out. The paper counts about 5 billion parameters. The build: a 4-billion-parameter language-vision backbone on Gemma3, a video history encoder, and an 860-million-parameter action expert. Its famous claim is skill mixing. The model recombines skills it already has to do tasks it never trained on. One example: after being talked through it once, it loaded a sweet potato into an air fryer. It also folded laundry on a two-armed robot it had never folded on. Its first-try success rate matched trained human operators on the same test.

The version history matters here. The access answer changes per version. Six rows tell the whole story.

Read the open column top to bottom and the pattern is plain. The publisher open-sourced the first two generations, then stopped. Every model after pi 0.5 in this line ships as a paper and a blog post, with the weights kept. That is what closed frontier means in this page's address. The research is public. The artifact is not.

Two name mix-ups ride along with this query family, and the search engine shows both. A bare "pi 0.7" can mean the perfusion index on a pulse oximeter. That is a medical device number with no link to robots. The suggestion engine itself offers "pi 0.7 oximeter" as a completion. And the pi in every name here is the Greek letter the company uses as its brand. It is never the Raspberry Pi board computer. If a search dropped you on oximeter pages or small boards, that is the mix-up at work.

The demand side of this query is its own evidence, and it all points one way. Google's suggestion engine, read on 2026-10-27, completes "pi0.7" with paper, model, github, arxiv, code, and huggingface. It completes "pi 0.7" with the same list plus "open source". People are looking for something to download. Type "pi0.7 api" and the completions come back empty. There is no API to search for. The People Also Ask block on the family's results asks point blank whether pi 0.6 is open source. The answer, dated, is no.

On this platform's own posture, stated plainly with its date: the pi 0.7 and pi 0.6 class is not currently offered here. As of 2026-10-27 there is no public listing for a pi 0.7 or pi 0.6 class route. This page promises no date and no arrival. What is published instead is the record you are reading, plus the platform's action route contract. Any robot client can be written against that contract today. The VLA category page holds the model family, and the models index is the live catalog.

Use cases

The reader who typed "pi0.7 access" wants the model and cannot have it. That buyer has four real paths today. Picking between them is the decision this page helps make.

The first path is the paper-plus-rebuild path, and the community took it. Both closed papers are public and detailed. The Recap recipe behind pi 0.6 and the context scheme behind pi 0.7 are described closely enough to rebuild. The rebuild projects on GitHub are doing exactly that. One such project, created in June 2026 with 49 stars, says it builds the pieces "discussed in public materials but have not yet been released" as open code. It sits on top of the publisher's open pi 0 through pi 0.5 stack. Its README names the closed ideas it rebuilds: Recap-style training, memory, and the world-model subgoal machinery. This path costs engineering time and buys deep understanding. It does not buy the trained model. Months of robot data went into the original.

The second path is the publisher's beta, covered in the waitlist access guide. It is the only way to have pi 0.7 class skill run for you today. The trade is the door itself. Apply, describe your use case, and wait. If accepted, upload demos and fine-tune on their machines. The beta post names real deployments built this way, from a driverless wheel loader to a two-armed robot that deburrs its own parts. It posts no prices and promises no named model, only that they keep enabling their latest. A buyer who needs a per-call catalog this quarter gets nothing from this door. A buyer building a real product gets a real offer with an unknown price.

The third path is to run the newest open thing instead. Pi 0.5 is the last open checkpoint in the line. It is a direct ancestor of pi 0.7, and it runs on one desktop GPU. For most robot tasks a small team will attempt this year, a fine-tuned pi 0.5 is the practical answer. What it costs to run is covered in the pi 0.5 pricing guide. The gap to pi 0.7 is real: the newer model follows richer prompts and reaches further into new tasks. Whether that gap is worth a waitlist or a rebuild depends on the task. Naming the gap is how you decide.

The fourth path is waiting, and for this model it beats how it sounds. The priced robot API market has exactly one member: Google's Gemini Robotics ER 2 (the only public robot rate card). That is a reasoning model, not an action policy. Its per million token rates double on January 1, 2027, per Google's pricing page read 2026-10-27. Every action policy in the pi line is unpriced everywhere. The publisher has also shown a pattern worth watching: open, open, then closed, closed, then a paid managed service. A team whose task is not blocked this quarter can let that play out. The big-host survey behind this page's claims is public in do the big hosts serve robot models. The wider model class has its own explainer in vision-language-action models explained.

API usage

Three calls matter on this page. The first checks a live catalog. Listing state is read, never guessed from a blog post. The second is the publisher's own flow for the newest model you can actually run, the open pi 0.5. Pi 0.7 has no runnable artifact of its own. The third is this platform's action route, a public contract that answers 404 for any pi class id until a listing exists. The contract is written up in the action route guide.

curl

The catalog check is one request:

curl -sS "https://api.ironstratum.com/v1/models" \
  -H "Authorization: Bearer $KEY"

The answer is the live list of model ids this platform lists. As of 2026-10-27, no pi 0.7 or pi 0.6 class id is in it. That is the whole check. Repeat it later and you learn whether that changed, without depending on any page's date.

The action call itself, if a pi class id ever appears in that list, is a multipart POST. Its shape is fixed today:

curl -X POST "https://api.ironstratum.com/v1/action" \
  -H "Authorization: Bearer $KEY" \
  -F "model=<id exactly as the models index lists it>" \
  -F "instruction=put the red cube in the bowl" \
  -F 'state=[0.12, -0.80, 1.25, 0.40, -0.20, 0.90, 0.50]' \
  -F "image=@cam0.jpg" \
  -F "image=@cam1.jpg"

Sent today with any unlisted id, it answers 404 with the code model_not_found. That is the honest answer. It is exactly what the platform's own docs promise for ids that are not on the public list.

python

No one can run pi 0.7 locally, so this tab shows the closest true thing. It is the publisher's own documented flow for pi 0.5, the newest open checkpoint in the family. On a GPU machine with the openpi repo installed, start the policy server, which listens on port 8000. On the robot machine, install the openpi-client package and speak to it:

from openpi_client import image_tools
from openpi_client import websocket_client_policy

# Server started with scripts/serve_policy.py from the openpi
# repository, using a pi0.5 checkpoint. Listens on port 8000.
client = websocket_client_policy.WebsocketClientPolicy(
    host="gpu-box.local", port=8000
)

for step in range(num_steps):
    # Resize images on the robot side to cut bandwidth, and keep
    # them uint8. The publisher's docs use 224 pixels here.
    observation = {
        "observation/image": image_tools.convert_to_uint8(
            image_tools.resize_with_pad(img, 224, 224)
        ),
        "observation/wrist_image": image_tools.convert_to_uint8(
            image_tools.resize_with_pad(wrist_img, 224, 224)
        ),
        "observation/state": joint_positions,  # unnormalized; the
        # server applies the norm stats for the checkpoint
        "prompt": "pick up the green cube",
    }
    action_chunk = client.infer(observation)["actions"]
    for action in action_chunk:
        arm_step(action)             # your arm driver, one row per tick

This is the publisher's pattern, not a rewrite. No snippet exists for pi 0.7. Any code on the internet claiming to load pi 0.7 or pi 0.6 weights loads something else. The stats that match a checkpoint to your arm are covered in the normalization stats guide.

lerobot

Here is the same loop against this platform's action route, with a LeRobot camera class for the frames. The contract is four form fields. The model id is a string you read from the models index:

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 every call

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

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

Written today, this client is complete and testable except for the id. That is the point of publishing the contract first. The response carries the action chunk, the stats block the model applied, and a usage object. Metering on this route is per call. One served request is one billed call. A refused request bills nothing. The prepaid wallet balance is the hard stop. Rates for listed models sit on the pricing page, never in prose on pages like this one.

Benchmarks

Nothing in this section is this platform's own measurement. A model with no runnable artifact has no numbers of ours to publish, and none will be invented. Every figure below carries its owner and its date.

The speed figures come from the two primary documents, both read on 2026-10-27. The pi 0.6 model card, dated November 17, 2025, states 63 milliseconds per action chunk on one H100 GPU, with 5 denoise steps and 3 cameras. For pi 0.7, the paper states a light build at 38 milliseconds on the same hardware class and camera count. Turn on the memory encoder and the drawn subgoal images, and the worst case climbs back to 127 milliseconds. The subgoal generator is itself a 14-billion-parameter image model. The paper runs it across four H100 GPUs with 8-bit math to keep its latency sane. Hold these setups side by side. The closed frontier is not just smarter. It is heavier.

The skill figures are the publisher's own, from the paper and the post. The pi*0.6 specialists were tuned for three tasks: laundry folding, espresso, and box building. A single pi 0.7 model matches or beats them in success rate and speed, out of the box, with no task tuning. Then the test that made headlines. The model folded shirts on a two-armed UR5e system it had no folding data for. The paper reports 85.6 percent task progress and an 80 percent success rate for the model. Ten human operators, averaging 375 hours of practice and given no warm-up on the new robot, scored 90.9 and 80.6. On par with trained humans at first contact, on hardware it never saw. The paper's own word for the result is competitive.

Demand closes the picture, from the model hub's own records read on 2026-10-27. The community port of pi 0.5 pulled more than 18,000 downloads last month. Pi 0's community port pulled more than 13,000. On the publisher's own group, the hub offers exactly one item, the FAST tokenizer. And the open repo's checkpoint table lists no version later than pi 0.5. Downloads flow to what is open. The two closed models pile up citations instead. A research record is not a product promise. For how a benchmark result does or does not transfer to your arm, read the embodiment stats guide.

Getting started

1. Read the two closed papers. The pi 0.7 post and the paper are public and detailed. So are the pi 0.6 post and its model card. Every identity claim on this page traces to one of them.
2. If you want to run something this week, run pi 0.5. The python tab above is the publisher's own flow for the last open checkpoint in the line. One GPU with 8 GB or more serves it. What it costs to run is covered in the pi 0.5 pricing guide.
3. If you want pi 0.7 class skill run for you, apply to the beta. The waitlist is the only first-party door. Onboarding comes in batches. Pricing is unpublished. No model ids are named. Ask for numbers before you commit engineering time. The access steps are walked through in the waitlist guide.
4. On this platform, watch the live list. Create an account on the signup page and make an API key. Check the models index the way the curl tab shows. Cost shapes for listed models sit on the pricing page, and the rate rules on the pricing guide. The model family lives on the VLA page, and the models index is the live catalog. When a pi class route ever appears there, this page's question changes from who serves it to what it costs per call. The answer will be on the pricing page, not in a blog post.