OpenVLA-7B API pricing: no rate card, so count the calls

OpenVLA-7B API pricing has no number to look up. No host publishes a rate for the base checkpoint, and the one per-call OpenVLA offer found today publishes no rate either, both checked on 26 October 2026. The price you can act on today is a rented GPU by the hour. Its design sets the rest: it returns one action per call, so your control rate sets the call count and the bill. This page works the per-call and per-robot-hour math for a model that returns a single action.

Last verified: 2026-10-26

What you are actually trying to price

OpenVLA-7B is the open vision-language-action model released in June 2024 by researchers at Stanford, UC Berkeley, Google DeepMind, and the Toyota Research Institute. The project page carries the release facts. Its paper lays out the build: a 7B model on a Prismatic backbone, with a fused DINOv2 and SigLIP vision encoder in front and a Llama 2 language model behind. Pre-training covered 970,000 episodes from the Open X-Embodiment datasets.

The model card states the output format: 7-DoF end-effector deltas, meaning position, rotation, and gripper. You must convert them back to real units for your own robot before they mean anything, and the normalization guide covers that step. Each dimension of the action is split into one of 256 bins. Those bins overwrite the last 256 tokens of the Llama vocabulary. One action comes out of the model as seven plain tokens. The capability record, the benchmarks, and the checkpoint list live on the model's own page: openvla-7b-hosted-availability.

One property of this checkpoint sets the price unit, and it is the opposite of the family around it. A call does not return a chunk of actions. It returns one action. The repo says so in its data-collection advice: "Collect at a control frequency around 5-10Hz. OpenVLA is not trained with action chunking, empirically the model struggles with high-frequency data." Later recipes in this family fix that by returning a run of actions per call. The base checkpoint does not, so your control rate sets its call count, and nothing else does.

Two names collide with the model in search results. The Belgian political party Open VLD takes the bare query on some engines, and the security scanner OpenVAS pollutes cost queries. A third collision is commercial, and it costs money. The family member with the fifty-action chunk turns up on the same result pages. Those two price differently, and the reason is chunk length.

The host census, checked 26 October 2026

People searching "openvla api pricing", "openvla 7b api cost", and "openvla hosted api" all want the same row: a hosted route, a billing unit, and a rate. Google's own AI Overview told that query on 25 October 2026 that OpenVLA has no official hosted public web API. The answer is right, but it is a search artifact, so this page checks the surfaces itself. Here is what each place that could take your money for this model actually offers, read on 26 October 2026.

Five more hosts could not be read today. Together answered 401, Groq answered 403, and Novita, Baseten, and Hyperbolic have no public model list at their published paths. This page makes no claim about those five; the claim covers the ten rows above.

The row that matters is the one where money changes hands. roboticinference.com serves four OpenVLA fine-tunes per call. The offer exists, and no rate card is published for it. Ask for the rate in writing before you build against it. The other rows are dead ends for a buyer with a budget.

Three notes on the table. First, the absence is dated and scoped to the surfaces named. Second, the meters in this market are not per call. The one public rate card in the table above meters input per million tokens and output per million actions. Its hour estimate rests on a 30 hertz loop of 108,000 actions. Third, OpenVLA is not on that card, so the two meters have never met for this model.

One unit note deserves its own line, because it decides what a call costs later. A per-action meter and a per-call meter are the same money for this model and different money for the chunked ones. OpenVLA-7B returns one action per call, so the two meters move together. Each chunked policy in the family bills once per run of actions, which is why the per-action rates in this market read so much lower than the per-call ones.

What self-hosting costs per call

With no route to buy, the price that exists is a rented card plus your time. Two numbers from the model decide which card you need: the memory it takes and the speed it reaches.

The paper settles both in one sentence:

"During inference, OpenVLA requires 15GB of GPU memory when loaded in bfloat16 precision (i.e., without quantization) and runs at approximately 6Hz on one NVIDIA RTX 4090 GPU (without compilation, speculative decoding, or other inference speed-up tricks)."

Read that as a floor. That same section gives the other two floors: 8-bit needs 10.2 GB of memory, and 4-bit needs 7.0 GB.

Hourly rates for the cards that matter, one named party, Secure Cloud tier, read 26 October 2026 on the RunPod pricing page. The page lists its cheaper Community tier first; the rates below are the Secure Cloud rows:

All amounts are United States dollars written as bare numerals. Each rate carries its party and its date. Rates move, so treat each one as a snapshot. The discount tiers, the pod and serverless split, and the account rates behind a quote have their own page: the account rate lane.

To turn an hourly rate into a call price you need one more input: the time one call takes on that card. Keep the math symbolic until you have measured it for your own setup.

Two formulas carry the whole thing. Each variable is named, and every number comes from the table above or from a measurement you take yourself.

cost per call       =  R x t / 3600
cost per robot hour =  R x f / m

