Release News: Qiskit v2.4 is here!

We're excited to announce the release of Qiskit SDK v2.4! The latest minor release in the v2.x series continues our efforts to strengthen the SDK’s core infrastructure—making it faster, more extensible, and more practical to use as circuits grow larger and compilation workflows become more sophisticated.

Over the past several releases, we’ve been laying the groundwork for deeper integrations with compiled languages, higher-performance compilation pathways, and more scalable internal tooling. Qiskit v2.4 builds directly on that foundation by consolidating and extending existing capabilities in each of these areas and beyond.

A key priority for Qiskit v2.4 is delivering progress without disruption. Many of the improvements described below apply automatically, require no change to existing code, and are designed to scale with the size and complexity of your workloads. Whether you’re building custom compiled Python extensions or experimenting with early fault-tolerant circuits, Qiskit v2.4 aims to make your workflows faster and easier.

Read on to learn about the top features and performance improvements you’ll be getting when you update to v2.4, and be sure to check our release notes for details on anything not covered here.

The TL;DR

The biggest updates we’re going to cover in this article include the following:

• Enabling compiled Python extensions in Qiskit. Qiskit v2.4 makes it possible to build and distribute Python extensions compiled against Qiskit’s C API on PyPI. That means you can build high-performance extensions without your users needing custom tooling.
• Improvements in fault-tolerant pipeline. New fault-tolerant transpilation pipeline delivers faster Clifford+T compilation and lower T counts by combining staged passes with gridsynth-based RZ synthesis. Improvements apply automatically when targeting discrete basis gate sets, making FT‑style compilation faster and more practical at larger scales.
• Further extending the C API. Qiskit’s C API continues to expand in v2.4, with new support for parameterized gates, Pauli-based computation, DAG-level transpiler passes, and text-based circuit drawing. Our goal: make it practical to build deeper, higher-performance compiler tooling in C while integrating cleanly with existing Python workflows.
• Faster QPY serialization. The QPY circuit serialization format has been refactored to use Rust internally, resulting in faster serialization and deserialization of circuits with no changes required to existing workflows.

Top new features & improvements

In this section we’ll cover some of the most important new features and enhancements included in this release. If you want to know more about these, or other features that didn’t make it into this article, you can see the full list of new features here.

Enabling compiled Python extensions in Qiskit

Qiskit v2.4 makes it possible to build and distribute Python extensions compiled against Qiskit’s C API. Even if you don’t write C or Rust code yourself, this change enables external packages and experimental tools to integrate tightly with Qiskit and share optimized functionality back with the community.

For developers working in compiled languages, this update makes it practical to move performance‑critical or low‑level components into compiled extensions that you can distribute while keeping Qiskit’s Python interfaces intact. Extensions can now depend on Qiskit at build time to locate the necessary headers. Then you can package and distribute them as ordinary Python wheels using standard Python tooling.

To illustrate this workflow, we’ve built a working external transpiler pass as a compiled Python extension. The demo ports the AddSpectatorMeasures pass—available in the Qiskit addon utilities package—from Python to C using the C API. This should give you a sense of how v2.4 makes it posible to implement a functioning customization outside the core SDK.Note that Qiskit’s C API is still considered unstable, and binary compatibility across minor releases is not yet guaranteed. We plan to commit to versioned stability in a future release.

Importantly, the build and packaging process remains entirely conventional. The extension uses standard setuptools infrastructure, integrates with pyproject.toml, and requires no custom compiler flags or environmental tricks beyond a typical C toolchain.

For contributors and advanced users, this opens the door to richer extension patterns—custom passes, analyses, and optimizations—while maintaining Python as the primary user interface.

Improvements in fault-tolerant pipeline

The latest Qiskit release introduces a significantly improved fault-tolerant transpilation pipeline for targeting discrete Clifford+T basis gate sets, delivering higher compilation quality and substantially faster runtimes. These improvements are designed with fault-tolerant workflows in mind, but they also reduce compilation time and improve circuit quality for any workflow that targets discrete gate sets.

The pipeline first applies Qiskit’s high-performance compilation flow for continuous basis gate sets targeting Clifford+RZ, then translates the resulting circuits into the discrete Clifford+T gate set and performs optimizations directly on that representation. This separation means that each stage can use the most effective algorithms for its task, improving both performance and output quality.

Additionally, Qiskit now uses the gridsynth algorithm as the default method for synthesizing RZ rotations in a discrete basis, replacing the SolovayKitaevDecomposition used in prior releases. gridsynth produces substantially lower T counts, and the new fault-tolerant transpilation pipeline also caches angle synthesis results to further reduce redundant work across large circuits. The combined effect is faster compilation and circuits that require much fewer of those costly T gates.

Best of all, you don’t have to change anything about your workflow to get these enhancements. They’re enabled by default when targeting a discrete basis gate set. Benchmarks show consistent improvements in both compilation time and T-count reduction, often by large margins. You can see these gains in the figure below, which shows how v2.4 compares against v2.3 across an array of standard fault-tolerant circuit benchmarks.

Left: Ratio of T counts produced by Qiskit v2.4 relative to v2.3 when compiling to a Clifford+T basis. Right: Ratio of compiled runtimes for the same circuits. Smaller values indicate better performance in v2.4. The dashed red line indicates parity between the two versions. Points below the line correspond to cases where v2.4 achieves lower T counts or faster compilation. Benchmarks were run on circuits from FTCircuitBench (arXiv:2601.03185, GitHub here) with a two‑minute timeout, indicated by 𐄂 (v2.3 timeout) and ♦ (v2.4 timeout).

If you previously limited circuit size, depth, or synthesis accuracy due to FT compilation costs, it’s worth revisiting those assumptions in Qiskit v2.4.

