pi 0.5 LIBERO checkpoint API pricing

A LIBERO report bought through a per-call API is priced in calls, and the call count turns on one number: how many returned actions your client executes before it asks again. The documented protocol executes 10 per call. On that setting, the 500-episode report this site measured on a rented card, 1.93 in compute over 47.18 hours, holds 17,250 calls, and those calls cost 51.75 at the written-record rate for the pi05-libero model id. The card beat the meter by about 27 times, and the reason is not the rate. A card-hour meter prices the whole clock, including the simulator rebuilds that eat most of it. A per-call meter prices the policy and leaves the simulator on your machine. This page prices both paths for this one checkpoint, names every input, and lists the exact strings the run types. Third-party figures were read on 26 October 2026. The measured figures carry their own date, 2026-10-10.

The price in one line

The written record, in plain words. The pi05-libero row sits in the platform's model data. Metering is per call. The rate is set. The model is not on the public list, and no date is attached to that. Nothing answers under the id today: the route returns a plain 404 for it, and the models list omits it. Only listed rows render in the table below, and the models index is the live catalog. A written record is not a launch.

The rate itself stays inside the machine table. In the arithmetic below it is the named variable P. You can recover it from a figure this site already publishes.

P               =  6.48 per robot hour / 2,160 calls per robot hour

report actions  =  125 x (280 + 280 + 300 + 520)   =  172,500
protocol calls  =  172,500 / 10                    =  17,250
report cost     =  17,250 x P                      =  51.75

The 6.48 anchor is this site's published robot-hour figure for the pi05 id, derived in the open. That basis is 2,160 calls per robot hour at the written-record rate, the same rate this page's fence carries. Divide 6.48 by 2,160 and you hold P. The check inverts, too: 51.75 divided by 17,250 hands the same P back. A money figure nobody can invert is not a number. It is a mood.

The checkpoint you are pricing

Three public artifacts carry this tune. The publisher's repository calls the model fine-tuned for the LIBERO benchmark, meant for inference. LeRobot's port page describes the same tune converted and refined. Here is the menu.

In the publisher's run the tune scored 98.8 on spatial, 98.2 on object, 98.0 on goal, and 92.4 on the long suite, for the 96.85 average. With 6,000 extra steps, the port scored 97.0, 99.0, 98.0, and 96.0, for 97.5. Both scores sit on the LeRobot LIBERO guide and the openpi results table. Both describe simulation only. The port card was read today: 26,314 downloads, and the card's own inference switch reads false, because it is weights, not a service.

One pricing fact belongs on this page and nowhere else. On the platform's written record, the LIBERO row is not priced differently from the base. The three pi 0.5 rows, pi05, pi05-droid, and pi05-libero, carry the same per-call rate. The tune you send does not change the bill. What changes the bill is how you drive it, which is the next four sections.

Who serves it by API, checked today

Every party a buyer would check, read on 26 October 2026:

Read the last column as one finding. On every public page read today, no per-call price for this checkpoint appears anywhere. The honest version of that sentence stops at public pages. One platform's catalog sits behind an invitation key. What it prices is not visible from outside. This page says so rather than guess.

The abstract.inc row deserves one relation, because their estimate is priced on a unit this site also uses. Their 0.85 estimate covers one hour of a 30 Hz control loop, 108,000 actions, the same action-hour behind this site's 2,160-call robot hour. The report priced on this page holds 172,500 actions, about 1.6 of those hours. Their card prices the base model. The LIBERO row is absent, so the crossed cell stays dashed rather than multiplied out.

The meter: one call, one bill

Field by field, the route contract is published on the action route page and the run-action reference. The short version follows, because the budget consequences live in the details. The route is POST /v1/action. Its body is a multipart form with four required fields: model, instruction, state, and one or more image parts. State is a JSON array of numbers; this arm sends eight values. Back come three fields. First comes actions, the chunk of actuator deltas. Second comes normalization, the statistics the model applied, passed through untouched. Third comes usage, the call count with the call's cost. One served request is one billed call. A request refused before it is served bills nothing.

