pi 0.5 DROID checkpoint API pricing: no host prices it, the two licenses, and the cost per robot hour

No host prices the pi 0.5 DROID checkpoint. There is no per-call rate card for it on any marketplace, no published rate on the model maker's own beta, and no row on a public catalog. The weights are open, so the cost you can size today is a rented GPU hour and the training compute behind it. Two licenses apply, and they are not the same license. The checkpoint returns 15 actions per call, not the 50 the base model returns, so one robot hour holds 7,200 calls instead of 2,160. This page checks every path and prices the hour.

Last verified: 2026-10-26

What you are actually trying to price

The pi 0.5 DROID checkpoint is a tuned copy of pi 0.5, the open-weights vision-language-action model from Physical Intelligence. It sits in the checkpoint table in the openpi repository as pi05_droid, with the asset path gs://openpi-assets/checkpoints/pi05_droid and a use case of inference and further fine-tuning. The table's own pitch for it is fast inference and good language-following.

The tune is a fine-tune on DROID, the Distributed Robot Interaction Dataset. The DROID paper records 76,000 demonstration trajectories, 350 hours of interaction, 564 scenes, 86 tasks, 52 buildings, 18 robots, 50 data collectors and 13 institutions, collected over 12 months. Each episode carries three synchronized RGB camera streams, camera calibration, depth, and a natural language instruction. The project page carries the same counts and the hardware list.

The rig is the point, and it is not a brand name. It is a Franka Panda arm with 7 degrees of freedom, two adjustable ZED 2 stereo cameras, a wrist-mounted ZED Mini stereo camera, and an Oculus Quest 2 headset with controllers for teleoperation, all on a portable height-adjustable desk. The checkpoint reads two of those views: one external camera, chosen left or right, plus the wrist camera. The serving instructions pass the external camera as a flag and leave the choice to you.

One number decides the price, and it is not in the marketing copy. The openpi config file gives this checkpoint an action horizon of 15, so one call returns 15 joint commands. The base model's own config defaults to 50. A call therefore buys a third of the motion at the same rate. The horizon is a training-time setting. It is not a request knob, and sending more frames does not change it.

The base model's numbers live on the family page: pi05. On the DROID side, the rig, the camera contract and the latency band live on the model's own page: pi05-droid.

The first-party path: the Pi API beta

The only official hosted path from the model maker opened on 13 October 2026. The announcement describes a loop, not an endpoint. You upload robot data. The maker runs the fine-tuning on compute they manage, and the tuned model then runs on your robot through their hosted inference. Their partner examples work that way. The post admits rough edges, including network trouble at some sites.

Read in full on 26 October 2026, both pages carry no pricing content at all. The post carries no rate, no billing unit, and no free tier terms. Nor does the application form. On that form the team says it is starting small and onboarding in batches. It asks who would train the policy and what they have done before, names ACT, diffusion policy and pi 0.5 in its checklist, and asks how many hours of teleoperation data you have. It never asks what you would pay, and it never states a price.

Two things a buyer on that list should know. First, the beta does not name this checkpoint. The post points to pi 0 and pi 0.5 as the foundation models behind the effort. Then it says the API serves their latest and most capable models. The DROID tune is not in that list, so a place on the waitlist is not a route to this checkpoint. Second, getting in is an application, not a checkout. Onboarding in batches means no self-serve spend today. The full walkthrough of the form and the access timeline is its own guide: the Physical Intelligence API waitlist.

Where a buyer would look, checked 26 October 2026

On 25 October 2026 a full census for this checkpoint found no competitor pricing page anywhere. That finding still holds. Here is every place a buyer would check, read on 26 October 2026.

The one priced row in that table is for the base model, not for this checkpoint. Its numbers live on the base model's page: pi 0.5 API pricing.

Two of the three searches behind this page return something else entirely. Check Point sells security appliances and publishes endpoint packages. Factory sells a coding agent named Droid and publishes monthly tiers. Both own the word. Android's F-Droid owns the rest of it. If a search for this checkpoint lands on a firewall price sheet, that is the collision, not the answer.

The lesson in that table is the dates. The classic marketplaces carry nothing today, and any sentence on the web that says nobody hosts this model is a sentence with a shelf life. Check the date on the claim before you trust it, including this one.

Self-hosting the open weights: what a card hour costs

Without a priced first-party endpoint, the open weights are the path you can buy today. The memory floors come from the repository itself. Read them as of 26 October 2026:

