Ask what makes a quantum computer good and most people reach for two numbers: how many qubits it has, and how clean those qubits are. Both matter. Neither tells you how long you will wait for an answer. A machine with flawless qubits that crawls through one circuit every few seconds is close to useless for the kinds of problems people actually want to run, because those problems demand thousands, sometimes millions, of circuit executions stitched together. Speed is the quiet third axis, and the industry has a yardstick for it: CLOPS, short for Circuit Layer Operations Per Second.
Why speed is a real problem
A quantum program rarely runs once. Because measuring a qubit returns a single random bit drawn from a probability distribution, you have to repeat the same circuit many times to estimate what that distribution actually looks like. A few thousand repetitions, called shots, is routine. Then there are algorithms that wrap the quantum circuit inside a classical optimization loop, tweaking parameters, running again, adjusting, running again. Variational chemistry calculations and error-mitigation routines can chain together enormous numbers of these iterations.
Every one of those runs carries overhead. The qubits have to be reset to a known state. Control electronics load the next circuit. Microwave or laser pulses fire. The results get read out, shipped to a classical computer, processed, and the next batch gets queued. On many systems the dead time between circuits dwarfs the actual quantum computation, which lasts only microseconds. If you add qubits but the plumbing stays slow, your headline number grows while your throughput stalls.
What CLOPS measures
IBM introduced CLOPS to capture this end-to-end rhythm rather than just the raw gate speed. The benchmark runs a set of parameterized circuits that resemble the structure of real workloads, with a defined number of qubits, layers of gates, and parameter updates between runs. It then counts how many layers of operations the full system completes per second, including the classical overhead of loading parameters and handling results.
The key word is system. CLOPS deliberately bundles together things that a gate-fidelity test ignores: the reset time, the readout time, the latency of the control stack, the speed of the classical computer feeding the quantum one, and the cost of recompiling circuits with new parameters. A machine can have beautiful gates and still post a mediocre CLOPS score if its electronics stall between shots. That is exactly the point. The number rewards engineering the whole pipeline, not just polishing the qubits.
The levers that move the number
Several improvements show up directly in a better CLOPS result.
- Faster reset. Actively driving qubits back to their ground state beats waiting for them to decay naturally, trimming dead time between shots.
- Parallel readout. Measuring many qubits at once, rather than in sequence, shortens the longest single step in many runs.
- Keeping parameters on the edge. Updating circuit parameters inside the control hardware, instead of recompiling and re-uploading an entire circuit from a distant server, cuts the loop latency that kills variational algorithms.
- Tighter classical coupling. Putting the controlling computer physically and logically close to the quantum processor removes network round-trips.
None of these touch coherence time or two-qubit fidelity. They are systems engineering, and they can swing throughput by large factors between generations of the same hardware.
A benchmark, not the benchmark
CLOPS should not be read in isolation. A machine could post a dazzling speed figure while its qubits are too noisy to produce useful answers, so speed only counts once accuracy clears the bar for your problem. That is why practitioners look at CLOPS alongside qubit count, error rates, and quality metrics like Quantum Volume. Each captures a different failure mode. A slow but accurate machine wastes your calendar; a fast but sloppy one wastes your results.
The benchmark also leans toward the circuit-and-shots model used by superconducting and some trapped-ion gate machines. Comparing a CLOPS figure across radically different architectures, say a superconducting processor against a neutral-atom analog simulator, invites confusion, because the underlying execution model differs. Within a single platform and across its roadmap, though, the trend line is honest and useful.
As the field pushes toward error correction, speed matters more, not less. Fault-tolerant machines will run staggering numbers of cycles, decoding errors in real time between them. The classical and quantum halves will have to keep pace with each other continuously. A benchmark that already forces vendors to time the whole relay race, not just the sprint in the middle, is good preparation for that future.
