Marin Ivezic
Three questions decide whether a first quantum project runs cleanly or burns its budget in a fortnight. What are you buying, who are you buying it from, and what happens between pressing submit and getting results back. A single variational chemistry run can reach six million circuit executions, so the answers reach the invoice quickly.
This piece walks the access path end to end, from credentials to returned counts. It assumes you are comfortable with cloud infrastructure and new to quantum hardware, and it assumes no physics beyond one idea: a quantum processor returns probabilistic results, so you have to run the same thing repeatedly to learn anything from it.
What You Are Actually Renting
Providers sell scheduled time on a quantum processor, sliced into units, and those units set the economics of everything you build on top.
A quantum processing unit (QPU) is the chip that holds the qubits, plus the control electronics and refrigeration that keep it working. Everything else in the stack is classical. When you buy access, you are buying scheduled use of that QPU together with the software that gets your program onto it.
Three units of sale appear on almost every price list.
A shot is one execution of one circuit. Measuring a qubit yields a 0 or a 1, and the outcome is probabilistic, so a single execution tells you almost nothing. You run the same circuit many times and read the distribution of results. A thousand shots per circuit is a small run and ten thousand is unremarkable.
A task, called a job on some platforms, is one submission. It is a circuit or a batch of circuits, sent to a named device with a requested shot count. Providers commonly charge a fixed fee per task and a separate per-shot fee on top of it.
Reserved time is a block of exclusive access, sold by the hour or the half hour. Inside the block your work runs back to back, nobody else’s jobs interleave with yours, and the queue effectively disappears.
None of this resembles a CPU-hour. A quantum processor does not run your program for as long as the program needs. It runs a fixed circuit a fixed number of times, and the wall-clock cost of that is set by the hardware rather than by the size of your problem. Two teams solving very different problems on the same device with the same shot count pay roughly the same amount.
Quantum annealers bill differently again. Annealing is a separate model of computation, aimed at optimization problems rather than general circuits, and D-Wave sells anneal time in microseconds per read plus hybrid solver time in seconds. If your pilot is an optimization pilot, the unit you are budgeting is not a shot at all, and the two price lists are not directly comparable. We flag this early in our own material because teams routinely build a cost model against one and then switch hardware model mid-project.
The Path a Job Takes
Understanding the units is half the job. The other half is knowing what happens to your circuit after you submit it, because three of those steps can change your results without changing your code.
Authentication. You hold an API token or a cloud identity. On aggregator platforms the token is your normal cloud credential, and quantum access becomes another permission on an existing role.
Circuit construction. You build a circuit in a software development kit (SDK), typically in Python. Qiskit, Cirq, PennyLane and the Braket SDK all produce the same kind of object: a sequence of gates applied to numbered qubits.
Transpilation. This is the step architects underestimate. Your circuit is written in abstract gates on abstract qubits. The device supports a small native gate set and a fixed connectivity graph, meaning each physical qubit can interact directly with only a few neighbours. The compiler rewrites your gates into native ones and maps your circuit qubits onto physical qubits. Where two qubits need to interact and are not neighbours, it inserts SWAP operations to shuffle states across the chip. Circuit depth, the number of sequential gate layers, grows as a result. Depth is expensive, since qubits lose their quantum state over time and every extra layer adds error.
Queueing. On shared public devices the wait is usually the longest part of the job. Execution is measured in seconds and the queue is not.
Execution against a calibration. Providers recalibrate their devices on a schedule and publish per-qubit and per-gate error rates that change from day to day. The same circuit submitted on Tuesday and Thursday can return measurably different distributions. Pull the calibration snapshot with your results and store the two together, or your experiment isn’t reproducible.
Results. What comes back is a histogram of bitstrings and their counts, sometimes with error mitigation applied. Error mitigation is post-processing that estimates and corrects for known noise. It costs additional shots.
The beamline comparison
The nearest familiar analogue is not a cloud virtual machine. It is a shared scientific instrument: a synchrotron beamline, a research reactor, an electron microscope with a booking calendar.
The working habits around such instruments transfer almost intact. Sample preparation happens off-site, so the session is spent measuring rather than setting up. Time is applied for and granted in blocks. The instrument drifts, gets recalibrated between sessions, and every published result carries the run conditions alongside the data. Nobody who has waited eight months for beam time turns up without a plan for the session.
Teams that treat a QPU this way get further than teams treating it as an elastic compute resource. Prepare and validate everything on a simulator, submit work that is ready, and record the conditions. We build that sequence into our lab exercises deliberately, and then drop the analogy, because in every other respect a QPU behaves like a network service and the comparison stops paying.
Three Ways In
Access arrives through one of three patterns. Most organizations end up using two of them.
Direct from the hardware builder
IBM Quantum, D-Wave’s Leap service, IQM’s Resonance and the direct offerings from IonQ, Quantinuum, Pasqal, QuEra and Rigetti all put you in a first-party relationship with the company that built the machine.
You get the earliest access to new devices, the deepest level of control, and in some cases pulse-level programming beneath the gate abstraction. You also get the vendor’s own SDK dialect, a separate account, and a separate bill for each vendor you work with. For research teams pushing hardware behaviour, first-party access is usually the only option that goes deep enough.
Through a general-purpose cloud
Amazon Braket and Microsoft Azure Quantum aggregate third-party hardware behind one interface. One identity system, one bill, one SDK, several vendors’ machines underneath.
The procurement advantage is real and it is the main reason to choose this route. Adding a second hardware vendor becomes a configuration change rather than a contract negotiation, and comparing two device families on the same circuit becomes a morning’s work. The trade is a layer of abstraction between you and the device, plus a roster that moves. Devices are added and retired on the aggregator’s schedule, not yours, and the list you design against this quarter will differ from the list a year out.
Through a software abstraction layer
PennyLane, Classiq, Strangeworks and similar platforms sit above the hardware entirely. Some offer hardware-agnostic circuit construction. Others accept a problem rather than a circuit, formulate it themselves, and decide which backend to send it to.
Portability is the draw, and for teams whose expertise is in the application domain rather than in quantum computing it is a reasonable starting point. The cost is visibility. Transpilation choices drive both accuracy and price, and a layer that hides them also hides the two levers you most need when a pilot comes in over budget.
Where Latency Starts to Cost Money
Most near-term quantum work is hybrid. A classical optimizer proposes a set of parameters, the quantum device evaluates a cost function for those parameters, and the loop repeats. The variational quantum eigensolver (VQE), used for molecular ground states, works this way. So does the quantum approximate optimization algorithm (QAOA), used for combinatorial problems.
Put the classical half on a laptop and the quantum half on a shared device in another region, and the loop pays a network round trip plus a fresh queue wait on every iteration. Two hundred iterations of a few seconds each becomes a scheduling problem rather than a compute problem, and a job that should finish overnight can take a week of calendar time.
There are three answers, and mature teams use all of them.
Run the classical half inside the provider’s environment. IBM’s Qiskit Runtime, Braket Hybrid Jobs and Azure Quantum’s session model all exist to hold a classical process next to the QPU so the loop closes without leaving the data centre. Second, batch aggressively: send many circuits in one task rather than one circuit per task, which cuts both round trips and per-task fees. Third, reserve time when the loop genuinely needs to run uninterrupted.
Tighter integration than that is still bespoke engineering. Supercomputing centres are the ones doing it. JUNIQ at the Jülich Supercomputing Centre and the Helmi system in Finland both put quantum devices alongside classical clusters and expose them through the scheduling systems researchers already use. That work is building the middleware that a general enterprise will eventually buy. Today it is a research programme rather than a product, and we would not plan a corporate roadmap around scheduler-level quantum integration before the standards settle.
A Worked Shot Budget
Numbers make the economics concrete. Take a small VQE run with these assumptions.
A twelve-qubit ansatz with sixty variational parameters. The ansatz is the parameterized circuit template the optimizer tunes, and the parameter count is one of the things that sets how many iterations the optimizer needs. A gradient-free optimizer that converges in roughly two hundred iterations. A Hamiltonian, the mathematical object that encodes the molecule’s energy, split into eight measurement groups, so each iteration needs eight distinct circuits. Four thousand shots per circuit.
Per iteration: 8 circuits × 4,000 shots = 32,000 shots. Full run: 200 iterations × 32,000 = 6,400,000 shots.
Now the billing. If the eight circuits go up as one batched task per iteration, the run is 200 tasks. Submitted one circuit at a time, it is 1,600 tasks. The bill is (tasks × task fee) + (shots × shot fee), and on any current price list the shot term dominates by a wide margin. Batching saves real money on the fixed term, and it is still not the dominant cost.
The shot count sets the budget, and there is one lever on it. Shot noise, the statistical error from finite sampling, falls as one over the square root of the number of shots. Halving shots per circuit from 4,000 to 2,000 halves the bill and multiplies the statistical error by about 1.4. Quadrupling shots to 16,000 quadruples the bill and halves the error. That relationship is unforgiving, and it means precision is something you buy in increments of four.
If you take one number away from this article, take the shot count. It is the single figure that turns an algorithm choice into a budget, and it is the first thing we ask a participant to calculate before they touch hardware.
One more variable belongs in the model. Gate operations run far faster on superconducting hardware than on trapped-ion hardware, and shot throughput broadly follows. The same 6.4 million shots can be a manageable session on one platform and an unmanageable one on another, at similar per-shot pricing. Device selection is a throughput decision as much as a fidelity decision.
When Shared Access Stops Working
Cloud access is the right default and it isn’t universal. Four things push organizations off the public queue.
Data classification. The decision usually turns on policy rather than on trust. Whether your data can leave the boundary at all is a compliance question with a written answer, and it gets settled before anyone evaluates a provider.
Throughput. A team running one experiment a month has a different problem from a team running jobs every day. Sustained high-frequency use is where reserved capacity starts to compete with pay-per-use on cost.
Loop latency. Some algorithms need feedback inside milliseconds. Real-time error correction is the clearest case. A public network round trip cannot meet that, and no amount of batching fixes it.
Sovereignty and procurement rules. Several national programmes now require that certain computation happens on domestic infrastructure, which rules out a foreign-hosted service regardless of its technical merits.
The escalation path runs roughly in cost order. A private network link into the provider’s region removes the public internet. A dedicated reservation removes the queue. A provider-managed system installed at your site removes the data transfer while leaving operations with the vendor. Buying a system outright removes the vendor from day-to-day operations and hands you a facilities problem: refrigeration, vibration isolation, and staff who can recalibrate hardware.
At the far end sits the open-architecture route, assembling a system from separately sourced components. QuantWare sells processors, Bluefors sells dilution refrigerators, Quantum Machines sells control electronics, and several national laboratories have built working systems this way. The appeal is avoiding a single-vendor commitment on strategic infrastructure. The obstacle is that no standard operating layer exists across quantum hardware, so integration is genuine engineering rather than assembly. Whether this path is cheaper than a turnkey system is not yet settled, and anyone claiming otherwise is extrapolating from classical computing rather than reporting a result.
One clarification belongs here, because it distorts more procurement conversations than any other. Advertised qubit counts are physical qubits, the noisy hardware devices. A logical qubit is an error-corrected abstraction built from many physical ones. Vendor roadmaps mix the two units freely, and comparing a physical count from one company against a logical count from another produces a meaningless answer. Ask which unit a number is in, and ask whether a capability was announced or demonstrated.
Decisions Worth Making Before You Write Circuits
Six choices are cheap now and expensive later.
Abstract the backend from day one. Wrap device selection behind your own interface. Devices get retired, and a pilot with a hard-coded backend name becomes a rewrite instead of a configuration change.
Make shots a budget line. Put the shot count in the same review as cloud spend. It is the only quantum cost figure that a finance team can reason about without training.
Version the transpiled circuit, not only the source. Compiler versions change and the mapping onto physical qubits changes with them. A source circuit alone will not reproduce last quarter’s numbers.
Store calibration data with every result. A results file without the device state that produced it is an anecdote.
Settle the data boundary before the pilot, not during it. Run the first experiments on synthetic or non-sensitive data. That keeps the compliance review off the project’s critical path.
Assume the device you start on will be retired. Design the comparison tooling early so that moving to a new backend produces a measurement rather than an argument.
Where This Leads
The access model described here is what quantum computing looks like for almost everyone through the rest of this decade. Owning hardware remains a decision for national laboratories, a handful of research-heavy corporations, and organizations with a classification requirement that leaves no alternative. Everyone else rents, and renting well is a specific skill: shot budgeting, transpilation awareness, queue-aware architecture, and enough hardware literacy to read a specification sheet without being sold to.
That skill set is learnable in weeks rather than years, and it is mostly engineering rather than physics. Marin Ivezic’s longer technical treatment of Quantum-as-a-Service on PostQuantum.com goes deeper on the provider comparison if you want the vendor-by-vendor view.
For the structured version, with lab work against real hardware and a credential at the end, Quantum Academy runs a quantum systems integration track built on exactly this material. It covers the access path, the cost model, hybrid workflow design, and the on-premises decision in full, and it assumes the background this article has assumed throughout: an experienced infrastructure professional, no physics degree required.