Chapter 39: Quantum Cloud Platforms

The previous four chapters asked what quantum computers can do. This one asks what it costs to use one, and the answer is not about qubits.

A 4,096-shot Bell-state job occupies the device for 6.92 milliseconds. Everything else — the queue, the scheduling, the calibration cycle, the billing — is what you are actually buying.

⚠️ Common Pitfall — 6.92 or 6.93? Both, and the difference is instructive.

§39.2's table reads 6.93 ms, computed from the scheduler's unrounded circuit duration. Every figure after it — this sentence, the utilization table, the billing comparison — reads 6.92 ms, because example-02 takes the duration from the printed table, where it appears as 1.69 μs, and $1.69 \times 10^{-6} \times 4096 = 6.9222$ ms.

A 0.14% gap, and it is the width of a rounding multiplied by four thousand. Nothing here is wrong: each script is a faithful report of its own inputs. But re-deriving from a printed figure is the most common way a correct measurement becomes a slightly incorrect one downstream, and in a chapter about reproducibility it is worth doing once in public rather than pretending it does not happen. When you quote this book's numbers, quote the table.

And the bill for identical work differs by more than three orders of magnitude depending only on how the provider counts.

A note on what is measured here. This environment has no provider credentials, so queue times in this chapter are not measured — they are stated as structural facts with representative values, and labelled where they appear. Circuit durations, calibration spreads, and layout fidelities are measured, from real backend calibration data. Prices are published list rates that change; what is durable is the structure, which is the chapter's actual subject.

39.1 What you are buying

Four ways to reach a quantum computer:

The aggregators are the interesting case, because they make hardware from different physical modalities look interchangeable behind a uniform API — and §39.5 measures how badly that intuition fails at the invoice.

What the uniform API does not make uniform

The submission call is genuinely portable. run(circuit, shots=4096) means the same thing on a superconducting chip and on a trapped-ion machine, and that is a real engineering achievement. What the call does not carry across is everything that determines the number on the invoice.

Four things change underneath and none of them appears in the signature:

Connectivity. The device §39.2 measures is heavy-hex. Every qubit has at most three neighbours:

   fake_torino    133 qubits   150 couplers
   qubit degree   1: 5 qubits   2: 89 qubits   3: 39 qubits

A trapped-ion machine has all-to-all coupling. On an all-to-all device the entire 2.03× layout spread of §39.6 cannot occur, because there is no routing to vary — any pair of qubits is one gate apart. The variance §39.6 measures is not a property of the circuit. It is a property of the graph the circuit was poured into.

Native gate set. This device's basis is cz, sx, rz, x. A two-qubit gate you write as swap becomes three czs and six sxs, which is why §39.6's routing overhead multiplies the way it does.

Gate duration. §39.2's cz runs in 68–184 ns. Trapped-ion two-qubit gates are orders of magnitude slower, which is exactly why the pricing models diverge: a per-minute price on a slow device and a per-shot price on a fast one are pricing opposite ends of the same trade.

The billing unit. Which is §39.4, and is the only one of the four that changes your answer by three orders of magnitude.

So portability is real at the source level and false at the cost level. Chapter 18 showed that circuits transfer between frameworks; this chapter is the reminder that transferring a circuit is not the same as transferring a workload, because the workload's cost was tuned against a device that the new one does not resemble. Case Study 39.1 is that mistake, made by a competent team, costing 3.7× an annual budget.

🔀 In Another Framework: every SDK has a job handle, and the handle is the reproducibility record.

The naming differs and the concept does not. Qiskit's Runtime returns a job object with an ID; Braket (Chapter 17) returns a QuantumTask identified by an ARN; PennyLane (Chapter 16) wraps a remote device and hands back whatever the underlying plugin's handle is; Q# (Chapter 15) submits through Azure Quantum and gets a job ID back.

In every case that handle is the only durable pointer to the calibration state your circuit actually ran against — which makes it §39.8's most important field, and the one people throw away because it looks like a transport detail rather than a scientific one.

The framework-portability lesson of Part III has an addendum here: the circuit is portable, the result's provenance is not. Each provider records it in its own format, and none of them will record it for you.

39.2 What a circuit costs the device

Circuit duration comes from the backend target's instruction durations, which are calibration data rather than estimates. On a 133-qubit heavy-hex device:

   cz          68.0 - 184.0 ns          measure   1560.0 ns
   sx          32.0 -  64.0 ns          reset     1600.0 - 1848.0 ns
   rz           0.0 ns (virtual)

Scheduling four representative circuits with alap and reading off the duration:

   circuit                     2q gates   depth   duration us   @4096 shots
   Bell                               2       8          1.69       6.93 ms
   GHZ-10                             9      40          2.49      10.21 ms
   QFT-8                            137     252         10.55      43.20 ms
   EfficientSU2-12 (3 reps)          33      69          3.22      13.19 ms

A 4,096-shot job occupies the device for between 7 and 43 milliseconds.

For comparison, the same jobs on a local state-vector simulator on one laptop core:

   Bell                            21.7 ms (4,096 shots)
   GHZ-10                          73.7 ms (4,096 shots)
   QFT-8                           26.0 ms (4,096 shots)

The local simulator's wall clock is the same order of magnitude as the quantum device's execution time. Both are tens of milliseconds — the simulator figures jitter by a factor of two or so between runs, which is itself the point: nothing here is the bottleneck. Everything that makes hardware feel slow happens around the execution.

Where the microseconds actually go

Take the Bell circuit apart with the numbers already on the page. It is 1.69 µs long and measure costs 1,560 ns:

   Bell total                 1,690 ns
   measure                    1,560 ns      92.3% of the circuit
   everything else               130 ns

The 130 ns left over has to cover one sx and one cz. Their quoted ranges are 32–64 ns and 68–184 ns, so the residual sits comfortably inside the 100–248 ns window those two gates can produce. (It is not an exact multiple of dt, which tells you the 1.69 µs is a three-significant-figure display of something slightly off round — the arithmetic is a consistency check, not a decomposition.)

Readout is 92% of a Bell circuit. Scale that to the job:

   4,096-shot Bell job        6.92 ms total
   readout portion            6.39 ms

Six of the seven milliseconds this chapter opens with are the measurement, not the entanglement. That single fact reorganizes a lot of intuition. A team trying to make a shallow circuit cheaper by removing gates is optimizing 8% of the duration. There is no gate-level change to a two-qubit circuit that moves the number, because the number is a readout integration window set by the physics of dispersive measurement and by how confidently the electronics must distinguish two resonator states.

This is also why §39.4's per-shot model is not obviously irrational. A per-shot price is roughly a readout price, and on shallow circuits readout is most of what the device does for you. It stops being reasonable when circuits get deep, which is precisely the regime the per-minute model is built for.

