The new API beta from Physical Intelligence (Pi) lets robotics teams fine-tune its robot foundation models without building their own training infrastructure. For robot data, the telling part is how its early partners improved their robots: they tested a model, studied what went wrong, and let each failure decide what to record next. The API now runs the training. Reading the failures, and labeling them consistently, stays with each team.
On October 13, Physical Intelligence opened an API beta for its robot foundation models. Teams can upload data, fine-tune a model on infrastructure Pi manages, and run it on their own robots. That is useful news. The more interesting part is a short passage describing how early partners actually improved their robots.
Their problems were very different: a garment turned inside out, an ingredient that kept slipping out of a scoop, and a part that ended up in the wrong spot. The improvement loop, however, was similar: gather demonstrations, train a model, try it on the robot, then let what went wrong guide what to record next.
What Launched?
Pi’s pitch is that general-purpose robot models such as π0 and π0.5 already carry a lot of physical knowledge, but adapting them still requires machine-learning infrastructure, compute, and complicated data pipelines. The API takes over much of that work: you upload data, Pi handles the fine-tuning, and you access the resulting model through a hosted gateway for inference.
The early examples range widely. Actor runs an autonomous wheel loader that loads a dump truck in a commercial deployment in Utah, with no operator inside the machine. Almond’s dual-arm robot, Axol, deburred spacers used in its own assembly with a model developed after four days of iteration using the API.
The Loop Runs on Failures
Look at the three problems again. Each represents a different kind of failure, and, in our reading, each points to a different data need.
- A garment turned inside out is a variation problem. The robot needs examples of the same kind of object in states it may not have encountered before.
- An ingredient that slips out of a scoop is a physical-interaction problem. The demonstrations need to capture how to handle materials that behave differently.
- A part that lands in the wrong place is a precision problem. The data needs clear examples of correct placement, along with near-misses that still count as failures.
None of these is necessarily fixed by collecting more of the same. Someone has to examine a failed run, identify the kind of failure, and direct the next round of data collection toward that gap. Pi’s description puts this step at the center of the process. It is also the part an API cannot fully handle for you.
Why Does This Matter Now?
When a model and its training infrastructure become available as a service, they become easier to access, and just as easy for every other team. What remains specific to each team is its data and how well it understands its own failures.
A team that can determine that a grasp failed because the object’s weight shifted has a clearer idea of what to collect next. A team that can only record that the grasp failed may collect more of everything and hope for the best. And if similar failures are labeled differently from run to run, the next round of data collection may target the wrong problem.
What the Announcement Doesn’t Tell Us
It helps to keep the limits in view. Pi’s post provides no success rates, trial counts, or side-by-side comparisons. It says the latest model offers partners more data-efficient fine-tuning and improved capability, but provides no numbers to quantify those gains. Pi also describes the beta as early and notes network connectivity challenges for some partners using cloud-hosted inference. The three failure examples are presented as a pattern across partners, rather than being tied to named companies or quantified outcomes.
That doesn’t make the launch less interesting. It means the evidence so far consists of a reported pattern and a set of examples. We’d want independent results before drawing firm conclusions about how well the approach works.
A Practical Way to Read a Failure
For teams running their own version of this loop, a failed run is more useful when it is recorded consistently. A practical starting point:
- Task and success criteria. What was the robot trying to do, and what counted as success? Define the criteria before the run.
- Point of divergence. Where did the run go off track, not just how did it end?
- Likely cause. Was the problem related to perception, planning, control, or the physical environment?
- One-off or pattern. Does the same kind of failure recur across runs? Repeated failures can reveal where additional data is needed.
This reflects how we think about failure analysis. It is our practical framework, not a process that Pi explicitly describes in its announcement.
Labelix.ai’s Take
The most useful idea in this launch is the framing: improvement comes from learning from failures. That matches how we think about robotics data. Demonstrations help a robot get started. Understanding why it failed, consistently and in a form a team can act on, helps determine what to collect next.
That is the work behind failure analysis. It depends on two related practices: consistent annotation of the data going in, and policy evaluation against clear success criteria, so failures can be identified consistently. Designing test scenarios that surface those failures in the first place is a topic of its own, which we cover in our guide to benchmark design.
As model APIs make the training side easier to access, we expect more of the difference between teams to come from how well they collect, label, and learn from their data. We’ll be watching how Pi’s partners report results as the beta develops.
Send us your failed rollouts. Get back the reasons.
Start with recent failed and borderline rollouts from one policy. A dedicated Labelix.ai team drafts the failure taxonomy with your engineers, tags every rollout, and shows you the breakdown and the agreement numbers.
FAQs
What is the Pi API beta?
A service from Physical Intelligence that lets developers upload data, fine-tune its robot foundation models on infrastructure Pi manages, and run the resulting models on their own robots through hosted inference. It was announced on October 13, 2026.
What is robot failure analysis?
The practice of determining why a robot's run failed, where it went off track, and whether the likely cause involved perception, planning, control, or the environment. The findings help teams decide what data to collect or what to fix next.
Why do failures matter for robot training data?
Failures reveal where a model struggles. Targeted data addressing those gaps can be more useful than collecting additional examples of situations the robot already handles well.
Cindy writes about Physical AI, robotics, and the human data that teaches models to perceive and act, for Labelix.ai, an independent data foundry for robotics and multimodal AI.
Get the next one first
One sharp read a month on Physical AI and the data behind it.
