1. The short version, what to know first, and where this fits in the series

• A quantum program is a circuit: instructions to a quantum computer are written as a circuit: which gates to apply to which qubits, in what order, and a final measurement. The result is not one answer but a distribution of 0s and 1s over many measurements (shots).
• How it is used: you write a circuit on your own machine and test it (on a simulator), use a transpiler to rewrite it for the machine's gates and connectivity, send it to the cloud, wait in a queue, and receive the executed result. In the most advanced uses, quantum and classical computers go back and forth many times in a hybrid loop
• What to look at: the same circuit can end up with very different numbers of two-qubit gates depending on connectivity and optimisation strength (in our run, a 5-qubit example went from 56 to 30, and to 20 with full connectivity). Beyond the "number of qubits", the size of the circuit after conversion and the speed of execution decide practical performance Our calculation

2. What a quantum program is — "writing a circuit"

(1) An everyday example: a musical score and a recording of the performance

A score lists which notes to play in which order. A circuit in a quantum program is the same: it lists which gates to apply to which qubits, in what order. The difference is in the performance. An ordinary program gives the same output for the same input. A quantum program, when finally measured, gives results that are decided by probability. So we run the same circuit hundreds or thousands of times and count what comes out. The number of repetitions is called shots.

(2) The smallest example: make a Bell state and measure it

Here is the most common small example. With two qubits, we (1) apply an H gate to the first qubit (tilt the arrow sideways to make a superposition), (2) apply a CNOT gate (flip the second qubit only when the first is 1, which "entangles" the two), and (3) measure both. Three instructions.

Ideally the result is "00" or "11", about half each. "01" and "10" never appear, because the two qubits behave as one unit. This is entanglement. On our local simulator, 1000 measurements gave "00" 502 times and "11" 498 times Our calculation (results we ran; code in the fold-out below).

from qiskit import QuantumCircuit
from qiskit.primitives import StatevectorSampler

qc = QuantumCircuit(2, 2)
qc.h(0)                      # put q0 in a superposition
qc.cx(0, 1)                  # entangle q1 with q0 (q0 is the control)
qc.measure([0, 1], [0, 1])   # measure both into classical bits

result = StatevectorSampler(seed=7).run([qc], shots=1000).result()
print(result[0].data.c.get_counts())   # {'11': 498, '00': 502} (dictionary order varies)

import cirq

q0, q1 = cirq.LineQubit.range(2)
c = cirq.Circuit(cirq.H(q0), cirq.CNOT(q0, q1), cirq.measure(q0, q1, key='m'))
r = cirq.Simulator(seed=7).run(c, repetitions=1000)
print(r.histogram(key='m'))   # Counter({0: 512, 3: 488}) (0 means "00", 3 means "11" read as an integer)

import cudaq

@cudaq.kernel
def bell():
    q = cudaq.qvector(2)
    h(q[0])
    x.ctrl(q[0], q[1])
    mz(q)

cudaq.set_random_seed(7)
print(cudaq.sample(bell, shots_count=1000))   # { 00:499 11:501 }

import pennylane as qml

dev = qml.device('default.qubit', wires=2, shots=1000, seed=7)

@qml.qnode(dev)
def bell():
    qml.Hadamard(wires=0)
    qml.CNOT(wires=[0, 1])
    return qml.counts()

print(bell())   # "00" 502 times, "11" 498 times (printed as NumPy types)

OPENQASM 3.0;
include "stdgates.inc";
bit[2] c;
qubit[2] q;
h q[0];
cx q[0], q[1];
c[0] = measure q[0];
c[1] = measure q[1];

3. A map of SDKs — Qiskit, Cirq, CUDA-Q and others

The tool for writing circuits is an SDK (software development kit). Most let you build circuits in Python and send them to a simulator or real hardware. The table below organises the main SDKs we could confirm. It is not a ranking.

