• Quantum Research
• Blog

We’re pleased to announce the release of Qiskit SDK v2.5! Each minor release in the v2.x series has served to strengthen Qiskit’s foundations—making it faster, more extensible, and better equipped to handle the growing complexity of quantum workloads. From improving performance to expanding interoperability, the goal is always to deliver consistent progress without disrupting existing workflows.

Qiskit v2.5 continues that trajectory while also pushing toward programmable performance: giving you more control over how your quantum programs are compiled, optimized, and executed. To that end, the latest release introduces new abstractions for building custom compiler pipelines, expanded C API capabilities, and sizable speedups across the transpiler.

These updates reflect a broader shift in how Qiskit is evolving. Alongside under-the-hood improvements that “just work,” v2.5 also introduces tools and capabilities that make the SDK a more flexible, high-performance platform—one you can configure, extend, and tailor to your needs.

Read on to learn more about the changes introduced in Qiskit v2.5, and be sure to check the release notes for any details not covered in this blog post.

The TL;DR

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

• Classical control flow in the C API. You can now inspect classical control flow instructions used in dynamic circuits directly from C. This fills one of the biggest remaining gaps between the C API and Python for Qiskit's core data model.
• Multi-representation compiler framework. New abstractions let you build compilation pipelines that move between different intermediate representations (IR)—an important capability for domain-specific workflows, complex FTQC (fault-tolerant quantum computing) compiler flows, and more.
• Dedicated fault-tolerant pipelines. New preset pass managers simplify compilation to PBC and Clifford+T representations, both of which are important for FTQC.
• Faster transpilation. Algorithmic improvements in LightSabre, software optimizations, more multithreading, and new fidelity-focused passes all combine to make compilation meaningfully faster in v2.5.
• Qiskit v1.x series end of life. As a reminder, the release of Qiskit SDK v1.4.6 on 12 June marked end of life for the Qiskit v1.x series. Releases in the v1.x series will no longer receive any support—including bug fixes, security updates, or other patches. Users should upgrade to the v2.x series to continue receiving updates and support. Check the Qiskit v2.0 migration guide for more details.

Before we dive into the new features and improvements, we’d first like to highlight an important naming update. While not directly related to the Qiskit v2.5 release, the change helps clarify the distinction between the open-source Qiskit SDK and IBM’s quantum computing service.

Announcement: Qiskit Runtime Service is now IBM Quantum Compute Service

Qiskit Runtime Service is now called IBM Quantum Compute Service. This change serves to establish a clearer distinction between:

• Qiskit — an open-source, hardware-agnostic software development kit for building quantum algorithms and applications
• IBM Quantum Compute Service — a managed cloud service for executing quantum algorithms and applications on IBM quantum computers

The message is simple: Build with Qiskit. Run with IBM Quantum Compute.

This update will be rolled out gradually starting today and continuing over the coming weeks. You may continue to see the previous name in some places until the transition is complete.

Please note that this is a naming update only. There will be no changes to APIs, workflows, or the tools you use to run quantum workloads today. Existing programs and integrations will continue to work exactly as before.

Top new features & improvements

Now let’s dive into the most important new features and enhancements included in the v2.5 release. As always, if you want to know more about these or other updates that didn’t make it into this release summary article, you can see the full release notes in our documentation.

Classical control flow in the C API

Qiskit SDK v2.5 enables full inspection of dynamic-circuit control flow from the C API. This means that if you're using Qiskit's C API, especially in the hybrid Python–C mode we described in the v2.4 release, you can now inspect classical control-flow instructions directly from C, without dropping back into Python.

Qiskit v2.5 adds support for inspecting the same control-flow operations available through Qiskit’s ControlFlowOp hierarchy, including if/else, while, for, switch, box, break, and continue instructions. You can query control-flow types, inspect nested circuit blocks, examine conditions and loop parameters, and access the mappings between nested blocks and the corresponding parent circuit.

For full details, check the new control flow page in our documentation.

This release also introduces a new companion API for inspecting classical expressions in dynamic circuits. You can traverse expression trees, inspect variables and literal values, analyze logical, arithmetic, and comparison operations, and retrieve type information for the expressions that define control-flow conditions and timing-related constructs. This provides inspection support for everything in Python’s qiskit.circuit.classical module, including classical expressions, variables, types, and timing-related stretch expressions.

See the new classical expressions page in our documentation for additional details.

Together, these additions enable full inspection of dynamic circuits from C, making it possible for compiler backends and other low-level tooling to analyze circuits involving control flow and classical expressions entirely from the C API. Construction of control-flow operations and classical expressions from C is not yet supported, but inspection is an important step towards that goal.

Multi-representation compiler framework