⚙️ Under the Transpiler: every duration on this device is an integer multiple of dt.

dt = 4 × 10⁻⁹ s is the control-electronics sample period — the smallest unit of time the waveform generator can address. Check every duration the chapter quotes against it:

text cz 68 ns / 4 ns = 17 measure 1,560 ns / 4 ns = 390 cz 184 ns / 4 ns = 46 reset 1,600 ns / 4 ns = 400 sx 32 ns / 4 ns = 8 reset 1,848 ns / 4 ns = 462 sx 64 ns / 4 ns = 16 rz 0 ns / 4 ns = 0

All integers. Scheduling is not continuous-time optimization; it is integer arithmetic on a grid. When ALAPScheduleAnalysis returns a start time it returns it in units of dt, and the code that produced §39.2's table multiplies by dt to get seconds — which is why backend.target.dt appears in the duration function at all.

The practical consequence: you cannot shave 10 ns off a gate. Durations quantize, and a "faster" pulse that does not cross a 4 ns boundary is free of charge and free of benefit.

📐 Math Aside: duration tracks depth, not two-qubit gate count.

§39.2's table invites the wrong model. QFT-8 has 4.15× the two-qubit gates of EfficientSU2-12 but only 3.28× the duration. If duration were proportional to gate count those would match. Normalize the table both ways:

text circuit 2q depth duration us ns per 2q gate ns per layer Bell 2 8 1.69 845.0 211.2 GHZ-10 9 40 2.49 276.7 62.2 QFT-8 137 252 10.55 77.0 41.9 EfficientSU2-12 33 69 3.22 97.6 46.7

The "ns per two-qubit gate" column spans 11× and is useless. The "ns per layer" column collapses to 41.9 and 46.7 for the two deep circuits — an 11% spread, and both values sit between the sx duration and the cz duration, which is what a layer of a scheduled circuit is made of.

The reason is that a schedule is a critical path, not a sum. Gates on disjoint qubits execute simultaneously, so a circuit's duration is

$$ T \approx \sum_{\ell=1}^{D} \max_{g \in \ell} \, t_g $$

— the sum over $D$ layers of the slowest gate in each layer — not $\sum_g t_g$ over all gates. Gate count enters only through its effect on depth.

Bell and GHZ-10 break the pattern (211.2 and 62.2 ns per layer) for the reason above: their layer count is small enough that the single 1,560 ns readout layer dominates the average. Subtract the readout and every circuit in the table lands in the same tens-of-nanoseconds-per-layer band.

This matters for pricing. Under a per-minute model you are billed for depth. Under a per-shot model you are billed for shots. Chapter 28's transpiler work reduces gate count, which reduces depth, which reduces the per-minute bill and does nothing at all to the per-shot bill — an asymmetry §39.4 turns into money.

🗝️ Version Note: these durations used to live somewhere else.

Before Qiskit 2.0, instruction timing came from the pulse layer: backend.defaults(), an instruction_schedule_map, and per-instruction Schedule objects you could inspect gate by gate. qiskit.pulse was removed in Qiskit 2.0, along with add_calibration, .calibrations, backend.defaults, instruction_schedule_map and drive_channel.

Durations now come from backend.target — target[op][qubits].duration — which is the calibration data reduced to what the transpiler needs. QuantumCircuit.duration is also deprecated in Qiskit 2.x, so the code behind §39.2's table runs ALAPScheduleAnalysis explicitly and reads the last instruction's end time out of property_set["node_start_time"].

Tutorials written against Qiskit 1.x will not run, and the failure is an AttributeError on backend.defaults rather than anything that hints at the actual change. Chapter 31 documents the same removal from the timing side.

39.3 The queue is the product

Put the 6.92 ms next to the turnaround a user experiences. Queue values here are representative, not measured:

   device busy   6.92 ms, queue 30 seconds  -> utilization 2.31e-04  (    4,335x wall clock)
   device busy   6.92 ms, queue 5 minutes   -> utilization 2.31e-05  (   43,340x wall clock)
   device busy   6.92 ms, queue 1 hour      -> utilization 1.92e-06  (  520,064x wall clock)
   device busy   6.92 ms, queue 8 hours     -> utilization 2.40e-07  (4,160,504x wall clock)

The device is not the bottleneck. At a five-minute queue you are waiting 43,000 times longer than you compute, and the quantum processor spends 99.998% of your job's lifetime doing something for somebody else.

This reframes almost every optimization in Part V. Chapter 28 reduced circuit depth; Chapter 29 improved layout; Chapter 31 fought decoherence. All of them make the 7 milliseconds better and none of them touch the five minutes — which is correct, because those chapters were optimizing fidelity, and this chapter is about throughput. The point is that they are different problems with different levers, and a team that conflates them will optimize the wrong one.

⚠️ Common Pitfall: batching is the highest-leverage optimization on a cloud platform, and it is not a quantum technique.

If the queue dominates, then submitting 100 circuits in one job rather than 100 jobs is worth more than any transpiler setting. This is why the primitives layer has session and batch modes (§39.7), and why the first question about a slow quantum workflow should be "how many jobs?" rather than "how deep is the circuit?"

📐 Math Aside: utilization, and the identity that makes the table redundant.

Let $t_d$ be device time and $t_q$ queue time. Utilization is the share of your job's lifetime the device spends on it:

$$ U = \frac{t_d}{t_d + t_q} $$

and the wall-clock multiple — how much longer the job takes than it computes — is

$$ M = \frac{t_d + t_q}{t_d} $$

These are reciprocals. $U = 1/M$ exactly, which is why every row of §39.3's table carries the same information twice. Check it on the five-minute row: $1/43{,}340 = 2.307 \times 10^{-5}$, which is the $2.31 \times 10^{-5}$ printed beside it.

When $t_q \gg t_d$ — which holds by four orders of magnitude here — the formula degenerates usefully:

$$ U \approx \frac{t_d}{t_q}, \qquad M \approx \frac{t_q}{t_d} $$

So utilization does not depend on the circuit at all in this regime; it depends on the ratio of two numbers you control separately. Making the circuit 2× shorter doubles $U$ and changes your wall clock by 3.5 ms out of five minutes.

Invert it to ask what queue a given utilization requires: $t_q = t_d(1/U - 1)$. For a 4,096-shot Bell job at 6.92 ms:

text U = 50% -> queue must be under 6.92 ms U = 10% -> queue must be under 62.30 ms

For the device to be even half-busy on your behalf, the queue would have to be shorter than the job itself. No shared-access platform can offer that, and none claims to. This is not a flaw in the platforms; it is what "shared" means.

What a five-minute queue tells you about the device