R: hourly rate for the card, from the table above
t: seconds per call, which is 1 / m
f: the control rate your loop asks for, in hertz
m: the fastest rate the model reaches on that card, in hertz

Four setups you can actually rent, worked through the formula above. These are setups rather than a controlled experiment, because the card and the precision both differ from row to row.

The second row uses a third-party benchmark, the Yotta Labs VLA benchmark of 10 August 2026. It measures the model at 276.0 ms on an RTX 4090 and calls it "a strict single-step policy (chunk size 1)". Its own note says why the number matters for money: "this cost is paid on every forward pass with no amortization". The last column repeats each card's hourly rate, and that is the finding rather than a rounding artifact. At full duty a chunkless policy keeps the card busy for the whole hour, so an hour of robot motion costs the hourly rate. The rate you run at changes the robot's behaviour, not the bill.

One sensitivity line. The lowest-rate card on the list is the A5000, and it is also the one that makes the fewest calls. At 8-bit and 1.2 Hz it costs 0.0000625 per call against the 4090's 0.0000412. A slower call on a cheaper card is still a slower call, and an hour of that motion costs 0.27 against 0.89. The cheap card is not the cheap call. Each figure in that table is a floor at full duty, not a bill. Idle time, restarts, and your own engineering sit on top, and the deeper local-versus-hosted treatment is the VLA break-even guide.

Why one action per call sets the bill

A chunked policy returns a run of actions per call, so the call count is the frame rate divided by the chunk. OpenVLA-7B returns one action per call, so the call count is the frame rate itself.

calls per robot hour  =  3600 x f

f: the control rate your loop asks for, in hertz

Two things fall out of that table. The first is the multiplier. At the same per-call price, the base checkpoint needs 18,000 calls for a robot hour where a fifty-action chunk needs 2,160. A single action out of the base checkpoint costs about fifty times what the same action costs out of a chunk. The second is what a chunk buys. A chunked policy plans a run of motion in one pass and pays for that pass once. The base checkpoint cannot, so it asks the card for every single step.

Unit conversion has its own guide, which works the math for every meter in this market: the pricing units guide.

Here is the part that surprises people who arrive with a rental quote in hand. At full duty the hourly rate IS the cost per robot hour. 3,600 seconds of motion at 6 Hz is 21,600 calls. 21,600 calls at 6 Hz is exactly one hour of card time. The card bill for an hour of robot work is the hourly rate. Your run rate changes the robot's behaviour, not the bill. It changes the bill only when your loop asks for less than the card can deliver. Run at 5 Hz on a card that reaches 6 Hz, and the card is busy five sixths of the hour, so you pay five sixths of the rate. The measured card-side derivation for the sibling policies is on the robot inference cost report.

That is where the cheap card gets interesting. The lowest-rate card on the rental list is not the card the paper used. Its evaluation card was an A5000, and on it the 8-bit model runs at 1.2 Hz. The paper's words: "on the A5000 GPU we use for our evaluations, we can only run the model at 1.2Hz, which significantly changes the system dynamics compared to the training dataset for the 5Hz non-blocking controller used in the BridgeData V2 tasks." Four-bit on the same card reaches 3 Hz, which the paper calls closer to the dynamics of data collection. That section's table prices the choice in task success: bfloat16 scores 71.3 percent on the Bridge suite, 8-bit scores 58.1, and 4-bit scores 71.9.

So the choice of precision is a behaviour decision with a bill attached, not a bill decision. Going to 8-bit to fit the cheap card gives you a robot that acts several times slower than the data it was trained on. The paper measures the task-success cost in points.

The tuning bill, before any serving

Serving is not the only cost on the way to a policy that works on your robot. The paper's compute figures are worth reading as money. Pre-training took 64 A100 GPUs for 14 days, which the paper totals as 21,500 A100-hours. That one is behind you, because the checkpoint is free to download. The next one is not.

Full fine-tuning of the model on one task used 8 A100 GPUs for 5 to 15 hours. LoRA, the recipe the repo recommends, needs 10 to 15 hours on a single A100. The paper calls that an 8x reduction in compute. At the A100 rate above, one LoRA run on one task reads 17.90 to 26.85, and a full tune of one task reads 71.60 to 214.80. The repo's memory floors decide which of the two you can even start. A smaller card works with about 27 GB once you lower the batch size. The shipped LoRA command at its default batch size needs about 72 GB. A 24 GB card will serve the model and will not start the tune.

That is the shape of the whole bill for a team shipping on OpenVLA-7B. One setup cost you can read off a rate card today. The tuning cost reads off the same card. And the serving cost depends on a number only your own hardware can give you. The tuning side has its own guide, with the product math between a fine-tune and an evaluation: the fine-tune and evaluation product math guide.

The platform's written record

