Quantum in the cloud.
Rented, not owned.

Quantum results are statistical. A circuit is executed many times — each execution is a shot — and the distribution of outcomes is the answer. That single fact shapes every pricing model in the market, and it is why quantum billing does not resemble cloud compute billing at all.

Per-shot, used by AWS Braket, charges a task fee plus a fee for each execution. Cost scales directly with how many shots your statistics require, which for a noisy device can be a lot. It makes small experiments genuinely cheap and makes precision expensive.

Per-minute, used by IBM Quantum, charges for time on the processor, typically metered in seconds with substantially different rates across access tiers. It rewards efficient circuits and punishes idle connections. IBM has also offered a free open plan on real hardware, which is where most people should start — check current availability.

Per-program, used by Azure Quantum, varies by hardware provider within the marketplace; some meter per gate operation, which makes circuit structure directly visible in the bill.

Indicative figures move constantly and we would rather not publish numbers that are wrong within a quarter. As of September 2026 the shape is: free tiers on real hardware exist and are usable; pay-as-you-go experimentation runs from single-digit to low-hundreds of currency units for a meaningful experiment; and sustained serious use is a subscription negotiated in the thousands per month. Check the provider's own pricing page before budgeting anything.

The binding constraint is not qubit count. It is circuit depth — how many operations you can apply before decoherence and accumulated gate error make the result indistinguishable from noise. On current hardware that number is modest, which means the algorithms that actually complete are shallow ones: variational circuits, small simulations, benchmark problems, and demonstrations.

The second constraint is queue time. Shared hardware means your job waits. For interactive work this is the difference between an afternoon and a week, and simulators — classical machines pretending to be quantum ones, up to around thirty qubits — are where most development sensibly happens. You debug on a simulator and spend hardware time only on runs that matter.

The honest summary for a business evaluating this: you can learn on it, you can benchmark on it, you can build genuine internal capability on it. You cannot currently put it in a production path and get an advantage over a classical machine, and the pages that follow explain why for the two applications most often proposed.