Physical Intelligence opens Pi API beta applications

Physical Intelligence announced its Pi API beta on October 13. Developers can upload robot data, train adapted models on infrastructure the company manages and obtain predictions through hosted inference.

The application page says onboarding starts small and proceeds in batches. Applying does not provide immediate access. The reviewed announcement and application offer no public price, guaranteed hardware list, minimum data requirement or admission timetable.

For a robotics team, the important question is how much work moves off its own infrastructure and how much remains at the robot. Access to a capable model can simplify one part of a project while leaving data quality, integration and operational testing as substantial engineering jobs.

What developers would actually do

The announced workflow connects demonstration collection, training, robot testing and further data collection informed by failures. Physical Intelligence describes partners iterating independently, including Almond using its Axol robot to deburr assembly spacers after four days of API experimentation.

A useful pilot should begin with one bounded task and an agreed definition of completion. Picking up a part is different from placing it accurately, releasing it cleanly and returning to a state where the next cycle can begin. Record the whole job rather than treating the most impressive movement as the outcome.

Keep a stable evaluation set separate from demonstrations used for adaptation. Include ordinary variations in object position, lighting and starting configuration. Compare successive policies against the same conditions, then add a second set of unfamiliar cases. That makes it easier to see whether an apparent improvement is repeatable or merely reflects easier trials.

Count human assistance as part of performance. A policy that succeeds after repeated resets can still be useful for research, but its operating cost differs from one that recovers without intervention. Log failed attempts, recovery time and damaged or misplaced objects alongside successful completions.

Check the robot setup before planning a rollout

The application asks about robot embodiments, available robots, operator demonstration hours, planned simulation data and team experience. It also asks for success criteria. These questions describe information applicants should prepare. They do not establish published admission thresholds.

The announcement shows work ranging from heavy machinery to manipulation, but those examples are not a universal compatibility guarantee.

Before committing an integration schedule, ask which observations and action representations the service expects. Clarify camera inputs, coordinate frames, control interfaces and how the robot reports its state. A matching product name alone would be a weak compatibility test if the cameras, gripper or control configuration differ from those used during adaptation.

Teams should also clarify who diagnoses a failed run. A data conversion problem, a model error and an actuator fault can look similar from a short recording. Preserving the relevant observations, commands and timing information makes the next engineering decision more useful than simply requesting another training run.

Hosted inference makes connectivity part of the test

Physical Intelligence reports that most showcased applications used cloud inference and that some encountered connectivity challenges.

The application offers cloud, local and combined deployment preferences. A local option in a questionnaire does not establish a supported local deployment feature.

For a pilot, measure elapsed time from capturing an observation to receiving a usable command under realistic network conditions. Average response time alone can hide occasional long delays. Ask how the integration handles stale responses, temporary outages and reconnection, and what the robot does while it waits. These are deployment questions, not documented Pi API specifications.

There is a useful architectural comparison in Google DeepMind’s 2025 introduction of Gemini Robotics On Device. Google described local execution independent of a data network and interfaces to safety critical controllers. That illustrates why inference location and motion supervision deserve separate consideration. It does not establish a performance ranking against Pi.

A production decision should therefore include review of the complete robot system. Model outputs should not be mistaken for a safety certification. Teams need to establish the operating limits, supervision and stopping behavior appropriate to their equipment and workplace before allowing an experimental policy to perform unsupervised work.

The research code is a separate access route

Physical Intelligence’s openpi repository documents model checkpoints, adaptation and inference examples, including ALOHA and DROID configurations. It warns that provided task specific checkpoints may not work on a different setup. Those examples describe the research software and its models. They are not a supported hardware catalog or service contract for the new beta.

The distinction matters when estimating effort. Running research code puts environment setup, compute and serving in the team’s hands. A managed service changes that division of responsibility. Developers should compare the actual work and control offered by each route rather than assume that instructions for one transfer directly to the other.

The API announcement does not assign a new version name to the model it offers.

What would make the beta valuable

The strongest evidence would be a documented improvement on a team’s own task at an acceptable total operating cost. That includes preparation and supervision time as well as model usage. Ask about data retention, access controls, model updates and whether an earlier policy can remain available while its replacement is evaluated.

An application is a sensible next step for a team that can describe its robot and a measurable pilot. A production commitment requires more information. The useful milestone is a repeatable process for improving real work, with failures visible enough to guide the next experiment.

For a related model announcement, ByteForward’s Natura 1 coverage examines the separate challenges of dexterous hardware and evaluation.

Archival Robonaut photograph illustrating robotic hands. Image courtesy of NASA.