Qiskit v2.5 introduces the new MultiStagePassManager, a framework for building compiler pipelines that operate across multiple intermediate representations (IR). Rather than requiring an entire workflow to use a single representation, MultiStagePassManager lets you express each stage of compilation in the representation best suited to the task at hand.

This flexibility is particularly valuable for advanced compilation workflows. For example, a domain-specific compiler might begin with a high-level representation that enables specialized optimizations before lowering to a DAGCircuit and continuing through Qiskit’s existing transpiler pipeline. Similarly, FTQC workflows might involve several representations, moving from a high-level program through one or more intermediate optimization stages before generating a final output representation.

This feature is primarily aimed at advanced users, such as researchers and developers building custom compiler workflows. However, it is designed to integrate seamlessly with Qiskit's existing pass manager, allowing for incremental adoption without rewriting existing pipelines. Keep in mind that users are responsible for defining the transitions between stages in MultiStagePassManager; transitions are not inferred automatically.

The following example shows a domain-specific workflow built with the Qiskit Fermions package. The pipeline begins with a fermionic program, passes though an intermediate fermionic representation, and then lowers to Qiskit’s standard DAGCircuit representation before continuing through Qiskit’s transpiler infrastructure. All of this is tied together in a single pass manager that remains compatible with Qiskit’s existing preset pass managers, making it easy to plug in generate_preset_pass_manager as another stage in the pipeline.

from qiskit.passmanager import MultiStagePassManager
from qiskit.transpiler import generate_preset_pass_manager
from qiskit_ibm_runtime.fake_provider import FakeOsaka

# Qiskit Fermions is a package for working with fermionic systems and 
# uses a specialized intermediate representation (IR) 
from qiskit_fermions.circuit import FermionicCircuit
from qiskit_fermions.circuit.library import Evolution, InitializeModes, OrbitalRotation
from qiskit_fermions.mappers.library import jordan_wigner
from qiskit_fermions.transpiler.converters import FermionicCircuitToDAG
from qiskit_fermions.transpiler.passes import (
    F2QSynthesis,
    TrivialF2QLayout,
)


# Specify the fermion to qubit synthesis, here using the Jordan-Wigner transformation.
# The F2QSynthesis is a lowering pass and implements a Task[FermionicDAGCircuit, DAGCircuit].
config = {
    "Evolution": ("MapperFn", (jordan_wigner,)),
    "InitializeModes": "TrivialOccupation",
    "OrbitalRotation": "GivensDecomposition",
}
synth = F2QSynthesis(config)

# Define the multi-staged pass manager going through multiple IRs
pass_manager = MultiStagePassManager(
    # input conversion: FermionicCircuit -> FermionicDAGCircuit
    fermionic_input=FermionicCircuitToDAG(),
    # layout: FermionicDAGCircuit -> FermionicDAGCircuit
    fermionic_layout=TrivialF2QLayout(),
    # synthesis from fermions to qubits: FermionicDAGCircuit -> DAGCircuit
    fermionic_to_qubit=synth,
    # qubit optimization: DAGCircuit -> DAGCircuit
    # note how we can plug in Qiskit's existing pass managers here
    dag_optimization=generate_preset_pass_manager(
        backend=FakeOsaka(), optimization_level=3
    ),
)

# build the program in domain-specific representation...
fermionic_circuit = build_fermionic_program()
print(type(fermionic_circuit))
print(fermionic_circuit.draw())

# ... and run the pass manager
dag = pass_manager.run(fermionic_circuit)

If you would like to run the full program, locally install Qiskit Fermions and complete the function:

import numpy as np
from qiskit_fermions.operators import FermionOperator
# ... plus existing imports of the snippet above

def build_fermionic_program() -> FermionicCircuit:
    """A program in domain-specific representation."""
    hamil = FermionOperator.from_dict(
        {
            ((True, 0), (False, 2)): 2.0,
            ((True, 2), (False, 0)): 2.0,
            ((True, 1), (False, 3)): -2.0,
            ((True, 3), (False, 1)): -2.0,
        }
    )
    time = 1.5
    num_modes = 4
    evo = Evolution(num_modes, hamil, time=time)

    init = InitializeModes([True, False, True, False])

    rot_mat = np.zeros((num_modes, num_modes), dtype=complex)
    rot_mat[0, 1] = 1
    rot_mat[1, 0] = 1
    rot_mat[2, 3] = 1
    rot_mat[3, 2] = 1
    orb_rot = OrbitalRotation(rot_mat)

    circ = FermionicCircuit(num_modes)
    circ.append(init, circ.modes)
    circ.append(orb_rot, circ.modes)
    circ.append(evo, circ.modes)

    return circ

Dedicated fault-tolerant compilation pipelines

Qiskit v2.5 introduces two new preset pass managers for emerging fault-tolerant compilation workflows. These include:

• generate_preset_pbc_pass_manager() for compiling circuits into Pauli-based computation (PBC) representations
• generate_preset_clifford_t_pass_manager() for compiling circuits to Clifford+T gate sets

Pauli-based computation is a circuit representation where computation is expressed through Pauli measurements and Pauli rotations, making it a useful IR for some fault-tolerant compilation workflows. Clifford+T representations express circuits using Clifford operations and T gates, a gate set that has long served as a common baseline in FTQC because of its compatibility with many proposed error-correction architectures.

The representation you choose will depend largely on your target fault-tolerant architecture and compilation workflow. Clifford+T has long served as a common baseline for fault-tolerant compilation, while Pauli-based computation is increasingly emerging as an important alternative representation. Interest in both approaches continues to grow as quantum technology progresses toward fault-tolerance.

With these new ready-to-use pipelines, it’s now much easier to experiment with fault-tolerant compilation targets without needing to build and maintain custom compilation pipelines on your own. The new pass managers are also fully customizable. Developers can inspect, modify, and extend individual compilation stages, making it easy to experiment with new optimization techniques.

To see what this looks like in practice, let’s start with the default PBC pipeline. In the following example, generate_preset_pbc_pass_manager compiles a quantum phase-estimation circuit into a PBC representation built from Pauli measurements and Pauli product rotations:

from qiskit.circuit.library import phase_estimation, PauliEvolutionGate
from qiskit.quantum_info import SparseObservable
from qiskit.transpiler import generate_preset_pbc_pass_manager

# build a Quantum Phase Estimation based on Trotterization
num_qubits = 10
hamiltonian = SparseObservable.from_sparse_list(
    [("ZZ", [i, i + 1], 0.5) for i in range(num_qubits - 1)]
    + [("X", [i], 1) for i in range(num_qubits)],
    num_qubits=num_qubits,
)
hamiltonian_simulation = PauliEvolutionGate(hamiltonian, time=0.5)

m = 10
qpe = phase_estimation(m, hamiltonian_simulation)
print(qpe.count_ops())

# use the preset PBC pass manager to compile to 
# Pauli measurements and Pauli rotations
pbc_pm = generate_preset_pbc_pass_manager()
pbc = pbc_pm.run(qpe)
print(pbc.count_ops())
# prints: OrderedDict({'pauli_product_rotation': 1354})

Like Qiskit’s other preset pass managers, the PBC pipeline exposes its compilation stages so you can customize it to integrate additional optimization strategies. For example, we can append a LitinskiTransformation pass to the PBC optimization stage:

from qiskit.transpiler.passes import LitinskiTransformation

print("PBC stages:", pbc_pm.stages)
pbc_pm.pbc_optimization.append(LitinskiTransformation(fix_clifford=False))
pbc = pbc_pm.run(qpe)
print(pbc.count_ops())
# prints:
# PBC stages: ('unrolling', 'optimization', 'pbc_translation', 'pbc_optimization')
# OrderedDict({'pauli_product_rotation': 443})

The new generate_preset_clifford_t_pass_manager, on the other hand, targets Clifford+T instruction sets. You can use the pass manager with its default settings or configure it to trade off approximation accuracy against T-count through the rz_synthesis_config options shown in the next example:

from qiskit.transpiler import generate_preset_clifford_t_pass_manager

cliff_t_pm = generate_preset_clifford_t_pass_manager()
cliff_t = cliff_t_pm.run(qpe)
print(cliff_t.count_ops())
# prints: OrderedDict({'h': 38590, 't': 29718, 'tdg': 28182, ...})

# set the RZ synthesis accuracy to a lower level, which results
# in less T gates but a larger approximation error
cliff_t_pm = generate_preset_clifford_t_pass_manager(
    rz_synthesis_config={"rz_synthesis_error": 1e-5, "rz_cache_error": 1e-10}
)
cliff_t = cliff_t_pm.run(qpe)
print(cliff_t.count_ops())
# prints: OrderedDict({'h': 16603, 't': 13089, 'tdg': 11303, ...})

The new Clifford+T compilation pipeline also delivers substantial performance improvements. Across benchmark circuits drawn from FTCircuitBench and additional internal workloads, Qiskit v2.5 consistently reduces compilation runtime relative to v2.4, with some workloads compiling in roughly half the time, as shown below:

Transpiler performance improvements

Compilation performance in v2.5 achieves substantial gains over v2.4, thanks to improvements across multiple layers of the transpiler stack. These include algorithmic enhancements to LightSabre, expanded multithreading, and a new fidelity-focused optimization pass.

Some of the most significant updates come from the LightSabre routing algorithm. Routing heuristics now track “upcoming” gates as a series of stratified layers rather than using a fixed-size lookahead window. This removes bias in wide circuits, where a fixed number of gates may not represent a complete layer, while also avoiding unnecessarily deep lookahead in narrower circuits.