Further extending the C API

Qiskit’s C API continues to expand its support for advanced and performance-critical compiler workflows. The v2.4 release specifically adds functionality to support more advanced compiler-level workflows, enabling deeper integration with low-level quantum compiler tooling.

A major component of this expansion is broader support for circuit and transpiler manipulation directly from C. The C API now exposes DAG-level transpiler pass functions that operate directly on this representation. That means C-based tools can analyze and transform circuits at the same level as the Qiskit transpiler, avoiding repeated conversions between circuit and DAG forms when chaining multiple passes together.

The C API has also grown to support richer circuit construction. Users can now define custom gates, work with parameterized gates via QkParam, and retrieve or manipulate gate parameters directly from circuits and targets. Additionally, text-based circuit drawing is now available through the C interface, making it easier to debug and inspect C-generated circuits without re-entering Python.

Finally, Qiskit v2.4 introduces C API support for Pauli-based computation (PBC). The API exposes Pauli-product rotation and measurement instructions, along with transformation passes that convert standard circuits into Pauli-based forms. This enables C-based workflows to construct, analyze, and optimize circuits using Pauli-centric representations that are increasingly important for fault-tolerant compilation strategies.

Faster QPY serialization

The QPY module has been refactored and partially ported to Rust. This work lays the foundation for eventually exposing the serialization interface through the C API. However, users can already benefit from the refactor today through improved runtime performance when serializing and deserializing circuits.

To underscore these gains, we benchmarked QPY serialization and deserialization using randomly generated circuits of increasing size. The example below illustrates the structure of the benchmark, which creates random circuits, writes them to an in-memory buffer using QPY, and then reads them back:

import io
import time
from qiskit.circuit.random import random_circuit
from qiskit import qpy

for i in range(1, 1000):
    circ = random_circuit(i, i)
    with io.BytesIO() as f:
        dump_start = time.perf_counter()
        qpy.dump(circ, f)
        dump_stop = time.perf_counter()
        f.seek(0)
        load_start = time.perf_counter()
        qpy.load(f)
        load_stop = time.perf_counter()
        print(
            f"size {i}:  "
            f"dump in {(dump_stop - dump_start):.5f} and "
            f"load in {(load_stop - load_start):.5f}")

The figure below compares the total time spent serializing (dump) and deserializing (load) circuits in Qiskit v2.3 and v2.4 across a range of circuit sizes. Results indicate faster performance in v2.4 (in blue) relative to v2.3 (in red), with consistent improvements in both serialization and deserialization time and particularly notable gains for larger circuits.

Upgrade considerations

For the most part, we expect that you should be able to adopt the Qiskit v2.4 release without modification, but the following points may be relevant depending on how you use the SDK.

Linux build platform (glibc) requirements

Starting with Qiskit v2.4, packages published to PyPI for Linux are now built using the manylinux_2_28 platform. This effectively raises the minimum required version of glibc on Linux systems to 2.28, up from the previous requirement of glibc 2.17 under manylinux2014.

Linux distributions such as Debian 10+ (buster), Ubuntu 18.10+ (cosmic), Fedora 29+, and RHEL 8+ all include glibc 2.28, so the packages on PyPI should work on these distributions and newer versions. Systems based on older distributions will no longer be able to run Qiskit using the published builds due to incompatible system libraries.

For newer Python versions, this change largely aligns with existing ecosystem requirements. For example, Numpy on Python 3.14 already requires glibc 2.28, meaning Qiskit was effectively unusable on systems limited to manylinux2014 dependencies in those environments. In v2.4, the glibc baseline has been updated for all supported Python versions to ensure consistent builds.

It may still be possible build Qiskit from source on systems with older glibc versions, but these configurations are no longer tested in CI and should be considered unsupported.

C API stability

While the C API has advanced and expanded significantly in v2.4, it should still be considered unstable across minor releases. This means we cannot guarantee, for example, that extension modules compiled against Qiskit 2.4 will be able to run against Qiskit 2.5 or later. We plan to introduce explicit stability guarantees for the C API in a future release.

Minimum supported Python version

As a reminder, Qiskit SDK versions 2.3 and above require at least Python 3.10, following the end of life of Python 3.9. Users running older Python versions will need to upgrade their environment before installing v2.4.

Final notes

And there you have it! The most important details of the latest Qiskit SDK release. Remember, if you want to put ideas forward for future versions of Qiskit you can always open a GitHub issue to request a feature or report a bug! And if you want to follow what's coming up in the next release you can take a look at the Qiskit Roadmap.

Many people contributed to this release, special thanks to (in alphabetical order):

Abigail J. Cross, Akhil, Alexander Ivrii, Ameya Bhave, Arnav Kapoor,
Arthur Strauss, Bruno Caballero, byteforge, Debasmita Bhoumik, 
Dikran Meliksetian, Eli Arbel, Emmanuel Osalotioman Osazuwa, Eric Arellano,
Esteban, Evgenii Zheltonozhskii, Gadi Aleksandrowicz, Heet Bhatt, Ian Hincks,
Ikko Hamamura, Jake Lishman, John Lapeyre, Julien Gacon, Kalyan Dasgupta,
Kurian Uthuppu, Luca Oliva, Luciano Bello, Matthew Treinish, Max Rossmannek,
Moritz, PandaMan, phioa, Rajdeep Aher, Raynel Sanchez, Ritajit Majumdar, 
Shelly Garion, Shivam, and Yael Ben-Haim

This blog post was written by Robert Davis with help from Luciano Bello, Julien Gacon, Jake Lishman, Matthew Treinish, Kaelyn Ferris, and Alexander Ivrii.