Pricing

You pay for the task-seconds you use, metered from live market rates for the capacity class you request. Every submit response includes summary.billing_estimate — the authoritative quote for that job — and unused hold is released at settlement.

There are no subscriptions, minimum commitments, or idle charges. Credits are prepaid; a job only starts against a funded balance, so you can never be surprised by an open-ended bill.

Indicative rates

Capacity is priced per machine-hour on a live market, so rates move with supply. The ranges below were observed on live capacity on 2026-07-12 and are refreshed periodically — they are orientation, not a rate card. The billing_estimate in your submit response is what actually governs your job.

Multi-GPU capacity scales roughly linearly per GPU. You select capacity by declaring requirements (cpu, memory_mb, gpu_count, gpu_memory_mb) or a named preset from GET /api/v1/presets — the platform fills the request from live market capacity and meters what your tasks actually use.

Worked examples

Illustrations using mid-range rates — your submit response shows the real numbers before anything runs.

1. Fan-out data processing (CPU). 1,000 tasks × 30 seconds each on 16-core capacity is ~8.3 machine-hours. At ~$0.15/hr that is ≈ $1.25 for the whole batch.

2. Hyperparameter sweep (GPU). A sweep job with 9 parameter combinations × 20 minutes each on 24 GB GPU capacity is 3 GPU-hours. At ~$0.35/hr that is ≈ $1.05.

3. Training run (datacenter GPU). 4 hours on one 80 GB GPU at ~$3.00/GPU-hr is ≈ $12.

How billing works

The one-minute version — the full contract lives in Billing.

1. Fund — prepaid credits, topped up with USDC via x402 or MPP ($0.01 – $10,000 per top-up). Agents can do this autonomously.
2. Submit — the response carries summary.billing_estimate and a refundable hold is reserved covering the initial attempt plus your max_retries budget. Underfunded submits get 402 with a ready-to-pay shortfall quote — fund and retry the same request.
3. Run — usage is metered per task-second while tasks execute. timeout_s caps each task’s runtime cost; queue time is never charged.
4. Settle — at terminal state the actual metered cost is captured and the unused hold is released automatically. In the rare case actual use exceeds the hold, the difference is recorded as an overrun debit on the ledger.

Other numbers that matter:

• Project init is free but requires $5.00 available balance as a funding floor.
• Artifact storage and transfer have no separate charge today; retained artifacts count against a 100 GiB per-account quota until deleted.
• Infrastructure failures (lost workers, OOM kills) requeue without consuming your retry budget — you don’t pay extra for our misses.

Cost visibility

• GET /api/v1/account/balance — credits, holds, available funds.
• GET /api/v1/account/ledger — every settled credit and debit.
• GET /api/v1/jobs/:id — per-job billing_estimate, billing_hold, and post-terminal billing_settlement (actual cost, captured, released) inside summary.

Pricing FAQs

Can a job overspend my balance? No open-ended spend: jobs are admitted only when the estimated hold fits your available balance, and the hold bounds the reservation up front.

What happens to the unused part of the hold? Released automatically at settlement — you keep it as available credits.

Is queue time billed? No. Only task runtime is metered.

Do prices change? Yes — capacity is market-priced, which is why the table above is indicative. Your per-job billing_estimate is computed at submit time and is the number to trust.