Quantum researchers regain the controls: IBM's directed execution puts error-correction pipelines in client hands

The quantum researcher's toolkit just grew a new layer. The error-mitigation and error-correction pipeline that used to live inside IBM's cloud now runs client-side, where it can be inspected, customized, and composed by hand at the scale of thousands of circuit variants, on the same 100+ qubit hardware. The capability is IBM's new "directed execution" model, and per IBM, the performance tax on doing this work yourself is zero.

Quantum error correction is the engineering work of protecting fragile quantum states from noise. It is the field's central problem on the path to useful machines, and until now, much of the associated work happened server-side on IBM's quantum cloud: the twirling, randomization, mitigation, and post-processing routines that turn noisy hardware output into something a researcher can trust ran behind an API. Directed execution moves that pipeline to the researcher's side of the wire. A new Executor primitive powers the change and scales to thousands of circuit variants, letting users compose custom mitigation and correction routines that previously had to be requested and run on IBM's servers.

For a researcher building a custom pipeline, the difference is concrete. Twirling (averaging over many equivalent circuit variants to cancel certain noise effects), randomization, mitigation, and post-processing can now be sequenced and rerun locally. Pipelines that previously had to be triggered by an IBM-side request can be composed by hand against the specific mitigation strategy the researcher wants to test. The Executor primitive is the substrate that makes those compositions possible at scale.

For researchers already building on IBM's stack, the entry cost is low. Existing code written against the Qiskit Sampler and Estimator primitives continues to work via a provider update; the new model sits underneath them as a lower layer. For researchers writing active error-correction work, including the postselected QEC and distance-5 surface-code experiments that represent the field's main path forward, the change is more substantial. The same framework behind IBM's own quantum advantage demonstrations is now the foundation for client-side research, and the doors it opens are the ones the community has been asking for.

IBM's directed execution blog post frames the work as a platform-level shift in how much of the stack researchers can see and modify. The vendor's own measurement, on its distance-5 surface code, reports that the per-round logical error rate drops by up to 2.8x. Read that as one benchmark on IBM hardware from IBM's own research, not a general speedup and not a field-wide result. A 2.8x reduction in a specific IBM benchmark tells a working researcher that the abstraction is sound; it does not tell them what they will build on top of it.

The historical arc IBM sketches in the same post is worth reading. The original backend.run model gave direct, low-level access. The Sampler and Estimator primitives that followed traded some of that control for ergonomic, near-time, server-side pipelines. Directed execution is the third step: a lower-level model that keeps the ergonomics for users who want them and hands the pipeline back to users who need to touch it. Researchers who need to chain custom mitigation, post-processing, and correction stages by hand now have a platform that lets them.

What gets built on top is the next signal worth tracking. The framework covers postselected QEC and distance-5 surface codes, scales to thousands of circuit variants, and runs on hardware that crosses the 100-qubit line. The capability is in the platform; the research program is the part that has yet to be written.