The descriptions come from the official GitHub repositories, paper abstracts and public PyPI information (checked 16 October 2026) [Ref. 18 to 25] Sourced. The arrangement of the table is our commentary. The tket repository now sits under Quantinuum's organisation.

A "common language" for circuits: OpenQASM and QIR

Even when SDKs differ, telling a machine about a circuit needs a common way of writing it. OpenQASM (Open Quantum Assembly Language) is the best known. OpenQASM 3 goes beyond writing circuits: it separates classical computation done in real time, within the qubits' coherence time, from looser near-time computation, and lets you write control flow (such as if) and calls to external classical functions [Ref. 9] Sourced. The published specification is v3.1.0 (released 15 May 2024) [Ref. 10]. QIR (Quantum Intermediate Representation) is a specification that expresses quantum programs on top of LLVM intermediate representation, which general-purpose compilers use; it is being developed by a joint effort called the QIR Alliance [Ref. 11] Sourced. Neither is a standard of the International Organization for Standardization (ISO) or similar; they are specifications managed by communities and companies (we could not confirm any standardisation).

4. Compilers and transpilers — turning the "ideal circuit" into "the machine's language"

(1) An everyday example: deliveries in a town with few direct roads

Suppose you want to deliver a parcel from one house to a distant house. But in this town roads connect only neighbouring houses. To reach a distant house you have to hand the parcel from neighbour to neighbour. Every extra hand-over takes time and risks damage (more errors). A quantum computer chip has a similar constraint. A two-qubit gate (an operation on two qubits at once) can usually be applied only to pairs that are physically connected. So the circuit you wrote has to be rewritten to fit the chip's connectivity and the kinds of gates it can perform. The program that does this rewriting is the transpiler, a kind of compiler. (Limit of the analogy: a delivery moves the parcel itself, but for qubits we use an operation called a "SWAP" that moves the state to a neighbour. One SWAP is equivalent to three CNOTs, and every hand-over adds a seed of error.)

(2) Why the rewriting is needed

• Only certain gates are available: a real machine directly performs just a few "basis gates". Any other gate is broken down into combinations of them
• Connectivity is limited: if two qubits that should take a two-qubit gate are not directly connected, a SWAP moves one next to the other. How free the connectivity is depends on the qubit technology (see the articles on each technology)
• Fewer gates means fewer errors: two-qubit gates in particular have large errors, so reducing them pays off (our explanation)

(3) The six stages of Qiskit's transpiler

Qiskit's official documentation describes transpiling as six stages [Ref. 2] Sourced.

"Layout" in the figure assigns the circuit's qubits (logical numbers) to physical qubits on the chip. "Routing" connects distant pairs with SWAPs. The optimisation level runs from 0 to 3; a higher number uses heavier processing to try to cut more gates [Ref. 2]. The problem of inserting the fewest SWAPs is known to be NP-hard (a kind of problem where the cost of an exact solution grows explosively as qubits are added), so in practice approximate methods are used. Qiskit's standard is a method called SABRE, which searches while varying the initial placement randomly, so the result is stochastic (proposed by Li, Ding and Xie in 2019 [Ref. 12]). Qiskit's developers report that LightSABRE, an improvement on SABRE, was "about 200 times faster" and reduced SWAPs by an average of 18.9% [Ref. 13] Sourced (the authors' report; see the paper for the conditions and what was compared). tket, from another development group, is also known as a compiler that optimises circuits without depending on a particular machine [Ref. 14].

(4) What we actually tried: the same circuit changes several times over with conditions

We used a 5-qubit quantum Fourier transform (QFT). The QFT is a building block of many quantum algorithms, and nearly every pair of qubits interacts in it, so the effect of connectivity limits is easy to see. We converted it with Qiskit 2.6.0 transpile, setting the basis gates to rz, sx, x and cz (random seed 11) Our calculation.