The utilization number is about you. Turn it around and it says something about the provider, and the inference is worth making explicitly because it is usually made wrongly.

If the queue is 300 seconds deep and every queued job were a 6.92 ms Bell job, then a device running back-to-back at full occupancy would have

$$ \frac{300\ \text{s}}{6.92\ \text{ms}} \approx 43{,}300 $$

jobs ahead of you. That is a testable implication, and it has exactly two branches:

Either the queue really is that deep — in which case the platform is heavily oversubscribed and the device is close to fully utilized, from the provider's side, at the same moment it is 0.002% utilized from yours. Both statements are true. Utilization is not a property of the device; it is a property of whose clock you are reading.

Or the queue is not compute-bound, which is more likely, and the 300 seconds is mostly not other people's circuits. It is per-job setup, control-electronics reconfiguration, calibration windows, fair-share scheduling that deliberately interleaves accounts, and reservation blocks. In that case the device is idle for much of your wait and no amount of aggregate demand would fill it.

This chapter cannot tell you which — that would require measured queue data this environment has no credentials to obtain. But the two branches recommend opposite actions. If the queue is compute-bound, paying for reserved capacity buys you a real resource. If it is overhead-bound, reserved capacity buys you a device that will still spend most of its time not running your circuits, and the money is better spent on batching, which is free.

The diagnostic is cheap and nobody runs it: submit the same trivial job at many hours of the day across a week and look at the shape of the wait distribution, not its mean. A compute-bound queue produces a smooth, load-following distribution. An overhead-bound queue produces clusters — everything lands just after a calibration boundary. Exercise 39.11 is that experiment, and it needs credentials.

📊 What the Numbers Say: 2.31 × 10⁻⁵ is not a complaint.

The instinct on first seeing five-figure wall-clock multiples is that the platforms are badly run. They are not. A quantum processor is a single, unreplicated, frequently recalibrated instrument, and the queue is the mechanism that lets one of them serve thousands of users.

The right reading is the one this chapter builds on: a resource whose utilization is 10⁻⁵ is not scarce in the dimension you are optimizing. You are not competing for computation. You are competing for scheduling, and the tools that win a scheduling competition — fewer, larger submissions — are not the tools Part V spent six chapters sharpening.

The batching arithmetic, and where it stops

§39.3's pitfall box asserts batching beats transpiling. The arithmetic behind it has a shape worth knowing, because it tells you when to stop.

Submitting $n$ circuits as separate jobs costs $n(t_q + t_d)$ of wall clock. Batched into one submission they cost $t_q + n t_d$ — one queue wait, then $n$ executions back to back. The speedup is

$$ S(n) = \frac{n(t_q + t_d)}{t_q + n t_d} $$

Two limits carry all the meaning. For small $n$, where $n t_d \ll t_q$, the denominator is essentially $t_q$ and

$$ S(n) \approx n $$

Batching is linear in the batch size — 100 circuits is very nearly 100× — which is why the measured figure at $n = 100$ is 99.8× and not something more interesting. For large $n$ the denominator becomes $n t_d$ and

$$ S(\infty) = \frac{t_q + t_d}{t_d} = 1 + \frac{t_q}{t_d} = M $$

The batching ceiling is exactly §39.3's wall-clock multiple. At a five-minute queue that is 43,340×, the same number in the utilization table. This is not a coincidence and it is the cleanest statement of the chapter's economics: the most batching can ever buy you is the reciprocal of your utilization, because batching's entire job is to stop wasting the queue and there is only so much queue to stop wasting.

Practically, $S(n) \approx n$ holds until $n t_d$ becomes comparable to $t_q$, i.e. until

$$ n \approx \frac{t_q}{t_d} = \frac{300\ \text{s}}{6.92\ \text{ms}} \approx 43{,}300 $$

So for any batch size a working scientist will ever submit, batching returns its full linear payoff and has not begun to saturate. The practical ceiling is not this formula; it is the provider's cap on circuits per job and on job payload size. Check that cap — it, not the arithmetic, is what limits you.

💰 Cost and Queue: batching is free and it is the only free thing here.

Note what batching does not change. One hundred circuits batched into a single job still run 100 circuits' worth of shots, so under a per-shot model the bill is identical. Under a per-minute model the device time is identical too; whether the wall-clock allocation shrinks depends on whether your provider bills allocation or execution, which is §39.4's fine print.

Batching buys wall clock, not money. It converts eight hours into five minutes at zero cost, which makes it the best deal in this chapter — and it is worth being clear that it is a latency optimization, so that nobody proposes it as a solution to Case Study 39.1's invoice.

39.4 Three pricing models that do not compare

   IBM pay-as-you-go               per-minute of QPU time    ~$96/min
   AWS Braket (superconducting)    per-task + per-shot       ~$0.30 + $0.00035/shot
   AWS Braket (trapped ion)        per-task + per-shot       ~$0.30 + $0.01/shot
   Quantinuum                      credit-based (HQC)        formula over qubits, gates, shots

These are published list prices and they change. The structure is what matters, and the structure is that a per-minute price and a per-shot price cannot be compared without knowing the circuit — because the conversion factor between them is exactly the circuit duration §39.2 measured.

A per-shot model charges you the same for a 1.69 µs Bell circuit and a 10.55 µs QFT. A per-minute model charges 6× more for the second. Neither is wrong; they price different things, and which one is cheaper depends entirely on whether your circuits are shallow and numerous or deep and few.

The break-even duration ★

"Depends entirely on the circuit" is unsatisfying, and it does not have to be. There is a single number that decides it, and it is one line of algebra.

Ignore the per-task fee for a moment. Running $s$ shots of a circuit of duration $d$ costs

$$ C_{\text{minute}} = \frac{s\,d}{60}\,P_m \qquad\text{and}\qquad C_{\text{shot}} = s\,P_s $$

Set them equal. The shot count cancels — which is the first surprise: the crossover does not depend on how many shots you run — leaving

$$ d^{*} = \frac{60\,P_s}{P_m} $$

The break-even is a property of the two rate cards alone. Evaluate it at the chapter's list prices:

   superconducting   d* = 60 x 0.00035 / 96  =    218.75 us
   trapped ion       d* = 60 x 0.01    / 96  =  6,250.00 us  (6.25 ms)

Above $d^{*}$, per-shot is cheaper. Below it, per-minute is cheaper. Now lay §39.2's measured durations against it:

   circuit             duration    d*/d, superconducting    d*/d, trapped ion
   Bell                 1.69 us              129.4x               3,698.2x
   GHZ-10               2.49 us               87.9x               2,510.0x
   EfficientSU2-12      3.22 us               67.9x               1,941.0x
   QFT-8               10.55 us               20.7x                 592.4x

