IBM has expanded its quantum fleet with the Kingston processor, achieving a record-breaking 340,000 Circuit Layer Operations Per Second (CLOPS).
What Kingston adds to IBM’s quantum fleet
IBM’s Kingston processor is a 156-qubit system in the Heron r2 line. It is not a research side project; it is a production-facing addition to IBM’s quantum fleet. That framing matters for teams that already run workloads on cloud-accessible quantum hardware: a new machine expands capacity, reduces queue pressure, and gives algorithm developers another target with a clear qubit count and generation label.
Heron r2 is an evolutionary step rather than a full redesign of the control stack. Evolution usually means refinements to coherence, connectivity, gate quality, and classical control latency—not a rewrite of how you submit circuits. For practitioners, the practical takeaway is continuity: existing circuit patterns, transpilation flows, and error-mitigation habits remain relevant while the hardware underneath improves.
Why CLOPS is the metric to watch here
Kingston is reported at 340,000 Circuit Layer Operations Per Second (CLOPS). CLOPS measures how quickly a system can execute layers of quantum operations and return results, not how many qubits it has. Qubit count sets the size of the Hilbert space you can explore; CLOPS sets how many useful experiments you can finish in a session. A high CLOPS figure favors iterative work—parameter sweeps, variational loops, calibration checks, and rapid debugging of circuit structure.
Treat CLOPS as a throughput budget. If your algorithm needs many shots, many circuit variants, or tight classical–quantum feedback, wall-clock time becomes the constraint long before you exhaust theoretical qubit capacity. A fleet processor optimized for layer throughput is most valuable when your workflow is experimental and repetitive, not when you only need a single deep circuit once.
How to use a 156-qubit Heron r2 system well
Design around the real topology and noise, not an abstract all-to-all model. Map high-interaction subroutines onto well-connected regions of the device, keep two-qubit gate depth under control, and prefer shallow, modular circuit blocks that can be recompiled when layouts change. Prefer mid-circuit measurement and conditional logic only when the control stack and your software path actually support them end to end.
- Benchmark your own circuits: depth, two-qubit gate count, and shots-to-signal before and after layout optimization.
- Budget classical post-processing and error mitigation as first-class costs; they often dominate end-to-end runtime.
- Split exploratory runs (high shot diversity, lower depth) from validation runs (fixed circuits, higher shot counts) so CLOPS gains show up where iteration matters most.
What “fleet expansion” means for day-to-day work
Adding Kingston is a capacity and throughput move. More machines with a named generation and a published CLOPS number let teams plan batch jobs, schedule calibration-sensitive experiments, and compare results across devices of the same family. Cross-device comparison only works if you lock circuit definitions, random seeds where applicable, and analysis pipelines so hardware differences are visible rather than confounded by software drift.
For near-term applications—chemistry toy models, optimization demos, error-mitigation studies, and systems research—the win is operational: more runs per day on a 156-qubit Heron r2-class processor with strong layer throughput. Build circuits that respect connectivity, measure what you care about with enough shots, and use the CLOPS headroom to tighten the experiment loop instead of only chasing larger abstract qubit counts.