Every 24 GB card serves inference and starts a LoRA fine-tune, which needs more than 22.5 GB. A full fine-tune needs more than 70 GB, so it rents the 80 GB tier.

Hourly rates for the 24 GB tier, named party, read 26 October 2026 on the RunPod pricing page. The RTX 4090 sits at 0.89 per hour on secure cloud and 0.34 on community cloud. For the A5000 the pair reads 0.27 and 0.16, and for the 3090 it reads 0.50 and 0.22. Rates move. Every rate here is a snapshot with a date.

To turn hours into calls you need one more input, the time one call takes on the card. The pi 0 paper publishes a timing table for the same card and the same flow-matching design: 73 milliseconds on board, 86 with a network hop, on an RTX 4090. The publisher's own DROID troubleshooting table gives the round trip for this checkpoint instead. Half a second to a full second per chunk is normal there, and the maker asks for a cable rather than Wi-Fi on the control laptop. The shorter chunk of this checkpoint changes the per-call figure, and the publisher does not publish one. With a per-call time in hand, the raw card cost per call is:

GPU cost per call  =  R x t / 3600

R: hourly rate for the card, from the table above
t: seconds per call, from a benchmark you trust for your setup

One sensitivity line. At the 4090 secure rate of 0.89 per hour and the 86 millisecond figure, raw card time is about 0.000021 per call. At 7,200 calls per robot hour that is about 0.15 against a 0.89 rental hour. That number is a floor at full duty, not a bill. Idle time, restarts, and your own engineering sit on top of it. The deeper local-versus-hosted treatment, with amortization, is the VLA break-even guide.

Training on the full DROID dataset is the other end of the bill. The publisher's training notes give the numbers: about 1.8 TB of disk for the DROID dataset in RLDS form, and about two days on eight H100 GPUs for their config, 100k iterations at batch 256, roughly one epoch. Starting from PaliGemma instead of pi 0 initialization needs about five days on the same eight cards. At the H100 PCIe secure rate of 2.89 per hour, one eight-card pass for two days is about 1,110 in rental. The same notes say plainly that low-rank adapter training did worse on this path. There is also an action-space wrinkle. The released tune was trained on joint velocity actions. The maker's own recipe moved to joint positions, because joint velocities do not simulate well. Know which space your driver consumes.

The license position, in three parts, all read today. The openpi repository code is under the Apache License 2.0. That license covers the code and the weights the repository ships. The DROID dataset itself is under CC BY 4.0, as stated in the dataset paper. That license attaches to the data the tune was trained on, not to the checkpoint. The PaliGemma tokenizer sits behind a license gate on the Hub, so you accept its terms and sign in before your first run. None of this blocks commercial testing. A buyer should read both licenses before shipping a product on this checkpoint.

Per call, per action, per hour: the units

Robot API pricing arrives in three units, and most confusion in api cost searches comes from a unit error. This platform's action lane bills per call. The abstract.inc card bills per million tokens in and per million actions out. GPU vendors bill per hour. None of these compare until you convert.

Everything starts with the chunk. This checkpoint emits 15 actions per call, fixed by its training setup and not by a request. The base checkpoint emits 50. Your control loop decides how often it calls:

calls per robot hour  =  3600 x frame rate / chunk length

The first row is the SO-arm convention used throughout this site, 2,160 calls and 108,000 actions per robot hour. The second row is this checkpoint at the same frame rate. Both rows cover the same motion, 108,000 actions. The call count is three times higher, because the chunk is three times shorter. Divide any hourly quote by the call count and you recover the per-call rate. It also works in reverse. A two-way conversion is what makes an hourly figure checkable instead of magical. The full treatment of both units, with worked cases for every meter on the market, is the pricing units guide.

The platform's written record

This platform keeps a written record for the pi 0.5 family on its action route. There is one row each for pi05, pi05-droid and pi05-libero. Those are the base and the two public checkpoint tunes. The facts of that record, as of 26 October 2026: the rows sit in the platform's model data. Metering is per call. The rate is set. The models are not on the public list, and no date is attached to that. Only listed rows render in the table below, and the models index is the live catalog. This is the same state the model's own page records, in the same words. A written record is not a launch.

Budgeting that record is arithmetic. It takes three named inputs:

monthly spend  =  Rh x C x P
worst case     =  the prepaid wallet balance W

Rh: robot hours per month
C:  calls per robot hour, from the chunk table above
P:  per-call rate, read off the live table for a listed row
W:  wallet balance, the hard stop on spend

