Case Study 39.1: The Invoice

The situation

A pharmaceutical company's quantum team has a $50,000 annual cloud budget and a research plan: a variational study of a small metal-organic fragment, benchmarked across two hardware modalities to see which the chemistry suits better.

They prototype on a superconducting device. The workflow is a VQE loop — 120 optimizer iterations, an active space producing 27 Hamiltonian terms, roughly 100,000 shots per energy evaluation. It runs. The first month's invoice is **$7,432**, against a prototype-phase allowance of $8,000. On plan.

They port the identical workflow to a trapped-ion backend for the comparison arm. The next invoice is $185,542 — 3.7× the entire annual budget.

Nothing about the computation changed.

Step 1: what actually changed

The team's first assumption is a billing error. It is not.

>>> from vqelab.platform import PriceBook, job_cost
>>> sc  = PriceBook(as_of="2026-08", per_task_usd=0.30, per_shot_usd=0.00035)
>>> ion = PriceBook(as_of="2026-08", per_task_usd=0.30, per_shot_usd=0.01)
>>> shots, tasks, duration = 18_456_984, 3_240, 1.69e-6
>>> job_cost(shots, tasks, duration, sc)["usd"]
7431.9444
>>> job_cost(shots, tasks, duration, ion)["usd"]
185541.84

The per-shot rate is 28× higher, and the workflow's shot count was chosen on the cheaper device.

The team had treated shot count as a physics parameter — how many samples the estimator needs to resolve the energy to chemical accuracy, which is Chapter 24 §24.3's $1/\epsilon^2$ and does not care what hardware runs it. That reasoning is correct about the statistics and silent about the invoice.

⚠️ A shot count chosen on superconducting hardware is a budgeting decision, not a physics decision, when moved. The estimator needs what it needs; what changes is what each sample costs, and by a factor that nobody re-derives when porting a working script.

Step 2: the number that should have been on the dashboard

The team's monitoring tracked shots, jobs, and success rate. It did not track device time, because device time was not billed.

   Ch.36-scale VQE run -- 18,456,984 shots, 31.2 s of device time:
      per-minute     $        50   ($     2 per device-second)
      per-shot       $     7,432   ($   238 per device-second)
      trapped ion    $   185,542   ($ 5,948 per device-second)

Thirty-one seconds of quantum processor time. The team had never computed it, because no invoice line item mentions it and no SDK call returns it prominently.

Computing it changes the conversation entirely. A workflow that consumes half a minute of hardware per month is not a capacity problem — it is a pricing-model problem, and pricing-model problems have different solutions than capacity problems.

Step 3: the options, priced

Option A — reduce shots. Chemical accuracy requires what it requires. Dropping to $\epsilon = 0.005$ (worse than chemical accuracy) cuts shots 4× and the bill to ~$46,400. Still most of the annual budget, and the result no longer answers the question.

Option B — move to a per-minute provider. The same 31.2 seconds bills at roughly $50. The catch is that per-minute providers charge for wall-clock QPU allocation, including the classical latency inside a session — so the real figure depends on how tight the variational loop is, not on the shot count. The team measures their loop's turnaround before committing.

Option C — group commuting terms. Chapter 24 §24.3's optimization, which the Estimator primitive implements. The 27-term Hamiltonian groups into far fewer measurement bases; the team measures a 4× reduction. Bill falls to ~$46,400 on the ion device — the same 4×, and still not enough on its own.

Option D — ask whether the comparison arm needs full precision. The purpose of the trapped-ion run is modality comparison, not a production energy. A comparison can be made at lower precision on a subset of geometries.

The team takes C and D, and it is D that does the work.

Step 4: the recommendation

Trapped-ion arm: rescope to 6 geometries at $\epsilon = 0.008$, with commuting-group measurement. Estimated $9,400 — Option C and Option D together, and it is D that does the work.

The original port was a mistake of a specific kind and I want to name it precisely: we treated a parameter that is physical on one device as if it were physical on every device. The shot count is set by the estimator's variance and is correct. What we did not re-derive is that each of those samples costs 28× more, and our monitoring showed shots — not dollars per device-second — so nothing flagged it.

Two process changes:

  1. Price every workflow before porting it. It is a shot count, a circuit duration, and a rate card. We now have job_cost() for this; it refuses to run without the duration, which is the number we were missing.
  2. Add dollars-per-device-second to the dashboard. Our workflow uses 31 seconds of quantum processor per month. That number is invisible in every invoice and it is the one that reveals when the bill has stopped tracking the computation.

We are not asking for a budget increase. The comparison is answerable within the existing budget at appropriate precision; we were paying production rates for an exploratory question.

What this case study is about

Nobody made a technical error. The workflow was correct on both devices, the shot count was correctly derived, and both providers billed exactly what they advertise.

The failure was a quantity that was constant in one context and variable in another, crossing a boundary without being re-examined. That is the same shape as Chapter 36's active space — a decision made in the classical setup that dominated everything downstream and was never revisited — and Chapter 38's authentication precondition, which is a fact about the protocol rather than any product.

The general habit: when porting a workflow, list the parameters that were tuned against the old environment and re-derive each one. Most will be unchanged. The ones that are not will be expensive, and they will not announce themselves.

Questions

  1. Recompute the trapped-ion bill under Option A alone. Why is "use fewer shots" the worst of the four options, despite being the most obvious?
  2. Option B's catch is that per-minute providers bill wall-clock allocation including classical latency. Design the measurement that would tell you whether Option B is actually cheaper for this workflow.
  3. [measure] The team measured a 4× reduction from commuting-group measurement on 27 terms. What would you expect on Chapter 36's 631-term LiH Hamiltonian, and why is the answer not "23× better"?
  4. The recommendation adds "dollars per device-second" to the dashboard. What would a healthy value look like, and what would it mean if it fell sharply?
  5. The hard one. The team's shot count was derived from $1/\epsilon^2$ and is correct. Construct the argument that it was never purely a physics parameter — that even on the original device it encoded an economic choice — and say what that implies for how §24.3's formula should be taught.