Our calculation. "Depth" is the number of layers when gates that can run in parallel are put in the same layer; it is a guide to run time. Over 20 random seeds (0 to 19), the number of CZ gates stayed constant for each condition and only the depth at level 1 on the line moved, within 120 to 130 (a result for this example only; other circuits may vary in number). "Line" and "full" are examples, not the connectivity of any real chip.

Reading: for the same circuit, on a chip with qubits in a line, weak optimisation gave 56 CZ gates and strong optimisation gave 30. Full connectivity gave 20 (Our calculation). The more two-qubit gates there are, the more errors pile up, so before the "number of qubits", how large the circuit becomes after conversion decides whether it can run at all. Both the chip's connectivity and the transpiler's skill matter here.

(5) "Compilation" in a wider sense

Transpiling is a conversion at the level of circuits. Below it is control at the level of pulses (microwave waveforms); above it is the stage of turning an algorithm into a circuit. Machines that perform error correction add further stages: expanding logical gates into sequences of physical gates (lattice surgery and so on; see the logical-qubit article) and "decoding", reading out errors and deciding corrections. These involve software and also very fast classical processing (Section 6).

5. Using it through the cloud — from order to result

(1) An everyday example: sending a sample and conditions to a shared facility

In materials research, expensive electron microscopes and synchrotron facilities are often used as shared facilities. You send the sample and measurement conditions, and when your turn comes the facility staff measure it and return the data. Cloud use of a quantum computer is much the same. The "sample" is the circuit, and the "measurement conditions" are settings such as the number of runs (shots). The waiting line is the queue, and one request is a job.

(2) The flow of use

Of the eight steps, 1 to 3 and 8 happen on your own classical computer. Steps 4 to 7 are the work of the cloud and the quantum chip. Step 2, "try it small", matters. Real machines are scarce, waiting takes time, and usage is metered (billed), so the standard practice is to check on a local simulator first that the circuit does what you intended (our commentary).

(3) Shots — why we run the same circuit many times

Measuring a qubit gives a probabilistic result. So we run the same circuit N times and count the frequency of each outcome. N is the number of shots. When the probability p of an outcome is estimated from frequencies, a statistical error (the standard error) remains, of size √(p(1−p)/N). Multiplying N by 100 cuts the error to only a tenth.

(4) Which services, and how they can be used

The table below summarises what we could confirm in official material. Prices change easily, so we give no amounts. We do not rank the services.

Checked 16 October 2026. The summaries rely on each company's official documents and pages. The scope of services, device types and plan names can change. We did not check the terms of use of Quantinuum and IonQ.

(5) IBM's "execution modes": job, batch and session

In work that goes back and forth between quantum and classical computers (Section 6), joining the queue anew each time takes a long time. So IBM's service has three execution modes that differ in how they queue [Ref. 4] Sourced.

Source: IBM Quantum official documentation (Ref. 4). For what "reserved" means and the details of time limits (TTL), see that document.

6. Hybrid quantum-classical execution

(1) An everyday example: tasting while adjusting the seasoning

When you adjust the flavour of a pot, you taste, add seasoning, and taste again, repeatedly. Here, the taster is the quantum chip and the one deciding how much to add is the classical computer. A method in which a quantum circuit is used for "evaluation", and the classical computer looks at the result and re-sets the circuit's parameters (adjustment knobs inside the circuit), repeating the back-and-forth, is called hybrid (quantum-classical) execution.

The best-known example is the variational quantum eigensolver (VQE). To find the energy of a molecule, a parameterised circuit prepares a "trial state", and its energy expectation value is measured on the quantum chip. The classical computer updates the parameters in the direction that lowers the expectation value, and this repeats. It rests on the idea that the lower the energy expectation, the closer the state is to the true lowest-energy state (the variational principle) (our explanation). Peruzzo and colleagues demonstrated the principle on a photonic quantum processor in 2014 [Ref. 27], and in 2017 Kandala and colleagues found ground-state energies of molecules up to BeH₂ (up to six qubits) on superconducting qubits [Ref. 28] Sourced.