The numeric form for this checkpoint, at the SO-arm frame rate and its own chunk length. At 7,200 calls per robot hour, the written-record rate for the pi05-droid model id yields 21.60 per robot hour. The base model id at 2,160 calls yields 6.48 per robot hour on the same derivation, published separately. The same per-call rate buys a third of the motion per call, so an hourly bill built on the base checkpoint's chunk lands at a third of the real figure. Run it forward from there. A robot working ten hours a month spends about 216. A 160-hour work month runs about 3,460. The full derivation for the base model, with the measured card economics behind it, is the robot inference cost report.

The wallet floor is the point. An unattended robot loop cannot open a credit line. A refused call bills nothing. The general argument for prepaid floors under robot and agent workloads, with documented runaway cases, is the API bill shock guide.

What to do now

1. Budget on the chunk, not the call. The number that moves your hourly bill is 15, not 50. Any spreadsheet that starts from the base checkpoint's call count has to be rebuilt before it means anything.
2. Price both paths with dates. The rented card and the platform's per-call row are both readable today. Listed rates render on the pricing page, and the two can be set side by side.
3. Read both licenses before you build. The code is Apache 2.0. The DROID data is CC BY 4.0. A product that ships on this checkpoint has to answer both.
4. Write your client against a published contract. This platform's action route documents every field: POST /v1/action, multipart form data in, three fields back, with the call count and the cost returned on every reply. The run-action reference lists every field. A driver can be finished and tested before any spend begins. A sign up creates a key without a call from us, and the prepaid balance is the spend stop.

Frequently asked questions

What does the pi 0.5 DROID checkpoint cost?

Nothing on the market prices it. A full check on 26 October 2026 found no rate card, no per-call price, and no hosted listing for this checkpoint on Hugging Face, Replicate, fal, DeepInfra, abstract.inc or roboticinference.com. The model maker's own beta is waitlisted and carries no published rate. What you can size today is a rented GPU hour if you serve it yourself, the eight H100 days behind a full DROID training run, and whatever a hosted lane charges when one exists for this checkpoint. A written record for the pi05-droid model id sets a per-call rate, and listed rates render on the pricing page.

Is the pi 0.5 DROID checkpoint free to use?

Downloading the weights is free. So is the code, which sits under Apache 2.0. The data it was trained on is a separate obligation under CC BY 4.0. Compute is not free. A card hour, a training run, and your own setup work are the bill. Free to download is not the same as free to ship.

How good is the pi 0.5 DROID checkpoint?

Two published records, both dated. On the RoboArena leaderboard, read 26 October 2026, the pi05_droid policy scores 1608 over 745 evaluations, with a standard deviation of 30.7. That is fifth of 24 policies, and the highest of the publisher's DROID checkpoints on that board. The publisher calls it their strongest generalist DROID policy, on that benchmark. On the real rig, the MolmoAct2 paper reports pi 0.5 DROID at a 45.2 percent average success rate over five zero-shot DROID tasks at 15 trials each, against 87.1 percent for MolmoAct2 DROID on the same tasks. Both numbers carry their own source and date. A 45 percent average is a starting point, not a finished policy.

Why does this checkpoint need three times as many calls as the base model?

Because its action chunk is 15 commands, not 50. The horizon is a training-time setting in the openpi config. A shorter chunk means more calls for the same motion. At 30 frames per second the base checkpoint needs 2,160 calls per robot hour and this one needs 7,200, for the same 108,000 actions. The chunk is not a request knob, so you cannot trade it back at serving time.

Can I fine-tune pi 0.5 on my own robot data instead?

Yes, and most buyers should. The publisher's recipe has a path for it. The checkpoint table lists this checkpoint's use case as inference and further fine-tuning, so a custom dataset is a supported route. Record on a rig shaped like the DROID setup. Convert the recordings to the format the training config expects, and fine-tune from the base checkpoint. The full DROID dataset is a much larger job, about 1.8 TB of disk and about two days on eight H100 GPUs per pass. The base checkpoint's own page covers the base model side, and the pi 0.5 DROID model page covers the rig, the cameras, and the action space.

The short version: no host prices this checkpoint today, the code is Apache 2.0 and the data is CC BY 4.0, the chunk is 15 commands, so one robot hour holds 7,200 calls, and a written record with a set rate exists for the model id. Listed rates render on the pricing page. A sign up creates a key and a budget for metered calls.

Last verified: 2026-10-26