In addition to improving the quality of routing decisions, this change enables a more efficient implementation that updates lookahead layers in place during routing instead of repeatedly scanning the circuit. Together, these improvements provide better scaling on circuits with large qubit counts. LightSabre improvements have also resulted in substantial speedups for end-to-end compilation, with internal benchmarks showing major performance gains over previous transpiler implementations while maintaining comparable or improved circuit quality.

These improvements translate directly into faster transpilation on real workloads. The benchmark shown here compares Qiskit v2.5 against Qiskit v2.4.2 across a large collection of circuits. Points above the diagonal indicate cases where Qiskit v2.5 completed transpilation faster than the previous release.

Transpilation runtime comparison between Qiskit v2.5 and Qiskit v2.4.2 across a representative benchmark suite. Most workloads show faster compilation in v2.5 while maintaining comparable circuit quality.

Qiskit v2.5 also delivers expanded use of multithreading throughout the transpiler. More passes can now execute in parallel, improving performance for both large circuits and batch workloads. The new TwoQubitPeepholeOptimization pass is multithreaded from the start, while Optimize1qGatesDecomposition now supports multithreaded execution as well. Existing passes such as ConsolidateBlocks and UnitarySynthesis have also gained substantial multithreading support.

TwoQubitPeepholeOptimization is a new fidelity-focused optimization pass that replaces the previous two-qubit optimization workflow for optimization levels 2 and 3. Compared with the ConsolidateBlocks and UnitarySynthesis approach, the new pass is more amenable to multithreading, avoids duplication of work in some cases, and makes more effective use of hardware fidelity estimates when selecting resynthesis strategies. It’s also more reliable when multiple synthesis options are available, including cases involving fractional two-qubit gates such as RZZGate or linked qubits that support operations in either direction.

Crucially, TwoQubitPeepholeOptimization is designed to optimize for expected execution fidelity on real hardware rather than focusing solely on gate count or circuit depth. By incorporating backend error rates and device characteristics into its optimization decisions, the pass can make more informed tradeoffs that better reflect real-world device performance. Note that this may sometimes increase circuit depth or gate count if the error model predicts that doing so will improve overall execution fidelity.

Upgrade considerations

For most users, we expect that upgrading to Qiskit v2.5 should not require code changes. However, the following points may be relevant depending on how you use the SDK.

C API binary compatibility

Qiskit’s C API continues to evolve and should be considered unstable across minor releases. As a result, we cannot guarantee binary compatibility between Qiskit v2.5 and any previous or future releases.

In practical terms, this means that extensions compiled against Qiskit v2.4 may need to be rebuilt before they can be used with Qiskit v2.5. We plan to introduce explicit stability guarantees for the C API in a future release.

Updated dependency requirements

As of the v2.5 release, Qiskit now requires NumPy 2.0 or later and SciPy 1.14 or later. Users with environments pinned to older versions of either dependency may need to update those packages before upgrading to Qiskit v2.5.

This update aligns with Qiskit’s new dependency-version support policy, which is based on the scientific Python community’s SPEC 0 guidelines. The new policy defines how long older dependency versions remain supported and helps ensure that Qiskit can continue taking advantage of improvements across the scientific Python ecosystem.

Clifford+T compilation workflows

If you compile circuits to Clifford+T instruction sets, consider using the new generate_clifford_t_pass_manager() instead of transpile() or generate_preset_pass_manager().

The new pipeline is specifically designed for Clifford+T compilations workflows and provides a more configurable foundation for fault-tolerant compilation targets.

Final notes

Those are the highlights for Qiskit SDK v2.5. Open a GitHub issue to request features or report bugs, and check the Qiskit Roadmap to see what's coming next.

Special thanks to many developers that contributed to this release (in alphabetical order):

Aarush, Abdón Rodríguez, Abigail J. Cross, Alexander Ivrii, Alexander Miessen, 
amruthpremjith, Andrew Eddins, Antonio D. Córcoles-Gonzales, Archit Chadalawada,
Bruno Caballero, Conrad Haupt, Cosmin Dinu-Thiery, CowBeez, Debasmita Bhoumik,
Ebrahim Eldesoky, Eli Arbel, Eric Arellano, Gadi Aleksandrowicz, Gloria Amos,
Greg Neighbors, Hank Greenburg, Ian Hincks, Jake Lishman, Janani Ananthanarayanan,
Jeevan Kumar, Joshua Skanes-Norman, Julien Gacon, kataro92, Kevin J. Sung, Lojy Elkady,
Luciano Bello, Matthew Treinish, Max Rossmannek, Naman Garg, Parth Danve, Pramod Anandarao, RajeshKumar11, Rajnish Tiwari, Raynel Sanchez, Ross Peili, Shelly Garion, 
Sonai Biswas, Sorin Bolos, and Tilock Sadhukhan