π₀ and π₀.₅: the open reference design

Where you are. You know why systems split fast from slow and what can cross the boundary. This lesson opens the frontier-class design whose weights you can actually download, and it is the one architecture in this module worth learning line by line.

The model that forgot what a mug was

You have done the software version of this. Take a capable general model, fine-tune it hard on ten thousand of your own support tickets, and it gets sharper at tickets and duller at everything else. Nothing crashes. Ask it a question it used to answer well and the answer comes back flatter, more generic, slightly wrong in a way you cannot point at. The weights moved and they took something with them.

Now do the robot version, and notice that it is worse.

Take a vision-language model that has read most of the web and genuinely knows what a mug is, what “the extinct animal” means, what a fridge looks like from the inside. Bolt a fresh motor head onto it and start training on robot trajectories. On the first training step that head is randomly initialised. Its outputs are noise. Its gradients are therefore also noise, and those gradients flow straight back into the part of the network that knew what a mug was.

You are not fine-tuning the model. For the first several thousand steps you are sandblasting it.

The idea in one paragraph

π₀ is a vision-language model with a second, smaller transformer alongside it. The vision-language half reads camera frames and the instruction. The other half, called the action expert, reads the robot’s joint angles and a chunk of noisy candidate actions and turns them into fifty real-valued future actions. The two share one self-attention stack, so this is a single forward pass rather than two models talking over a wire. π₀.₅ then splits the training in two: a pretraining stage that supervises the backbone with discrete action tokens, where the learning signal is clean and familiar, and a post-training stage that adds the flow-matching action expert, where inference is fast. A follow-up paper collapses that into one stage and adds the idea that makes the whole thing hold together, and it is the most teachable architectural idea in this module: run both objectives together and block the action expert’s gradients from ever reaching the backbone. That paper calls it knowledge insulation, and its slogan is train fast, run fast, generalize better.

Two experts, one attention stack

The diagram has four input streams and they split cleanly into two pairs.

Images and words go to the vision-language expert, which for π₀ is a backbone of the PaliGemma family. This half is where all the pretraining lives. It has seen far more of the world than any robot dataset contains, and everything the model knows that is not about motors is stored here.

Joint angles and a chunk of noisy candidate actions go to the action expert, roughly 300 million parameters in π₀. This half has seen nothing but robots. Its job is narrow: given the scene as the other half understands it, and given where the arm currently is, refine that noisy chunk into a real one.

The output is a chunk of fifty continuous actions, produced by flow matching, supporting control at up to 50 Hz. Action representations covered flow matching properly; the one line to carry into this lesson is that training draws a straight line from a noise sample $a_0$ to a real action chunk $a_1$, picks a random point $a_\tau$ on that line, and asks the network for the direction to travel:

$v_\theta(a_\tau, \tau) \approx a_1 - a_0$

Because the target path is straight, the direction is the same everywhere along it, so integrating it back at inference takes a handful of steps rather than dozens. That is the whole reason this design can hold a 50 Hz loop.

Knowledge insulation

Now the problem from the hook, stated precisely. The action expert starts random. Backpropagating its loss through the shared attention would deliver noise to the pretrained backbone at exactly the moment the backbone is most fragile and the expert is least useful.

The recipe runs two objectives against one model.

The backbone is supervised on discrete action tokens produced by FAST, the compression scheme from the action-representations lesson. This is next-token prediction with a cross-entropy loss, which is precisely the objective the backbone was pretrained with. It is the model’s native language, so the gradients are well-behaved and the semantic representations survive contact with robot data.

The action expert is trained with the flow-matching loss on continuous chunks, because that is what you want at inference time.

Between them sits a stop-gradient. The expert’s gradients update the expert and stop.

The obvious alternative is to freeze the backbone entirely, and it is worse. A frozen backbone cannot learn anything robot-specific: not what your camera angle looks like, not that gripper fingers occlude the object, not what “the third one from the left” means when the objects are on a bench rather than in a photograph.

