Pricing

Prepaid credits. No subscription.

You buy credit in advance and runs spend it. There is no seat fee and no monthly minimum.

Credit packs

Three sizes, one dollar of credit per dollar paid

Prices are in US dollars before tax. Credit has no expiry date in the product today. Refunds and disputes are covered in the Terms.

Payment is handled by Stripe Checkout. Card details never reach us.

How a run is priced

A reserve first, the actual cost after

Each job kind has a maximum runtime and a rate per second of runtime. The numbers differ by kind and by GPU class, so the product shows them for the exact run you are about to submit instead of a single headline price.

  1. 1. Reserve. Submitting holds maximum runtime x rate from your credit. This is the worst case, so the run can never cost more than what was held.
  2. 2. Refuse early. If the reserve is more than your spendable credit, the run is refused (HTTP 402) before anything starts.
  3. 3. Settle. When the job ends, the hold becomes the actual cost and the rest is released. Until a job has settled, its reserve stays counted.

Before you run

Where you see the number

The reserve is shown before every run. Fine-tune jobs are reserved from the GPU provider's list price plus a container base rate and say so with their estimate; the older job kinds still use placeholder rates, and the product says so wherever it shows them. The reserve is a ceiling, not a quote: the actual cost is what the worker meters, and the estimate says when that is not measured.

  • In the console

    New run shows the estimated reservation from the server’s rates and checks it against your balance. New fine-tune and the evaluation on an adapter's page ask the estimate endpoint for the reserve and shows it before you submit.

  • From the API

    The estimate endpoint, POST /v1/estimates, returns the rate, the reserve, whether it would pass, and says plainly when an expected cost is not measured yet. API reference