The details a budget-minded client cares about. The route refuses any field it does not take, with 400 unknown_param naming the field. Both horizon and chunk_size are refused. Chunk length is the model's own property, not a request knob. An empty prepaid wallet returns 402 credit_balance_exhausted. An id that is not on the public list returns 404 model_not_found, which is what pi05-libero returns today. The 25 MiB body cap returns 413 before any connection is made. Saturation relays as 429 rate_limited, and that turn is unbilled. And the retry law: Idempotency-Key is accepted and logged, with no replay. A retrying client pays twice.

The trap that turns this meter expensive is old and well documented. Point the run at the base port instead of the finetuned one. The score reads zero while every call still bills. A mismatched normalization raises ValueError: QUANTILES normalization mode requires q01 and q99 stats on the first batch. The crash is loud, at least. Still, the episodes before you notice are on the bill. The quantile crash guide owns that failure family, and the bill-shock guide owns the wallet floors and the runaway-loop guards.

From calls to episodes

Two inputs fix the call count. The first is the step cap: how many environment steps an episode may run. The two documented conventions disagree on one suite, so both are named.

On the left is the TASK_SUITE_MAX_STEPS table from the LeRobot source. On the right is the publisher's own example client. The measured card report this page prices ran on the LeRobot caps. Those are the caps in every number below. A fifth suite, libero_90, holds 90 more tasks outside the four reported suites, and published runs do not report it (the benchmark's own repository, which prints the 130-task count and the LIBERO-90/LIBERO-10 split). After every reset the environment also takes 10 settling steps. Those steps are zero actions. They are not counted against the cap, and they are not billable calls. They are your clock, never your bill.

The second input is the lever. How many returned actions your client executes before it asks again is your setting, not the model's property. It is documented three different ways.

Per episode, the same three rows cost 0.207, 0.1035, and 0.02175. The factor of ten across the column is the finding. The bill for the identical report moves tenfold on a client setting. At 50 per call the counts round up per episode. The 520-step suite needs 11 calls of 50 actions, and the last one is partly unspent. The protocol setting of 10 divides every cap exactly.

From episodes to a report

The measured anchor, from the evaluation-cost report on this site, dated 2026-10-10. One 500-episode report, 125 episodes over each of the four suites. Wall time 47.18 hours on one rented 24 GB card. Rate basis 0.041 per card-hour, a below-list batch rate at a named community cloud. Compute cost 1.9344, written 1.93 in that page's title. Result 482 successes of 500, 96.4 percent. The clock per episode was about 5.8 minutes, and the rollout itself was 23 to 83 seconds of it: the simulator rebuild between episodes takes the rest. The published comparability shape is smaller, 400 episodes at 10 per task, about 37.7 hours, which that page prices at 3.40 on the lowest public card tier.

Set the metered numbers beside the card numbers, same report, same five paths:

Two honesty notes belong on this table. First, the per-call rows still need a machine that runs the simulator. The reset is about 5.8 minutes per episode of that machine's clock, whichever path you buy. Per wall hour, the protocol setting runs about 1.10 over the measured 47.18-hour wall. Second, the motion itself is small. The report holds 172,500 actions, about 1.6 robot hours at the site's 108,000-action hour, stretched across 47 hours of wall. A LIBERO report is 47 hours of clock and under 2 hours of motion. Rent by the hour and you buy the clock. Pay by the call and you buy only the motion. That motion carries a unit price that has to compete with a whole rented card.

That is the whole comparison in one paragraph. The card at its entry public tier costs 4.25 for the report. The meter at the protocol setting costs 51.75. That is about 12 times the entry public card, and about 27 times the account-rate number. Even at the checkpoint's own shipped config, 10.875 is about 2.6 times the entry public card. On benchmark math alone, at every scale measured here, the card wins. The 400-episode comparability shape lands the same way: 8.70 at the shipped config and 41.40 at the protocol setting, against 1.55 on the account-rate card and 3.40 at the lowest public tier.

Which path to buy

The decision rules, honestly drawn from the table above.