So insulation is not “protect the backbone from robot data.” It is “let the backbone learn from robot data through a clean channel, and only that channel.”

What you can actually download

This is where a lot of writing about π₀ stops being useful, because the family has five members and only some of them exist as files.

Those two lines are the sort of detail that costs you a week if you find it late. If your whole toolchain is PyTorch, one checkpoint quietly leaves your list of options - and so, as the repository currently stands, does the entire low-rank fine-tuning path that the next section is about to tell you fits on a 24 GB card. The 22.5 GB LoRA row is a JAX row. Check whether that is still true on the release you clone before you plan around it.

What it costs to run

From the repository’s own table:

Read the middle row carefully, because it draws the practical boundary of this whole module. A 24 GB consumer card can LoRA-fine-tune a π₀-class model with essentially no headroom, and cannot full-fine-tune one at all. Above 40 GB, on rented hardware, everything opens up. Below 24 GB you are running inference and fine-tuning smaller models, which is exactly what SmolVLA is for.

The two you cannot have

Physical Intelligence has published two models past π₀.₅ that exist as papers and not as files.

π*₀.₆ (17 November 2025) adds a training recipe called RECAP: demonstrations first, then real-time expert corrections when the robot goes wrong, then reinforcement learning from its own autonomous attempts. The reported results are about twice the throughput and more than half the failures removed, with continuous espresso making, laundry folding in an unfamiliar home, and factory box assembly. A parameter count of roughly 5 billion appears in secondary coverage rather than in Physical Intelligence’s own material, so treat it as approximate; the same goes for the specific run lengths (18 hours, 50 items, 59 boxes) that circulate in coverage, which I did not confirm against the primary source. All results are self-reported and nobody outside the company has replicated any of them.

π₀.₇ (16 April 2026) is framed as a steerable generalist: conditioned not only on an instruction but on metadata, control modalities and visual subgoals, and trained on a mixture that includes human video and the robot’s own autonomous data. The headline claim is that a single π₀.₇ matches or beats task-specific specialists trained with reinforcement learning on their own single task. No parameter count is published and no weights are released.

Check yourself

Do this

About thirty minutes, no GPU needed.

1. Do the memory arithmetic yourself. Run this, then reconcile it against the published table above.

params_b = 3.3          # billions of parameters, pi-zero class

weights = params_b * 2   # bf16, 2 bytes per parameter
grads   = params_b * 2   # bf16 gradients, full fine-tune only
adam    = params_b * 12  # fp32 master copy plus two Adam moments

print(f"weights alone                {weights:5.1f} GB")
print(f"full fine-tune, no activations {weights + grads + adam:5.1f} GB")
print("published: inference >8 GB, LoRA >22.5 GB, full >70 GB")

Write two sentences. Where does the gap between your full-fine-tune number and the published 70 GB come from? And why is the LoRA figure so much larger than the weights alone, when the adapters themselves are a few tens of megabytes?

2. Go and read the shelf. Open the openpi repository. Find the list of checkpoints, the LICENSE file, and any licence text attached to the weights themselves. Write down, in your own notes: which checkpoints exist today, which are usable from PyTorch, and what licence you believe covers the weights, with the URL you got that from and the date you checked. If you cannot find an explicit weights licence, write that down too, because that is the finding.

3. Draw it from a blank page. Close everything. Draw the π₀ architecture: four input streams, two experts, one shared attention stack, one output chunk. Then add the two training losses and the stop-gradient. Compare against the two figures above. The exit test for this module asks you to do this for three architectures from memory, and this is the one to get solid first.

What you can now do

You can draw π₀ from memory and say what each half sees. You can explain knowledge insulation, why a fresh action head is dangerous to a pretrained backbone, and why freezing is not the fix. You can state which π-family checkpoints exist as files rather than as announcements, which runtime each one needs, and what card you need for inference against LoRA against a full fine-tune. And you have a habit worth more than any of that: when a release quotes a comparison, you now ask what it was compared against.