OpenVLA-OFT API pricing: what a call costs when no API exists

No official OpenVLA-OFT API exists to price, and as of 26 October 2026 no marketplace sells hosted access to any of its checkpoints. The authors ship weights, fine-tuning code, and a self-host REST script. This guide shows the dated checks behind the absence. It covers what the published path costs on rented GPUs, how hourly rates convert to a per-call cost, and how per-call pricing for robot models works. It ends with the platform's own written record for the openvla-oft model id.

Last verified: 2026-10-26

What you are actually trying to price

OpenVLA-OFT is a fine-tuning recipe for OpenVLA, the open 7B vision-language-action model, plus the policies that recipe produces. The paper is by Kim, Finn, and Liang at Stanford, February 2025. It reports the LIBERO four-suite average rising from 76.5 to 97.1 percent. It also reports action generation running 26 times faster than the base model. The code and all five public checkpoints are MIT licensed on the project page and the repository. For the capability record, benchmarks, and checkpoint guide, the model's own page is here: openvla-oft.

One property of this model decides its pricing unit. A call to it does not return tokens. It returns an action chunk: a short run of motor commands for the next fraction of a second, computed in one pass. The chunk length is a property of the training setup, fixed in the repository's constants file, not a per-request dial. Any API price for this model is therefore a price per call. A call is worth a different amount of motion on each robot platform. That distinction drives every number below.

The absence, marketplace by marketplace

Search results for "openvla api" autocomplete into "openvla api pricing" and "openvla api cost". Google's own overview tells searchers no official hosted public web API exists. That is correct. Here is what each place that looks like a seller actually offers, checked on 26 October 2026.

Two honest notes about this table. First, the absence is dated. Each row was read on the date above. Any seller could appear later, so every row carries its check. Second, one search nuisance compounds the confusion: the security scanner OpenVAS pollutes "cost to run openvla" style queries. If a result talks about vulnerability scanning, it is the wrong product with a near-identical name.

The one thing the absence is not: a license problem. Nothing about OpenVLA-OFT is gated. The MIT license on the code and every checkpoint permits commercial serving without royalties. What is missing is the unglamorous part, a provider who has done the serving work and published a rate. Building that is exactly what a hosted product is.

The authors' serving script: the published API shape

The closest thing to an official OpenVLA-OFT API is a file in the base OpenVLA repository: vla-scripts/deploy.py. It is worth reading even if you never run it. It defines the minimum shape of a served VLA. Every commercial contract differs from it in a few predictable ways.

What the script gives you, verbatim from its header:

• A REST server for OpenVLA models over the HF AutoClass API, the server half only.
• Dependencies: uvicorn, fastapi, and json-numpy on the server; requests and json-numpy on the client.
• One endpoint, POST /act, taking a JSON body with an image array and an instruction string, on port 8000.
• A suggested tunnel (ssh -L 8000:localhost:8000) when the server is not on the open web.

What it does not give you: authentication, per-call metering, a wallet, retry semantics, or a model id you can swap. It is a research deployment aid. Running it well still means you manage the GPU, the process, and the norm statistics yourself. The statistics part is not cosmetic. Every checkpoint carries normalization numbers that must match your robot. The repository's own evaluation code names them with an unnorm key such as libero_spatial_no_noops.

A metered product contract wraps that same idea with account machinery. This platform's published action route is POST /v1/action, multipart form data in, JSON out. The request fields are model, instruction, state, and one or more image parts. The response carries three fields. actions is the chunk. normalization is the statistics block that was applied, passed through untouched. usage is the call count and the call's cost. Refusals have stable codes. A request with a field the route does not take returns 400 unknown_param, naming the field. An empty prepaid wallet returns 402 credit_balance_exhausted. A model id that is not on the public list returns 404 model_not_found. Every response, success or error, carries an x-request-id header for support. The full field-by-field contract is on the action route page. The machine-derived listing is in the run-action reference.

What a call costs when you rent the card

With no API to buy, the real price of OpenVLA-OFT today is a rented GPU plus your time. Two numbers from the authors decide which GPU: memory to serve, and memory to fine-tune.

The cliff: a 24 GB GPU serves every setup but cannot start even a batch-size-1 fine-tune. So the cost path forks. Tuning means renting 32 GB and up. Serving fits the entry 24 GB tier.

Hourly rates, named parties, read 26 October 2026:

Sources: the RunPod pricing page, and Spheron's own deployment guide. Spheron dates its figures as of 26 October 2026. Rates move. Treat any rate you find as a snapshot with a date, including these.

