Execution Economics — what each circuit costs, classically vs on a QPU. Audited.
Every other tool answers "run my method." Atlas also answers the money question: what would this circuit cost on a real QPU, and what does the classical route cost instead? The number is built from a formula you can see, with assumptions you can edit — labeled published / measured / derived, never a black box.
engine/economics.py
benchmarks/spend_frontier/ in the repo · pricing snapshot 2026-06-25 · counterfactual framing applies to every QPU figure.The $2,119.98 you don't spend
qft_n29 (29 qubits) carries #T = 1,173 — on paper, a hard circuit. Atlas routes it CPU: measured classical cost $5e-05/eval. The same job on the exhibit's QPU: $2,119.98. Magic ≠ hardness.
Correction (2026-09-05). This card used to headline multiplier_n45 at $17,560.86. That circuit needs 45 qubits and the exhibit used to price everything on IonQ Forte, which publishes 36. A price for a job the machine cannot run is not a price, so it was withdrawn along with 11 others. Update 2026-09-08: no longer for that reason — the exhibit now prices on the cheapest machine whose published qubit count fits, and Rigetti Cepheus finally has a sourced 2-qubit error rate (published median 2-qubit gate fidelity 99.1% → 9.0e-3, nine times worse than the unsourced 1e-3 default it used to inherit). multiplier_n45 still carries no price, for a different and better-stated reason: no machine that fits can run its campaign inside one year of continuous device time. 100 of the plotted circuits keep a QPU price. The classical side is unaffected and still measured — a problem on the QPU side must never delete a good measurement on the classical one (a regression that did exactly that, on 9 rows, was caught the same day by the claims checker). Found by the number-provenance gate, not by a reader.
The middle band
mqt_randomcircuit_n24 (MQT Bench, 24 qubits): Atlas's own estimators hit their budget — yet the TENSOR route still prices the classical side at $3.91e-4/eval (modeled contraction cost at HPC rates) vs $10,853.5 on a QPU.
Where a QPU is warranted
sycamore_rcs_53q_depth20 (Sycamore-scale RCS, pinned as external_corpus/qasm/sycamore_rcs_53q_depth20.qasm, seed 0): route ESCALATE — no classical price exists in Atlas's measured reach. The QPU side prices it at $38,060.29/eval on Rigetti Ankaa-3 (84 qubits — IonQ Forte, 36 qubits, cannot run a 53-qubit circuit; the earlier figure quoted on Forte was wrong for that reason). That price is recomputed from the engine on the pinned QASM by a deploy gate, so it cannot drift. The exhibit above shows no QPU point for this circuit, because the plot prices every row on one named vendor for comparability and Forte cannot run it — the plot and this paragraph disagree on purpose, and each says which machine it means. The 127-qubit kicked-Ising utility circuit fits no gate-based Braket device (Cepheus-1-108Q tops out at 108 qubits); on IBM Heron r2 billing is per minute, not per shot, so no per-eval price is quoted. Atlas escalates them instead of pretending.
5b The third axis: joules — and why there are two right answers
Dollars and device-time are not the only budgets. There is a third, and it is the one where the classical side can lose while winning on both of the others: the classical refutation of a celebrated quantum sampling result was faster than the quantum device and consumed roughly three orders of magnitude more energy. The field measures this in papers, after the fact. Nobody puts it in a routing decision.
The subtlety nobody publishes. A superconducting QPU's energy is dominated by a constant: the dilution refrigerator draws tens of kilowatts near 10 mK whether or not it is doing work. That gives two answers that are both correct and point opposite ways:
- Marginal — the fridge will be running anyway, so your job costs only what it adds. This is the right answer if you share a machine that already operates.
- Amortised — your job pays its share of the fridge for as long as it runs. This is the right answer if the machine exists for your workload, or you buy dedicated time.
The answer flips between them, so Atlas publishes both, each labelled with the question it answers. Publishing only one would be choosing for you without saying so.
Two things this axis will not do. It does not measure watts — you declare them, because Atlas does not know which machine you run on or which QPU you would go to; without declared power it returns nothing at all. And if you declare that all of the QPU's power is constant, the marginal reading is zero joules by definition and the QPU "wins" without any computation being done: Atlas marks that reading degenerate, because it is your assumption handed back, not a result.
Published break-even for reference, not measured by us: energy-to-solution crosses around 34 qubits. Like every other axis here, energy never governs the route: it changes whether you want to take the route, not whether the route exists.
For auditors — the formula behind every number
Everything above is computed, not asserted. This section is the full derivation: shots from precision, mitigation overhead, per-device calibration, vendor billing models, the measured classical side, and where this sits against other cost tools. Every term labeled published / measured / derived.
$0.30 task + 10,060 shots × $0.08/shot, published Braket pricing. At research-grade precision (ε=3e-3, ~112k shots) the same job is ≈ $8,942.78. Open the panel and recompute — that is the point. See also the corpus-wide exhibit above — the $805.1-class job appears there as mqt_cdkm_ripple_carry_adder_n18 at $801.26/eval.
1 Shots from precision
To pin an expectation value to additive error ε you need shots that beat shot-noise (error ~ 1/√N):
N_base = ⌈ 1 / ε² ⌉ε=1e-1 → 100 · ε=1e-2 → 10,000 · ε=3e-3 → ~111,111. derived (textbook shot-noise). Vendor floors apply (e.g. IonQ error-mitigation minimum 2,500 shots).
2 Mitigation overhead — the sensitive heart
Real hardware is noisy, so a usable expectation value needs error mitigation, whose sample overhead grows exponentially with circuit volume × noise (probabilistic error cancellation):
N = N_base · γ², γ² = e^(4·λ), λ = ε_g · n₂qpublished bound — Quek/Eisert arXiv:2210.11505, Takagi arXiv:2109.04457. n₂q = two-qubit gate count, ε_g = per-gate error (next section).
ε_g or the mitigation model move the QPU cost by orders of magnitude. That is exactly why Atlas exposes ε_g and the formula as editable and sourced — the honest answer to "why this model?" is "PEC, published, and you can swap it," not "trust us." We label it published, never measured.3 Per-device gate error ε_g — the calibration
The exponent rides on ε_g, so Atlas uses per-device values, not one generic number:
| Device | ε_g (2-qubit) | Provenance |
|---|---|---|
| public-access superconducting hardware (Heron r2) | 2.0e-3 | measured — Atlas's own ibm_kingston RB (2.02e-3 isolated; 3.42e-3 EPLG layered) |
| Rigetti | 5.0e-3 | published — 99.5% 2q fidelity |
| IQM (Garnet/Emerald) | 5.0e-3 | published — 99.51% |
| IonQ (Forte/Aria) | 3e-4 | vendor-claimed — no hard public 2q figure; optimistic, flagged uncertain |
That row is measured on our own hardware runs — and that calibration data ships in the repo (kingston_calibration.json). Note: two carve-outs sit outside our Apache-2.0 grant — IBM Quantum device data (job IDs, calibration, results), used under IBM Quantum's terms, and the 83 third-party benchmark circuits under benchmarks/external_corpus/ (QASMBench, MQT Bench), under their own licences. Only Atlas's own code/corpus/scripts are Apache-2.0; see NOTICE. The rest are published/claimed and editable. No affiliation. Atlas is a Krenn·IQ project. It is not affiliated with, endorsed by, or sponsored by IBM, IonQ, Rigetti, IQM, AWS, QuEra, AQT or any quantum-hardware vendor. All third-party names, marks and prices are the property of their respective owners and are cited for comparison only.
4 Two pricing families — billed how the vendor bills
Most naïve estimators invent a $/shot for superconducting hardware. That vendor doesn't bill per shot — it bills per minute of QPU time. Atlas branches:
per-shot (AWS Braket): cost = task_fee + N · per_shot per-minute (superconducting): cost = runtime_min · rate_per_minpublished tariffs — AWS Braket (IonQ $0.08/shot + $0.3/task; Rigetti $0.000425; IQM/AQT/QuEra) · superconducting-vendor plans (Open free · Pay-As-You-Go $96/min · Flex $72/min · Premium $48/min). Verify: AWS Braket pricing · IBM Quantum plans.
5 The classical side — measured, not estimated
The whole verdict is a comparison, so the classical cost is measured, not guessed: Atlas times the real MPS/tensor contraction (quimb) for the circuit and prices the wall-clock at a cloud-CPU rate. The reference machine is a dev Apple M4 (24 GB) — see the per-estimator ceilings on the Evidence page.
A laptop that settles the circuit in milliseconds at near-zero cost, versus the QPU job above, is the "don't spend" verdict in dollars.
6 Worked example (reproducible)
IonQ Forte via AWS Braket, a small tractable circuit a laptop runs in ms — parameters stated so every row recomputes: 5 two-qubit gates, depth 10, εg = 0.0003 (ion-trap, SOTA), pricing snapshot 2026-06-25:
| Precision ε | Shots (incl. mitigation) | QPU $/job |
|---|---|---|
| 1e-1 / 3e-2 | 2,500 (vendor floor) | $200.3 |
| 1e-2 (casual) | ~10,060 | ≈ $805.1 |
| 3e-3 (research-grade) | ~111,781 | ≈ $8,942.78 |
Every row is recomputable from §1–4 with the published pricing; the panel lets you change vendor, ε and campaign size and watch the number move.
7 Where this sits vs other cost tools
Vendor pricing tools — AWS Braket, IBM Quantum, IonQ — price their own hardware: useful once you've decided to run, silent on whether you should. Fault-tolerant resource estimators — Microsoft's Azure Quantum Resource Estimator and BenchQ — answer a different, future question: the physical qubits and runtime a large algorithm would need on a fault-tolerant machine that does not yet exist. Work on quantum economic advantage and the QEA online calculator estimate theoretical crossover points by algorithm class, not the measured cost of your circuit today. Atlas fills the near-term gap between them: it triages whether this specific circuit is classically simulable, measures what running it classically actually costs, and sets that against published QPU pricing — one auditable spend-or-don't-spend verdict for the hardware you can rent right now. We are not aware of another tool that combines all three.
Pricing shown is a dated snapshot under declared assumptions; classical time is measured, QPU cost is published pricing; decision support, not financial advice.
ε_g from our own QPU runs); (3) per-shot-vs-per-minute modeled correctly; (4) full auditability — every term labeled and sourced. The page you are reading is the moat: a cost number you can recompute, versus a black-box calculator you can't.