Every circuit in this chapter is one to three orders of magnitude below break-even. That column is not an incidental ratio — it is exactly the factor by which per-shot pricing exceeds per-minute pricing on that circuit, which is why §39.5's headline for the Bell-duration VQE run is 129× before task fees. The pricing spread this chapter is about is not a mysterious market fact. It is $d^{*}/d$, and you can compute it before you submit anything.

Where this would flip ★★

So per-shot pricing wins when circuits get long. How long?

The superconducting break-even is 218.75 µs. Put that beside §39.6's measured coherence on the same device:

   break-even circuit duration     218.75 us
   median T1                       174.90 us      d* = 1.25x median T1
   best   T1                       483.00 us      d* = 0.45x best T1

A circuit long enough to make per-shot pricing competitive runs for longer than a median qubit stays coherent. It fits inside the best qubit's T1 with room to spare, and inside the median qubit's not at all. So the flip is not impossible on superconducting hardware — it is available only in a regime where your result is already dominated by decoherence, which means the circuit that finally makes per-shot cheaper is a circuit whose output you should not trust.

For the trapped-ion rate the conclusion is harder:

   trapped-ion break-even         6,250 us
   best T1 on this device           483 us      d* = 12.9x the best T1

Nearly thirteen times the longest coherence time on the chip. On this hardware the trapped-ion per-shot model can never be the cheaper option, at any circuit you could actually run. (Trapped ions have far longer coherence times of their own, which is part of what the 28× premium buys — the point is that a circuit designed against this device's coherence budget will never reach the crossover.)

There is a second way the conclusion flips, and it is the one a team is more likely to meet: the rate cards move. $d^{*}$ is linear in $P_s$ and inverse in $P_m$, so a provider halving its per-shot rate halves the break-even, and a provider doubling its per-minute rate does the same. A 200× cut in the per-shot rate would bring the superconducting break-even down to about 1.1 µs and put every circuit in §39.2's table on the other side of it. Nothing about the physics would have changed. This is why PriceBook requires an as_of date: the conclusion in this section is dated, and the method is not.

⚠️ Common Pitfall: comparing two rate cards without a circuit.

"Provider A charges $0.00035 per shot and Provider B charges $96 per minute" contains no comparison. It is two numbers in different units, and the conversion factor between them — the circuit duration — is not on either rate card.

This is why job_cost() raises AmbiguousPricingError when circuit_duration_s is missing rather than defaulting it. A default here would be a guess at the number that decides the answer, and a 149× error would arrive silently and look like a price.

The habit: before you compare providers, compute $d^{*} = 60 P_s / P_m$ and ask which side of it your circuit is on. Two minutes of arithmetic replaces the entire discussion.

The third model prices something you have been optimizing all book

The credit-based model — Quantinuum's HQC is the reference case — is usually treated as a complicated version of the other two. It is not. It is a different thing, and its consequences for your engineering run in the opposite direction.

A credit formula is a function of circuit structure: qubit count, gate counts (with two-qubit gates weighted more heavily than one-qubit gates), and shots. The exact coefficients are published, change, and are not reproduced here. The structural consequence is what matters:

   per-minute      bill tracks   depth x shots         -> Ch.28 helps, Ch.29 helps a little
   per-shot        bill tracks   shots                 -> neither helps at all
   credit-based    bill tracks   gate counts x shots   -> Ch.28 and Ch.29 bill directly

Under a credit model, §39.6's layout roulette is a line item. The seed that produced 112 two-qubit gates costs materially more than the seed that produced 49 — for the same circuit, the same shots, and a 2.03× worse answer. You would be paying more for the worse result, and nothing in the workflow would tell you.

And §39.3's central claim becomes conditional. "Batching beats transpiling" is true under per-shot and per-minute pricing because transpiling does not touch the invoice. Under a credit model transpiling touches the invoice directly, and Chapter 28's approximation_degree work — which reached zero two-qubit gates on one circuit — stops being a fidelity optimization and becomes a cost optimization as well.

This is the chapter's own recurring warning applied to itself: every remedy is denominated in the currency of the disease. Change the currency and the remedy changes. The right question is never "what should I optimize?" but "what is my provider counting?" — and the three answers are depth, shots, and gates.

39.5 The same computation, $50 or $185,542

Take the book's own experiments — real shot counts from Chapters 30, 34, 36, and 37 — and price them under each model using §39.2's measured durations.

   experiment                                  shots  tasks    QPU time    @0.00035   @0.01/shot
   Ch.30 randomized benchmarking             614,400    600       0.0 m         395        6,324
   Ch.34 kernel Gram matrix (72x72)        2,617,344  2,556       0.1 m       1,683       26,940
   Ch.37 QAOA p=3, eps=0.01               13,000,000  1,300       0.5 m       4,940      130,390
   Ch.36 VQE LiH (2e,2o)                  18,456,984  3,240       0.5 m       7,432      185,542

Now put the pricing models side by side on the same job:

   Ch.36 VQE LiH: 18,456,984 shots = 0.52 min of QPU time
      per-MINUTE  @ $96/min          ->  $        50
      per-SHOT    @ $0.00035/shot    ->  $     7,432      (149x)
      per-SHOT    @ $0.01/shot       ->  $   185,542    (3,718x)

(Per-shot figures include the $0.30 per-task fee across 3,240 tasks.)

Half a minute of quantum processor time. Fifty dollars, or one hundred and eighty-five thousand, depending only on how the provider counts.

📊 What the Numbers Say: you are not paying for device time.

Eighteen million shots sounds enormous and is thirty-one seconds of hardware. The bill is not tracking the physics — it is tracking access, and the unit of access differs by 3,718× between providers for identical work.

This is the practical form of a pattern this book keeps finding. Chapter 36's error was dominated by an approximation nobody reported; Chapter 37's comparison turned on what an algorithm produced rather than how it scored. Here, the quantity that determines your invoice is not the quantity anyone optimizes.

The trapped-ion premium is real and it buys something — all-to-all connectivity, longer coherence, higher two-qubit fidelity — so 28× per shot is not a markup for nothing. But it means a shot count chosen on a superconducting device is a budgeting decision, not a physics decision, when moved.

129× or 149×? Both, and the difference is the task fee

The chapter quotes two ratios for the same comparison and they are both correct. The reconciliation is worth doing, because it is where the per-task fee stops being a rounding error.

   Ch.36 VQE LiH: 18,456,984 shots, 3,240 tasks, 1.69 us per shot
      per-minute                      $      49.91
      per-shot, shots only            $   6,459.94        129.4x
      per-task fees, 3,240 x $0.30    $     972.00
      per-shot, total                 $   7,431.94        148.9x

The shots-only ratio, 129.4×, is exactly $d^{*}/d$ from §39.4 — the break-even duration divided by the Bell circuit's 1.69 µs. That is the pure pricing-model effect and it is the number the algebra predicts.

The 149× is what you are actually billed, and the extra 20 points come from a fee that looks negligible. Thirty cents per task, on a workload nobody would describe as task-heavy, is $972 — nineteen times the entire per-minute bill for the same work.

That is the general lesson about task fees. A per-task charge is invisible when you compare rate cards, because a rate card presents it as the small number. It becomes the dominant term whenever tasks are many and shots per task are few, and a variational workload is exactly that shape: 3,240 tasks at about 5,697 shots each. Halving the shots per task while keeping total shots constant doubles the fee.

💰 Cost and Queue: the number no invoice contains.

Divide each price by the device time it bought:

text per-minute $ 50 over 31.2 s -> under $2 per device-second per-shot $ 7,432 over 31.2 s -> $238 per device-second trapped ion $ 185,542 over 31.2 s -> $5,948 per device-second

Dollars per device-second is the only figure that makes the three models commensurable, and no provider reports it — not because anyone is hiding it, but because two of the three never compute device time at all.

It is a two-line addition to any monitoring dashboard: total shots × circuit duration, divided into the invoice. Case Study 39.1's team had shots, jobs and success rate on their dashboard and not this, which is why a 3,718× exposure sat there for a month looking normal.

Watch what a falling value means. If dollars-per-device-second drops sharply, you have not become efficient — you have started running longer circuits, and under a per-shot model longer circuits are free. That is the moment to check whether they are still coherent.

The ordering inverts, and the table's rounding hides it

Look again at the QPU-time column in §39.5's table: 0.0 m, 0.1 m, 0.5 m, 0.5 m. Two experiments round to the same half-minute. They are not the same, and which is larger is the opposite of what the shot counts suggest.

   experiment          shots        duration      device time
   Ch.30 RB          614,400   GHZ-10  2.49 us        1.53 s
   Ch.34 Gram      2,617,344   SU2-12  3.22 us        8.43 s
   Ch.37 QAOA     13,000,000   GHZ-10  2.49 us       32.37 s
   Ch.36 VQE      18,456,984   Bell    1.69 us       31.19 s

Chapter 37's QAOA run uses 30% fewer shots than Chapter 36's VQE and occupies the device for longer. Under a per-shot model VQE is the more expensive experiment; under a per-minute model QAOA is. The ordering of the two most expensive experiments in the book reverses depending on which provider runs them.

The mechanism is one line. Per-shot cost orders experiments by $s$; per-minute cost orders them by $s\,d$. Two experiments therefore swap places whenever

$$ \frac{s_1}{s_2} < \frac{d_2}{d_1} $$

Here $18{,}456{,}984 / 13{,}000{,}000 = 1.42$ and $2.49 / 1.69 = 1.47$. A 42% shot advantage loses to a 47% duration disadvantage, and the tie is that close. Nothing about the two experiments' scientific content is involved.

This is worth internalizing before benchmarking anyone's platform against anyone else's. A cost ranking of workloads is not a property of the workloads. Chapter 30 made the same point about fidelity — that a benchmark number without its statistic named is not a number — and the platform version is that a cost comparison without its pricing model named is not a comparison.

39.6 Calibration drift, productized

Chapter 29 optimized layout against calibration data and found it goes stale. On a cloud platform that staleness has a name: the gap between submission and execution.

Measured spreads across a real 133-qubit device snapshot:

   cz (2-qubit)     min 1.79e-03   median 3.66e-03   max 1.00e+00
   sx (1-qubit)     min 1.13e-04   median 2.44e-04   max 1.00e+00
   T1 (us)          min 15.2       median 174.9      max 483.0

The best and worst two-qubit links differ by orders of magnitude, and some are dead (error 1.00). Which physical qubits you get is therefore a first-order determinant of your result — and the platform assigns them at execution time, using calibration data that may have been refreshed after you submitted.

How much does the assignment matter? Transpiling a 14-qubit EfficientSU2 with 24 different seeds:

   worst  fidelity 0.5755   seed 20   109 2q gates   depth 247
   median fidelity 0.6396
   best   fidelity 0.7911   seed 23    49 2q gates   depth 149
   error ratio worst/best: 2.03x        2q gate count range: 49 - 112

Twice the error, from nothing but the seed. Note the mechanism: the best layout used 49 two-qubit gates and the worst used 112, so this is mostly routing overhead rather than link quality.

And a caution against over-reading it — the same experiment on a 4-qubit circuit produced zero variation across all 24 seeds. The transpiler found the same good layout every time. Layout variance is a large-circuit phenomenon, and a team that measures it on a toy circuit will conclude, wrongly, that the transpiler is deterministic and the seed does not matter.

Where the 49-to-112 spread comes from

The circuit swept above is efficient_su2(14, reps=2, entanglement="circular"). Before transpilation it contains a fixed, seed-independent number of two-qubit gates: circular entanglement places one CX per qubit per repetition, so 14 × 2 = 28 CX. That is the whole algorithm. Everything above 28 is the transpiler paying for connectivity.

A swap in this device's basis is not free. Decomposed to cz/sx/rz:

   swap  ->  3 cz + 6 sx

Three two-qubit gates per swap. So the observed range converts directly into routing work:

   seed outcome     2q gates    minus 28 logical    swaps inserted
   best (seed 23)         49                  21                 7
   worst fidelity        109                  81                27
   worst gate count      112                  84                28

Between the luckiest and unluckiest starting layout, the transpiler inserted 7 swaps or 28 swaps for the same 28-gate circuit. All three residuals divide by three exactly, which is the arithmetic signature of swap insertion and not of anything else — this really is routing.

A quarter of the transpiled circuit is the algorithm in the best case, and a quarter of it is the algorithm in the worst case too — 28 out of 49 versus 28 out of 112. At 112 gates, 75% of what runs on the device is the device's fault, not the algorithm's.

⚛️ The Physics Underneath: heavy-hex is sparse on purpose, and routing is the bill for it.

Measure the coupling graph of the 133-qubit device this chapter uses:

text couplers 150 qubits of degree 1 5 qubits of degree 2 89 qubits of degree 3 39

Maximum degree three. For 133 qubits a fully connected graph would need 8,778 couplers; this chip has 150. Most qubits have two neighbours.

That sparsity is a deliberate physics trade. Every additional coupler on a superconducting chip is another path for crosstalk, another frequency-collision constraint to satisfy during fabrication, and another decay channel. Heavy-hex was adopted precisely to reduce spectator errors and frequency crowding — the connectivity was spent to buy gate fidelity.

The bill arrives at routing. A circuit with all-to-all logical entanglement — which entanglement="circular" on 14 qubits nearly is — has to be threaded through a degree-≤3 graph, and the threading costs swaps. §39.6's 2.03× is the price of the fidelity that made this device good in the first place, showing up on a different line.

On a trapped-ion machine the trade runs the other way: all-to-all connectivity, no routing, no layout variance — and gate times orders of magnitude longer. Chapter 29 optimized within this trade; this section prices it.

📐 Math Aside: how much of the 2.03× is routing and how much is bad links?

The chapter says "mostly routing overhead rather than link quality." That is checkable from the two reported rows, without a new experiment.

The fidelity model behind the sweep is a product over two-qubit gates, $F = \prod_i (1 - e_i)$. If a layout runs $n$ two-qubit gates, define its effective per-gate error $\bar{e}$ by $F = (1-\bar{e})^n$, so

$$ \bar{e} = 1 - F^{1/n} $$

Apply it to both ends of the sweep:

text layout F n effective per-gate error best 0.7911 49 4.771e-03 worst 0.5755 109 5.056e-03 device median cz error 3.660e-03

The two layouts' links differ by only 1.06× in quality. Their gate counts differ by 2.22×.

Now separate the effects. Ask what the worst layout's fidelity would have been if it had run its 109 gates on links as good as the best layout's:

$$ F_{\text{counterfactual}} = (1 - 4.771\times10^{-3})^{109} = 0.5938 $$

giving an error ratio of $(1 - 0.5938)/(1 - 0.7911) = 1.94\times$ against the measured $2.03\times$.

Gate count alone accounts for 1.94 of the 2.03 — about 94% of the effect on a log scale. Link quality contributes the remaining 6%. The chapter's "mostly routing" is quantitatively right, and now it has a number.

One detail rewards attention: both effective error rates exceed the device median of 3.66 × 10⁻³. Neither layout is running on good links — the best one is 30% worse than median. At optimization_level=1 the transpiler is not shopping hard for the best couplers, which is exactly Chapter 29's finding that a hardware-aware level 1 (0.9116) beats a naive level 3 (0.7720). The headroom §39.6 leaves on the table is larger than the variance it measures.

🔬 Honest Assessment: what the 24-seed sweep does and does not establish.

It establishes that transpiler seed is a first-order input to hardware fidelity at realistic widths, on one circuit family, on one device snapshot, at one optimization level. Twenty-four seeds is enough to see a 2.03× spread; it is not enough to characterize the distribution's tails, and the reported min/median/max are three order statistics from 24 draws.

It does not establish that seed 23 is a good seed. Seed 23 was best for this circuit on this calibration snapshot, and Case Study 39.2's whole subject is that both of those move. Pinning seed_transpiler=23 because it won here would be the book's seventh version of treating one draw as a constant.

It also does not establish that the fidelity model predicts measured outcomes. $\prod_i (1 - e_i)$ over two-qubit gates ignores one-qubit error, readout error, crosstalk, and idling decoherence. Chapter 30 measured how far this class of estimate lands from reality — the median predicted Chapter 28's circuit fidelity within 12% — so treat these numbers as a ranking of layouts, which is what they are used for here, not as predicted fidelities.

39.7 The primitives layer

Modern stacks do not expose "run this circuit." They expose two primitives:

• Sampler — returns measurement outcomes. What you want for QAOA sampling, BB84 simulation, or anything where the bitstrings are the answer.
• Estimator — returns expectation values of observables. What you want for VQE, where Chapter 36's 1,086 Hamiltonian terms are the natural unit rather than shots.

The Estimator is not a convenience wrapper. It owns term grouping, measurement-basis scheduling, and optionally error mitigation — which means Chapter 24 §24.3's commuting-group optimization is a platform feature, not something you implement, and whether it is applied is a configuration option you should know the value of.

Execution modes matter more than most people expect:

• Job — one submission, one queue wait.
• Batch — many circuits, one queue wait. The single biggest lever in §39.3's arithmetic.
• Session — reserved access for a sequence of dependent jobs. What a variational loop needs, because otherwise every iteration re-queues.

A VQE run with 120 iterations, submitted as 120 jobs at a five-minute queue, spends ten hours waiting and thirty seconds computing. The same run in a session spends the queue once.

The variational loop, decomposed

That sentence is the whole chapter compressed, so it is worth unpacking against the run it describes. Chapter 36's LiH VQE is the 18,456,984-shot, 3,240-task experiment §39.5 priced. Divide it by 120 iterations:

   total shots               18,456,984
   total tasks                    3,240
   iterations                       120

   tasks per iteration               27          exactly
   shots per iteration          153,808
   shots per task                 5,697
   device time, total             31.19 s
   device time per iteration       0.26 s

27 tasks per iteration, exactly — one per Hamiltonian term in that active space, which is the number Case Study 39.1's team was working with. The structure of the bill is the structure of the Hamiltonian.

Now price the two execution modes in wall clock:

   as 120 jobs, 5-min queue   120 x (300 + 0.26) s  = 10.01 hours,  31.19 s computing
   in one session             300 s + 31.19 s       =  5.52 minutes total
   ratio                                                            108.8x

The session speedup is 108.8×, which is essentially the iteration count — and that is not a coincidence but the same limit §39.3 derived for batching. A session's speedup is $i(t_q + t_d)/(t_q + i\,t_d)$, linear in $i$ until $i\,t_d$ approaches $t_q$, and here $120 \times 0.26\ \text{s} = 31\ \text{s}$ against a 300 s queue, so it has barely started to bend.

The consequence for design: a variational loop's wall clock is set by its iteration count and the queue, and by nothing else you can see in the code. Doubling the shots per evaluation doubles the statistical quality and adds 31 seconds to a ten-hour run. Chapter 24's convergence work and Chapter 37's depth study are both free in wall clock and neither is free in dollars — the reverse of the usual engineering intuition, and a direct consequence of running on a shared instrument.

What the Estimator is doing with those shots

The 27-tasks-per-iteration figure is not a law of nature; it is a scheduling decision made on your behalf.

An expectation value $\langle H \rangle$ over a Hamiltonian with $m$ Pauli terms needs each term measured in its own basis — unless terms commute qubit-wise, in which case one measurement basis serves several. That is Chapter 24 §24.3's commuting-group optimization, and on a cloud platform it is not code you write. It is a property of the Estimator primitive.

The stakes scale with the problem. Chapter 36 measured Hamiltonian sizes directly:

   H2      4 qubits       15 terms
   LiH    12 qubits      631 terms
   BeH2   14 qubits      666 terms
   H2O    14 qubits    1,086 terms

Grouping is the difference between 1,086 measurement settings and something a few times smaller, and under both the per-shot and the per-task fee that reduction is money — recall §39.5, where 3,240 tasks carried $972 in fees alone.

Two practical consequences follow, and they are the reason to know your Estimator's configuration rather than trusting it:

First, grouping changes the variance, not just the count. Terms measured together share shots. A grouping that halves the number of settings does not halve the cost of reaching a given precision, because the shots per setting must rise to compensate. Case Study 39.1's team measured a 4× reduction on 27 terms; asking what that implies for LiH's 631 terms is that case study's third question, and the answer is not "23× better."

Second, error mitigation lives here too. Resilience settings and twirling are Estimator options, and they multiply your shot count by factors that do not appear in your circuit. Chapter 13 measured what mitigation buys; the platform-layer point is that the setting is a billing decision as much as an accuracy decision, and its default is chosen by your provider, not by you.

🐛 Debug This: the optimizer that converged to a layout instead of a molecule.

A variational loop stops improving after about forty iterations and the energy wanders by an amount far larger than the shot noise justifies. The Hamiltonian is right, the ansatz is right, and the same code converges perfectly on a simulator.

The bug is one line, and it is almost always this line:

python for theta in optimizer: circuit = build_ansatz(theta) tqc = transpile(circuit, backend) # <-- inside the loop energy = estimator.run([(tqc, H)]).result()

transpile() is stochastic and it is being called fresh every iteration. §39.6 measured what that costs: across 24 seeds the same 14-qubit circuit landed anywhere from 49 to 112 two-qubit gates and 0.7911 to 0.5755 fidelity. The optimizer is therefore evaluating its objective on a different physical circuit each step, with up to 2.03× different error. It is not optimizing the energy landscape; it is partly sampling the layout distribution.

The fix is structural, not a seed:

python ansatz = build_ansatz_parameterized() # symbolic parameters tqc = transpile(ansatz, backend, seed_transpiler=7) # ONCE for theta in optimizer: energy = estimator.run([(tqc, H, theta)]).result() # bind, don't rebuild

Transpile the parameterized circuit once and bind values inside the loop. The physical circuit is then fixed for the whole run, and the only thing varying is the thing you are optimizing.

Two tells that you have this bug: the noise scales with iteration count rather than with shot count, and it disappears entirely on a simulator with no coupling map. And note that seed_transpiler=7 alone would not have fixed it — see §39.8, and Case Study 39.2, for why a fixed seed against a moving calibration snapshot is not a fixed layout.

39.8 A result you cannot re-run

The reproducibility problem is sharper here than in classical computing, and it is not primarily about randomness.

A hardware result depends on: the calibration snapshot at execution time, the physical qubits assigned, the transpiler version and seed, the mitigation settings, and the device's thermal state. Most of those are not in your code, and several are not recorded anywhere you control.

Chapter 30 §30.5 refused to let a fidelity be quoted without naming its statistic. The platform version is stronger:

🔬 Honest Assessment: a hardware result without its execution metadata is not reproducible, and a result that is not reproducible is not verifiable.

Record, with every hardware result you intend to cite: backend name, job ID, execution timestamp, the calibration snapshot, the final physical qubit assignment, transpiler version and optimization level and seed, shot count, and mitigation settings.

This is not bureaucratic. Chapter 29's stale-calibration finding and this chapter's 2.03× layout spread mean that the same code, on the same backend, on a different day, is a different experiment. Without the metadata you cannot tell a real effect from a recalibration.

The protocol, in three tiers

"Record the metadata" is advice nobody follows because it has no edges. Give it edges. The fields sort into three tiers by whether losing them is fatal, expensive, or merely annoying.

Tier 1 — provider-side, unrecoverable. These exist only at execution time and only on the provider's side. If you do not capture them in the moment, they are gone permanently, and no amount of later diligence recovers them:

   job_id                  the provider's handle -- your only pointer back
   execution_timestamp     when it ran, not when you submitted
   calibration_snapshot    the properties the device actually had
   physical_qubits         which qubits you were given

ExecutionRecord.is_reproducible returns False while any of these four is None, and that is the whole design of the class. It is deliberately not satisfied by "the code is committed."

Tier 2 — client-side, reconstructible but not for free. Your source could regenerate these, but only if you can identify the exact source, which after six months you cannot:

   qiskit_version          transpiler behaviour changes between releases
   optimization_level      determines which pass manager ran
   seed_transpiler         one input to a stochastic function
   shots                   sets the statistical floor
   mitigation settings     resilience level, twirling -- often defaulted

Tier 3 — contextual, worth having. Device queue depth at submission, whether you ran in a session, which other jobs shared the session, and any hardware maintenance notices in the window. Nice to have, rarely available, occasionally the entire explanation.

The operational rule that makes this stick: write the record at result time, not at analysis time. A dictionary serialized next to every raw result file, before any processing. The failure mode is universal and always the same — you intend to record the metadata when you write it up, and by then the job object has been garbage-collected and the calibration snapshot has been overwritten twice.

Why "I pinned my environment" is the wrong instinct

Classical reproducibility practice is about determinism of the computation: pin the versions, fix the seeds, and the same inputs produce the same outputs. It is good practice and it is complete for classical work, because the machine is not an input.

On hardware the machine is an input, and it is an input you do not control, do not observe by default, and cannot pin at all.

   what you can pin          what you cannot pin
   ------------------        --------------------
   library versions          the calibration snapshot
   transpiler seed           which physical qubits you get
   optimization level        the device's thermal state
   shot count                the queue's scheduling decisions
   circuit source            recalibration between submission and execution

Everything in the left column is client-side, and the variance this chapter measured is entirely in the right. A repository with a pinned requirements.txt, a fixed seed, and a notebook that regenerates every plot has pinned the side that was never the problem — and it has done so in a way that creates confidence, which makes it worse than doing nothing. Case Study 39.2 is a group that did all of this correctly and reported a 34% effect that later measured 7%.

The reframing that fixes it: on hardware you are not writing reproducible software, you are writing a lab notebook. The question is not "will this rerun?" — it will, and it will give a different answer. The question is "can a reader determine what I actually measured?" That is answered by metadata, not by determinism.

⚠️ Common Pitfall: a fixed seed is not a fixed layout.

seed_transpiler=42 fixes one input to the layout and routing passes. It does not fix the others. The layout selection stage scores candidate placements against the backend's current error rates, so when the device recalibrates the objective function changes and the same seed lands somewhere else.

The seed is deterministic; the function it seeds is not stationary.

Two things actually pin a layout. Pass an explicit initial_layout with the physical qubits recorded from the original run — which is why physical_qubits is a Tier 1 field and not a curiosity. Or transpile once, serialize the transpiled circuit itself (QASM 3 or a versioned artefact per Chapter 6), and submit that rather than re-deriving it.

The second option is what production workflows converge on, and it has a side benefit: it removes the §39.7 bug where a variational loop re-transpiles inside the optimizer.

39.9 What to actually do

1. Develop on a simulator. §39.2 measured local simulation at the same order of magnitude as hardware execution, with no queue and no cost. Use hardware for what only hardware provides: real noise.

2. Count jobs before counting gates. If the queue dominates, batching beats transpiling.

3. Price the experiment before running it. §39.5's spread means the same design is routine or prohibitive depending on the provider, and that is knowable in advance from a shot count and a duration.

4. Use sessions for variational loops. Otherwise every iteration pays the queue.

5. Record execution metadata as a matter of course. The cost is a dictionary; the alternative is an unfalsifiable result.

6. Know which pricing model you are on. The 129× is not a negotiation outcome — it is arithmetic, and it is on you to do it.

The pricing decision, as a procedure

Six pieces of advice are still six things to remember. The pricing part of it collapses to a procedure you can run in a couple of minutes, entirely from numbers you have before submitting anything.

Step 1 — get the circuit duration. Schedule the transpiled circuit with alap against the backend target and read off the end time, as §39.2 does. This is the number everything else needs and the one nobody has. Call it $d$.

Step 2 — count shots and tasks. Total shots $s$ across the whole workflow, and the number of separate submissions $T$. For a variational workflow, $T$ is iterations × measurement settings — 120 × 27 = 3,240 in §39.7's case, not 120.

Step 3 — compute the break-even. $d^{*} = 60 P_s / P_m$ from §39.4. Compare it to $d$:

   d <<  d*     per-minute wins, by roughly d*/d
   d ~=  d*     the models are within a factor of two -- decide on other grounds
   d >>  d*     per-shot wins

Step 4 — add the task fee separately. $T \times P_{\text{task}}$ is its own term and it does not scale with shots. §39.5's $972 on a $50 workload is the warning: whenever shots-per-task is small, check this before anything else.

Step 5 — compute dollars per device-second. Total cost divided by $s \times d$. This is the figure that makes providers comparable and the one no invoice reports.

Step 6 — write down the date. The rate cards move and the conclusion is dated. PriceBook requires as_of for exactly this reason.

Worked on the chapter's own example: $d = 1.69$ µs, $s = 18{,}456{,}984$, $T = 3{,}240$, $d^{*} = 218.75$ µs. Step 3 gives $d^{*}/d = 129$, so per-minute wins by two orders of magnitude before fees. Step 4 adds $972 of task fees, taking the observed ratio to 149×. Step 5 gives under $2 versus $238 per device-second. Six steps, no experiment, and the answer is available before a single shot is submitted.

Fidelity and throughput are different problems

The synthesis worth carrying out of Part V and into Chapter 40.

   Part V chapter    what it optimized       what it moves      what it does not move
   Ch.28  optimization  gate count / depth   the 7 ms, fidelity   the 5-minute queue
   Ch.29  layout        link quality          fidelity            the 5-minute queue
   Ch.31  timing        decoherence           fidelity            the 5-minute queue
   Ch.39  batching      submissions           the 5 minutes       fidelity, not at all

Every row is correct and no row helps the others. Chapter 29's hardware-aware level 1 beat a naive level 3 by 0.1397 in fidelity and changed the wall clock by nothing. Batching 100 circuits bought 99× in wall clock and changed the fidelity by nothing. Chapter 31 found dynamical decoupling made things significantly worse — a fidelity result with no throughput content whatsoever.

A team optimizing throughput with fidelity tools will work very hard and measure no improvement in the thing they were asked about, and vice versa. This is the chapter's version of the book's oldest warning: the number that is easy to get is not the number that answers the question. Circuit depth is easy to get. Queue time requires credentials, patience, and a week of sampling — which is why the chapter that is honest about not having measured it is the one you are reading.

🧪 Run It: price your own workflow, then find your break-even.

Everything below runs against fake backends with no credentials.

1. Get a duration. Run example-01-what-a-circuit-costs.py and reproduce §39.2's table. Then swap in a circuit you actually care about and read off its duration and depth. Divide duration by depth and check that you land in the 40–50 ns per layer band the Math Aside predicts — if you are far above it, your circuit is shallow enough that readout dominates.

2. Compute your break-even. $d^{*} = 60 P_s / P_m$ with today's published rates, not this chapter's. Where does your circuit sit relative to it, and by what factor?

3. Price it three ways.

python from vqelab.platform import PriceBook, job_cost ibm = PriceBook(as_of="<today>", per_minute_usd=96.0) aws = PriceBook(as_of="<today>", per_task_usd=0.30, per_shot_usd=0.00035) job_cost(shots, tasks, duration_s, ibm)["usd_per_device_second"]

Try omitting duration_s and read the AmbiguousPricingError message. That refusal is §39.4.

4. Run the layout sweep at your own width. example-03-calibration-and-reproducibility.py sweeps 24 seeds at 14 qubits and at 4. Run it at your circuit's width. If you see no variation, check layout_variance_is_measurable(n) before concluding the transpiler is deterministic — below 8 qubits the experiment cannot detect the effect, which is the chapter's seventh instance of a measurement that cannot see what it is being asked about.

5. Build a record you cannot cheat. Construct an ExecutionRecord from a local run and check is_reproducible. It will be False, correctly, because a fake backend has no job ID. That False is the honest answer, and getting comfortable with seeing it is most of the discipline this section is asking for.

What we measured

• A 4,096-shot Bell job occupies the device for 6.92 ms; QFT-8 for 43.20 ms
• Local simulation of the same jobs took 22–74 ms — the same order of magnitude as hardware execution
• ★ At a 5-minute queue, utilization is 2.31 × 10⁻⁵ — 43,340× wall clock over device time
• The book's own experiments run 614,400 to 18,456,984 shots — and 18.5M shots is 31.2 seconds of device time
• ★★★ The same VQE run costs $50 per-minute, $7,432 per-shot (149×), or $185,542 on trapped ions (3,718×) — identical computation, different counting
• Two-qubit error rates on one device span 1.79e-03 to 1.00 (dead links included); T1 spans 15.2–483.0 µs
• ★ Transpiler seed alone changed 14-qubit fidelity from 0.5755 to 0.7911 — 2.03× the error — driven by a 49-to-112 spread in two-qubit gate count
• The same test on a 4-qubit circuit showed zero variation. Layout variance is a large-circuit phenomenon
• 120 VQE iterations as 120 jobs at a 5-minute queue: 10 hours waiting, 30 seconds computing

Next: Chapter 40 closes the book — what this field actually employs people to do, what the forty chapters add up to, and how to tell a real opportunity from a well-funded one.