To turn hours into calls, you need one more input: the time a single call takes on the card. The paper's Table II gives the official figure for one A100. The full recipe single-camera runs at 109.7 generations per second, which is 72.9 ms per call. On the community GGUF port, a benchmark table read 26 October 2026 shows about 233 ms per call on an RTX 3090. 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 configuration

One sensitivity line. At an A100 rate of 2.72 per hour and the paper's 72.9 ms, raw card time is about 0.000055 per call. At a 3090 at 0.5 per hour and the community 233 ms, it is about 0.000032. Those are floor numbers at full duty. Idle time, restarts, and the provider's margin sit on top. That gap is what a per-call API price has to justify. It is also why per-call prices for robot models sit far above raw card time. The full local-versus-hosted treatment, with amortization and electricity, is the VLA break-even guide.

Per call, per token, per hour: the units of robot API pricing

Chat APIs price per million tokens. Robot action APIs, when they exist, price per call. GPU renters pay per hour. These three units never compare directly. Much of the confusion in "api cost" searches is a unit error.

The call count comes from your control loop and the model's chunk length. The repository's constants file fixes the chunk per platform, verbatim: NUM_ACTIONS_CHUNK is 8 for LIBERO (with ACTION_DIM 7), 25 for ALOHA (14 dimensions, both arms), and 5 for Bridge. Your loop calls once per chunk:

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

Read that table as a budget, not a benchmark. A short chunk is more reactive and more expensive at any fixed per-call rate. A long chunk gives smoother motion for fewer calls. The same call budget at different chunk lengths can differ by three times. The deeper treatment of the per-call and per-robot-hour units, with the worked cases, is the pricing units guide.

For scale on what does publish: the robot APIs with public rate cards in late October 2026 meter tokens, not calls. Their models speak the chat interface. The worked example is the Gemini Robotics rate card guide. Physical Intelligence's pi API remains waitlisted and unpriced. No public per-call rate card exists for OpenVLA-OFT anywhere.

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. The model 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. This is the same state the model's own page records, in the same words. It carries no promise: a written record is not a launch.

Budgeting that record is arithmetic 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, 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 wallet floor is the point of the shape. An unattended robot loop cannot open 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. Serve today, self-hosted. Rent a 24 GB GPU from any provider above, pull a checkpoint, for example the libero-spatial tune, and run the authors' script. Your costs are the hourly rate plus your setup time.
2. Fine-tune, then serve. Rent 32 GB or larger for the tune, then drop to the 24 GB serving tier. The evaluation cost side of that path is its own subject: the evaluation cost report.
3. Write the client against the published contract. The four form fields and the three response fields are fixed and documented today, so your driver can be finished and tested before any per-call spend begins. The models index is the live catalog.

When you are ready to budget metered calls, the current listed rates are always on the pricing page. You can sign up and create a key without a call from us.

Frequently asked questions

Is there an OpenVLA-OFT API?

No official one. The Stanford team behind the recipe released weights, code, and a self-host REST script, and no hosted product. Checked on 26 October 2026: Hugging Face lists zero inference providers for the checkpoints. The Inferix page is a weights mirror with no deployment. No marketplace sells access. If a seller appears, this page's absence table is the part that goes stale first; check the date on it.

How much does OpenVLA-OFT cost to run per hour?

The serving envelope is 15.9 to 18.0 GB of GPU memory depending on cameras. The entry 24 GB tier fits. On 26 October 2026 that tier rented at 0.27 to 0.89 per hour on RunPod. Fine-tuning is the expensive phase. The minimum is 25.6 GB, past a 24 GB card. Recommended sizes start at 44.1 GB.

How would per-call pricing be billed?

The pattern this platform's action route publishes: one served request bills one call. A refused request bills nothing. The response's usage field reports the call's cost every time. The prepaid wallet balance is the spend stop. Rates for listed models render on the pricing page; this page's table renders listed rows only.

Why do token prices not tell me what a robot call costs?

Because a robot call does not measure tokens. It returns an action chunk whose length the model's training setup fixes: 8 steps on LIBERO, 25 on ALOHA, 5 on Bridge. Two models at the same per-million-token price cost different amounts per robot hour on the same arm. Convert everything to calls per robot hour first, then apply a per-call price.

Is OpenVLA-OFT free?

The license is MIT on the code and all five public checkpoints. The weights, and the right to serve them commercially, cost nothing. What you pay for is compute: the GPU hours to fine-tune, the GPU or API calls to serve, and your engineering time. For the base model's own pricing page, see the OpenVLA-7B API pricing guide.

The short version: no API to price today. The published self-host path costs a rented 24 GB GPU by the hour. You can compute the per-call budget now from your chunk length. Listed rates live on the pricing page. Sign up to create a key and budget metered calls.

Last verified: 2026-10-26