This platform keeps a written record for the openvla-oft model id on its action route. The facts of that record, as of 26 October 2026: the row sits in the platform's model data. Metering is per call. The rate is set. It is not on the public list, and this page quotes no live rate for it. Only listed rows render in the table below, and the models index is the live catalog. The base checkpoint has no row of its own, so the OpenVLA-7B class is not currently offered here. It carries no promise: a written record is not a launch.

Budgeting that record is math on 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, for the model you are calling
P:  per-call rate, read off the live table for a listed row
W:  wallet balance, the hard stop on spend

The C input comes from the call count table above for the base checkpoint, where it runs from 18,000 to 36,000 calls a robot hour. The chunked row's count is on its own page: the OpenVLA-OFT pricing guide. At a fixed per-call rate, the base checkpoint's 18,000 calls cost about eight times the 2,160 calls of a fifty-action chunk on the same robot hour. Each of those calls re-encodes a fresh camera frame.

The route itself is a published contract, so a client can be finished before any spend begins. POST /v1/action takes multipart form data with the fields model, instruction, state, and one or more image parts. The answer carries actions, the normalization block the card applied, and usage with the call count and the call's cost. A request that carries a field the route does not take answers 400 and names it, unknown_param. An empty prepaid wallet answers 402, credit_balance_exhausted. A model id that is not on the public list answers 404, model_not_found. Each answer, success or error, carries an x-request-id header. The full field list is on the action route page and in the run-action reference.

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

What to do now

1. Rent the card and measure your own seconds per call. Each rate on this page is a floor. Run the model on the card you would actually rent, time a hundred calls, and divide the hourly rate by that count. Nothing else in the chain changes the answer.
2. Choose the precision against the control rate, not against the hourly rate. The paper's own 8-bit result is a behaviour change, 1.2 Hz against a 5 Hz training controller. If your loop needs 5 Hz, the 1.2 Hz setup is not a cheaper robot.
3. Price the tuning bill once, before the serving bill. A LoRA run on one A100 is 10 to 15 hours, and the A100 rate is on the table above. That is a specific one-time figure per task, and it is the part you can settle before writing a control loop.
4. Write the client against the published contract. The request fields, the response fields, and the error codes are documented today, so the driver can be finished and tested before any spend begins. Listed rates render on the pricing page. You can sign up and create a key without a call from us, and the prepaid balance is the spend stop.

Frequently asked questions

Is there an OpenVLA-7B API?

Not a priced one. The authors ship weights, code, and a self-host serving script, with no product and no checkout. Checked on 26 October 2026: the hosted inference field is empty on the base checkpoint and on the six sibling checkpoints read today. A multi-provider router, Replicate, fal, Fireworks, and DeepInfra list no OpenVLA row at all. One robot API serves four OpenVLA fine-tunes per call and publishes no rate. Five more hosts could not be read today, so this answer covers the ten surfaces in the table above and nothing wider.

What does OpenVLA-7B cost per call?

One answer in three units. A rented card, named party and date, costs 0.27 to 0.89 per hour for the 24 GB tier on 26 October 2026. The paper puts the model at about 6 Hz on an RTX 4090, which works out to 0.0000412 in raw card time per call. A hosted per-call rate does not exist for this checkpoint. At any rate you find, one call buys one action, so the count comes from your control rate: 18,000 to 36,000 calls a robot hour.

Why does one action per call make OpenVLA-7B expensive to serve?

Because the call count is the control rate with no chunk to divide it. A fifty-action chunk needs 2,160 calls for a robot hour at 30 frames per second. The base checkpoint needs 18,000 at the repo's 5 Hz floor. At the same per-call price, that is about eight times the bill for the same hour of work, and about fifty times the price of a single action. A third-party benchmark dated 10 August 2026 measured the model at 276.0 ms on an RTX 4090. Its reason was plain: a strict single-step policy re-encodes a fresh camera frame on every forward pass, with no amortization.

What does it cost to fine-tune OpenVLA-7B?

LoRA, the recipe the repo recommends, takes 10 to 15 hours on one A100. At the A100 rate on the table above, one run on one task reads 17.90 to 26.85. A full tune of the same task used 8 A100 GPUs for 5 to 15 hours, which reads 71.60 to 214.80 at that rate. The memory floors decide which you can start at all. A smaller card works with about 27 GB once you lower the batch size, and the shipped LoRA command at its default batch size needs about 72 GB.

Is OpenVLA-7B free to use?

The weights and the code are free to download, and both carry an MIT license, so there is no royalty on serving them yourself. Those weights may inherit limits from the Llama 2 base model, and the repo says so in its own words. What you pay for is compute: the GPU hours to fine-tune, the GPU hours to serve, and your own engineering time.

The short version: no rate card, no host pricing the base checkpoint as of 26 October 2026, and a design that puts the whole bill on the call count. One action per call means your control rate is your invoice. Rent the card, measure your own seconds per call, and read the listed rates on the pricing page. Sign up to create a key and budget metered calls.

Last verified: 2026-10-26