(2) Classical processing next to the quantum chip works on a microsecond scale

Hybrid work has two time worlds.

• Near time (via the cloud): a round trip of sending a circuit and receiving the result takes seconds to minutes or more, including waiting. The back-and-forth of VQE happens in this world
• Real time (within the qubits' coherence time): classical processing that reads a measurement result and decides the next operation before the qubits fall apart. Error-correction decoding and other work that needs microsecond response belong here

The OpenQASM 3 paper builds on exactly this distinction. It says the language was made to handle classical computation in real time, within the qubits' coherence time, and in looser near time, and to allow control flow and calls to external classical functions [Ref. 9] Sourced.

The figures are values stated in each source. One surface-code cycle is about 1.1 μs and the real-time decoder's mean latency is 63 μs (distance 5), as reported in Google's paper [Ref. 31] Sourced. IBM announced decoding of qLDPC codes in real time in under 480 nanoseconds on classical hardware [Ref. 32]. NVIDIA describes NVQLink as having a GPU-to-QPU throughput of 400 Gb/s and a latency of under 4 microseconds, and says that decoding on Quantinuum's Helios had a reaction time of 67 microseconds [Ref. 17]. All of these are company announcements (company claims), and figures that measure different things under different conditions cannot simply be compared.

(3) Combining with supercomputers

Raw measurement results from a quantum chip contain noise. So methods are being studied in which measurement results are processed by large classical computations to solve chemistry problems. The work of Robledo-Moreno and colleagues (a method called sample-based quantum diagonalisation, SQD) processed measurement results (quantum samples) from the superconducting processor Heron on the supercomputer Fugaku, and computed the ground states of the dissociation of the nitrogen molecule and of two iron-sulfur clusters ([2Fe-2S] and [4Fe-4S]). It used circuits of up to 77 qubits and 10,570 gates, and says the method gives an upper bound on the ground-state energy [Ref. 29] Sourced. Alexeev and colleagues have also published a perspective paper that organises the idea of "quantum-centric supercomputing", closely integrating quantum and supercomputers, from the viewpoint of materials science [Ref. 30]. In November 2025 IBM announced that it would provide a C API for Qiskit, and a C++ interface built on it, so that quantum computers can be programmed directly from HPC (high-performance computing) environments [Ref. 32] (company description).

7. A materials engineer's view — the link to materials computation, and handling data

Why does an article on software have a materials view? There are three reasons. (1) One of the leading intended uses of quantum computers is computation in materials and chemistry. (2) The limit of simulating them on an ordinary classical computer is close to what people in materials computation already feel. (3) Like experimental data, the results of quantum computing need discipline in record-keeping and reproducibility.

8. What could not be confirmed, and a summary

What could not be confirmed

• Measured waiting times (queues) and price amounts: they change easily and depend on conditions, so we give no figures.
• Latest versions of tket, Q# / QDK and the Braket SDK: we checked only Qiskit, Cirq, CUDA-Q and PennyLane on PyPI.
• The licence of the QIR specification and of OQTOPUS: we could not confirm them from GitHub's display (the QIR specification repository shows its licence as undetermined).
• International standardisation of QIR and OpenQASM: we could not confirm any statement that they are ISO or similar standards.
• Terms of use and prices of Quantinuum's and IonQ's cloud services: we confirmed only that the companies' sites present them, and not the details.
• Independent verification of IBM's "decoding in under 480 nanoseconds", of NVIDIA's NVQLink latency and of Quantinuum's decoding time: treated as company announcements; we did not confirm independent verification.
• The public availability of Qiskit's C API and C++ interface as of October 2026: we have only the statement in the November 2025 announcement.
• The latest measured values of each benchmark for each machine: this article concentrates on how to read the metrics and gives no list of values.
• The text of ISO/IEC 4879:2024, and the publication status of IEEE P7131: the text is paid; the publication status could not be confirmed.
• Statistics on SDK user numbers or market share: we could not confirm them, so we do not write "most widely used" or any other ranking.

9. How to read evaluations and standards

The yardsticks for software and cloud use are: (1) how circuits are written and passed on (the description specifications), (2) the machine's quality, (3) speed, (4) scale and (5) performance on applications. Hardware performance is treated in detail in separate articles ("Coherence and Fidelity" and "How to Read Quantum Advantage Claims"), so here we organise the metrics that are visible from the software and execution side. Check date: 16 October 2026.

The arrangement of the table is commentary (ours). The names, sources and dates of each metric were checked against papers and official pages (checked 16 October 2026). The text of standards is paid, so we stay with titles and scope.

Cautions in reading (for materials engineers)

• A "benchmark number" is a value with its conditions: even on the same machine it can change with transpiler settings, software versions and calibration time. Numbers without records cannot be compared (Section 7)
• Look at the relationship between proposer and what is measured: quantum volume, CLOPS and layer fidelity are mainly metrics proposed by IBM researchers [Ref. 33, 34, 35]. Whether other companies use them, and whether independent third parties measure them, must be checked separately
• Separate preprints from peer-reviewed work: CLOPS_h, QUOPS and Metriq are 2026 preprints [Ref. 37, 38, 39]
• Physical qubits or logical qubits: the QUOPS paper has evaluations on both physical qubits and logical qubits [Ref. 37]. The numbers mean entirely different things
• Standards are still at the stage of terminology: ISO/IEC 4879 is a terminology standard with no legal force (in general a standard becomes binding only when cited in law or in a contract; our explanation). Standards for performance metrics are still draft standards such as IEEE P7131, and we could not confirm any established consensus

10. Glossary

11. References

1. Javadi-Abhari A. et al. "Quantum computing with Qiskit", arXiv:2405.08810 (2024) — arxiv.org/abs/2405.08810
2. IBM Quantum "Transpiler stages" (Qiskit official documentation; checked 16 October 2026) — quantum.cloud.ibm.com/docs/en/guides/transpiler-stages
3. IBM Quantum "Introduction to primitives" (official documentation; checked 16 October 2026) — quantum.cloud.ibm.com/docs/en/guides/primitives
4. IBM Quantum "Introduction to Quantum Compute execution modes" (official documentation; checked 16 October 2026) — quantum.cloud.ibm.com/docs/en/guides/execution-modes
5. IBM Quantum "Plans overview" (official documentation; checked 16 October 2026) — quantum.cloud.ibm.com/docs/en/guides/plans-overview
6. Amazon Web Services "Amazon Braket pricing" (official page; checked 16 October 2026) — aws.amazon.com/braket/pricing/
7. Amazon Web Services "What is Amazon Braket?" (official documentation) — docs.aws.amazon.com/braket/…/braket-what-is-Braket.html
8. Microsoft "What is Azure Quantum?" (official documentation; checked 16 October 2026) — learn.microsoft.com/…/overview-azure-quantum
9. Cross A. et al. "OpenQASM 3: A Broader and Deeper Quantum Assembly Language", ACM Transactions on Quantum Computing 3, 1–50 (2022), DOI 10.1145/3505636 — doi.org/10.1145/3505636
10. OpenQASM GitHub repository (specification v3.1.0, 15 May 2024; the official site is openqasm.com; licence Apache-2.0; checked 16 October 2026) — github.com/openqasm/openqasm
11. QIR Alliance "Quantum Intermediate Representation" (official site; checked 16 October 2026) — qir-alliance.org
12. Li G., Ding Y., Xie Y. "Tackling the Qubit Mapping Problem for NISQ-Era Quantum Devices", ASPLOS '19, 1001–1014 (2019), DOI 10.1145/3297858.3304023 — doi.org/10.1145/3297858.3304023
13. Zou H. et al. "LightSABRE: A Lightweight and Enhanced SABRE Algorithm", arXiv:2409.08368 (2024) — arxiv.org/abs/2409.08368
14. Sivarajah S. et al. "t|ket⟩: a retargetable compiler for NISQ devices", Quantum Sci. Technol. 6, 014003 (2020), DOI 10.1088/2058-9565/ab8e92 — doi.org/10.1088/2058-9565/ab8e92
15. Bergholm V. et al. "PennyLane: Automatic differentiation of hybrid quantum-classical computations", arXiv:1811.04968 (2018) — arxiv.org/abs/1811.04968
16. NVIDIA "CUDA-Q" (official documentation; checked 16 October 2026) — nvidia.github.io/cuda-quantum/latest/
17. NVIDIA "World's Leading Scientific Supercomputing Centers Adopt NVIDIA NVQLink to Integrate Grace Blackwell Platform With Quantum Processors", press release (17 November 2025) (company announcement) — nvidianews.nvidia.com/news/scientific-supercomputing-centers-nvqlink-…
18. Qiskit GitHub repository (licence Apache-2.0; checked 16 October 2026) — github.com/Qiskit/qiskit
19. Cirq GitHub repository (Apache-2.0) — github.com/quantumlib/Cirq
20. CUDA-Q GitHub repository (Apache-2.0) — github.com/NVIDIA/cuda-quantum
21. PennyLane GitHub repository (Apache-2.0) — github.com/PennyLaneAI/pennylane
22. tket GitHub repository (under Quantinuum's organisation; Apache-2.0) — github.com/Quantinuum/tket
23. Microsoft Quantum Development Kit (Q#) GitHub repository (MIT) — github.com/microsoft/qdk
24. Amazon Braket SDK GitHub repository (Apache-2.0) — github.com/amazon-braket/amazon-braket-sdk-python
25. PyPI pages of each package (qiskit 2.6.0, cirq 1.7.0, cudaq 0.16.0, pennylane 0.45.1; checked 16 October 2026) — pypi.org/project/qiskit/, pypi.org/project/cirq/, pypi.org/project/cudaq/, pypi.org/project/pennylane/
26. Kakuko N. et al. "A Practical Open-Source Software Stack for a Cloud-Based Quantum Computing System" (OQTOPUS), arXiv:2507.23165 (2025); IEEE QCE 2025, DOI 10.1109/QCE65121.2025.00092 — arxiv.org/abs/2507.23165
27. Peruzzo A. et al. "A variational eigenvalue solver on a photonic quantum processor", Nature Communications 5, 4213 (2014), DOI 10.1038/ncomms5213 — doi.org/10.1038/ncomms5213
28. Kandala A. et al. "Hardware-efficient variational quantum eigensolver for small molecules and quantum magnets", Nature 549, 242–246 (2017), DOI 10.1038/nature23879 — doi.org/10.1038/nature23879
29. Robledo-Moreno J. et al. "Chemistry beyond the scale of exact diagonalization on a quantum-centric supercomputer", Science Advances 11, eadu9991 (2025), DOI 10.1126/sciadv.adu9991 (arXiv:2405.05068) — doi.org/10.1126/sciadv.adu9991
30. Alexeev Y. et al. "Quantum-centric Supercomputing for Materials Science: A Perspective on Challenges and Future Directions", Future Generation Computer Systems (2024), DOI 10.1016/j.future.2024.04.060 (arXiv:2312.09733) — arxiv.org/abs/2312.09733
31. Google Quantum AI and Collaborators "Quantum error correction below the surface code threshold", Nature 638, 920–926 (2025), DOI 10.1038/s41586-024-08449-y (arXiv:2408.13687) — doi.org/10.1038/s41586-024-08449-y
32. IBM "IBM Delivers New Quantum Processors, Software, and Algorithm Breakthroughs on Path to Advantage and Fault Tolerance", press release (12 November 2025) (company announcement) — newsroom.ibm.com/2025-11-12-ibm-delivers-new-quantum-processors,->newsroom.ibm.com/2025-11-12-ibm-delivers-new-quantum-processors
33. Cross A. W. et al. "Validating quantum computers using randomized model circuits", Phys. Rev. A 100, 032328 (2019), DOI 10.1103/PhysRevA.100.032328 — doi.org/10.1103/PhysRevA.100.032328
34. Wack A. et al. "Quality, Speed, and Scale: three key attributes to measure the performance of near-term quantum computers", arXiv:2110.14108 (2021) — arxiv.org/abs/2110.14108
35. McKay D. C. et al. "Benchmarking Quantum Processor Performance at Scale", arXiv:2311.05933 (2023) — arxiv.org/abs/2311.05933
36. Lubinski T. et al. "Application-Oriented Performance Benchmarks for Quantum Computing", IEEE Transactions on Quantum Engineering 4, 1–32 (2023), DOI 10.1109/TQE.2023.3253761 — doi.org/10.1109/TQE.2023.3253761
37. Proctor T. et al. "Benchmarking the computational power of quantum computers", arXiv:2609.12146 (September 2026) (preprint) — arxiv.org/abs/2609.12146
38. Wack A. "CLOPS: Benchmarking System Speed at Utility Scale", arXiv:2608.18044 (August 2026) (preprint) — arxiv.org/abs/2608.18044
39. Cosentino A. et al. "Metriq: A Collaborative Platform for Benchmarking Quantum Computers", arXiv:2603.08680 (March 2026) (preprint) — arxiv.org/abs/2603.08680
40. McKay D. et al. (IBM) "How to measure the performance of a quantum computer", IBM Quantum blog (16 July 2026) (company description) — ibm.com/quantum/blog/hardware-metrics-2026
41. Acuaviva A. et al. "Benchmarking quantum computers: towards a standard performance evaluation approach", Quantum Sci. Technol. 11, 025004 (2026), DOI 10.1088/2058-9565/ae4269 — doi.org/10.1088/2058-9565/ae4269
42. ISO/IEC 4879:2024 "Information technology — Quantum computing — Vocabulary" (published May 2024). Number, title, date and "Published" status checked on the listing page of the Institute for Standardization of Serbia (ISS) — iss.rs/en/project/show/iso:proj:80432
43. IEEE P7131 Working Group "Quantum Benchmarking Working Group P7131" (the working group's site, covering a draft standard for performance metrics and benchmarks of quantum computing) — sagroups.ieee.org/7131
44. Quantinuum "Technical perspective: By the end of the decade, we will deliver universal, fully fault-tolerant quantum computing", official blog (September 2024). The site navigation describes how Helios is offered (on-premises or cloud), and the text states a quantum volume above two million — quantinuum.com/blog/technical-perspective…
45. IonQ "IonQ roadmap" (official page; the site navigation lists Quantum Cloud; checked 16 October 2026) — ionq.com/roadmap
46. NVIDIA "NVIDIA NVQLink Architecture Integrates Accelerated Computing with Quantum Processors", NVIDIA Technical Blog (company description) — developer.nvidia.com/blog/nvidia-nvqlink-architecture-…

12. Claim-to-source audit

Last updated 16 October 2026. Sources are limited to primary material (official documentation, peer-reviewed papers, arXiv papers, public GitHub and PyPI information, official pages of the companies, and the listing page of an ISO standard). Company announcements and plans are kept separate. Software versions, service plans and prices change often. The results of code and numerical estimates are our own calculations on local simulators, not results from real hardware. Waiting times and price amounts, the latest versions of some SDKs, the licences of QIR and OQTOPUS, the state of international standardisation, the terms of use of Quantinuum and IonQ, independent verification of company speed claims, the public availability of Qiskit's C API, the latest benchmark values for each machine, the text of ISO/IEC 4879, the publication status of IEEE P7131 and SDK user numbers could not be confirmed and are not stated here. All figures are explanatory concept diagrams or drawings that include our calculations; Fig. 1 and Fig. 7 are ImageGen-generated conceptual illustrations.