1. A full benchmark report: rent the card. The clock dominates a report and the card prices the clock. This is not close, at any setting documented above.
2. A short check on a machine you already run: buy calls. A 40-episode smoke test costs about 4.14 in calls at the protocol setting. On a rented card at the lowest public tier the same 3.9 hours cost about 0.35. The card still wins if you would rent anyway. The calls win when the machine is already there. That means a laptop driving the simulator, a CI job, or a real arm whose loop you do not want to hang off a GPU you own. Calls buy exactly the policy slice, no card rental, no idle time, no setup.
3. Match the checkpoint and the preprocessing before spending anything. The served id must be the row you scored locally. The base port scores zero where the finetuned port scores 97.5, and both bill identically per call. The normalization must match the checkpoint's own statistics, or the arm moves wrong without an error. Average over seeds before quoting a score, and treat any simulation score as a simulation claim.

The one rule that saves the most money is older than any of this. Print the episode plan before the long run. On one pinned library version, a request for 500 episodes counted per suite and delivered 2,000. On a meter with no replay, a mistake of that size bills four times the intended report.

The strings you will type

The reference index, quoted exactly as each source spells it. API side first:

Local evaluation side, the LeRobot command surface:

The publisher's docker workflow, from the openpi README:

Frequently asked questions

What does a LIBERO report cost through a per-call API?

It depends on one client setting, and the page prices all three documented settings. At the protocol's 10 actions per call, a 500-episode report holds 17,250 calls and costs 51.75 at the written-record rate. At the checkpoint's shipped 50, it holds 3,625 calls and costs 10.875. At the publisher's client default of 5, it holds 34,500 calls and costs 103.50. The rate itself renders only in the machine pricing table on this page.

What does one episode cost?

At the protocol setting, 0.1035 per episode on average across the four suites. At the shipped config, 0.02175. At the publisher's client setting, 0.207. The long suite runs 520 steps against the short suites' 280 to 300. Its episodes cost more calls than the average in every row.

Which meter suits a LIBERO benchmark?

The rented card, and it is not close. A report is 47 hours of clock and about 1.6 robot hours of motion. A meter that prices the clock therefore beats a meter that prices the motion, at every rate on this page. The per-call meter wins when the machine running the loop already exists and you want no card at all. Think short checks, CI, or a real arm.

Is the pi 0.5 LIBERO checkpoint on the public list here?

No. The row sits in the platform's model data with its rate set, and it is not on the public list as of 26 October 2026. Nothing answers under the id today: the route returns a plain 404 and the models list omits it. The models index is the live catalog, and the machine table on this page renders only listed rows.

What does the actions-per-call setting actually change?

Only the bill, and by a factor of ten across the documented settings. The model returns its chunk; your client decides how much of it to execute before asking again. On this platform's route the chunk length is the model's own property: horizon and chunk_size are refused as request fields with 400 unknown_param. The executed-count lever stays yours, in your client.

What can the API not do for a LIBERO run?

Three things. It cannot run the simulator: the environment, the resets, and the 5.8-minute-per-episode rebuild stay on your machine. It cannot pick your checkpoint or fix your preprocessing. The base port bills the same as the finetuned one and scores zero. And it cannot make a retry free. Idempotency-Key is logged with no replay, so a retrying client pays twice.

The budget pages around this one

Neighboring numbers each have an owner on this site. For the measured card report and its 1.93, read the evaluation-cost page. The 6.48-per-robot-hour derivation and the 2,160-call conversion sit on the cost derivation and the unit glossary. For the family rate picture, there is the pi 0.5 API pricing page, and for the unit conversion worked both ways, the per-call versus per-robot-hour guide. On the protocol side, suites and checkpoints and leaderboard reading, the companion is the LIBERO evaluation guide. Listed rates for listed rows render on the pricing page, never in prose. Sign up to create a key when a metered path fits your run. Every third-party figure on this page was read on 26 October 2026. The measured figures carry 2026-10-10. The written record is a record, not a launch.

Last verified: 2026-10-26