Qiskit 2.6 lets C programs write compiler passes and save circuits

IBM has released Qiskit SDK v2.6, a version that is mostly about the C API: programs in C and other compiled languages can now write their own compiler passes, save circuits in the QPY format and define custom gates, according to the official release summary.

Three new C API building blocks

IBM calls v2.6 “a C API release” above all. Earlier versions let C users build circuits and run Qiskit’s preset transpiler. Version 2.6 adds three pieces that give them control over the compiler itself.

The first is a pass-manager framework. A QkPassManager runs QkPass objects added with qk_passmanager_push_pass, and each pass is described by a vtable (QkPassVtable). Every pass declares the intermediate representation (IR) it reads and the one it produces, through a QkIrHandle. That can be a built-in Qiskit IR, currently QkCircuit or QkDag, or an IR the developer defines. Because the declarations are known, the pass manager can check that a multi-stage pipeline fits together before running it. Errors are reported through QkCompilationError.

The second is QPY serialization. QPY is Qiskit’s binary format for storing circuits. Several QkCircuit objects can now be written to one stream, in memory with qk_qpy_dump_buffer or to disk with qk_qpy_dump_file, and read back with qk_qpy_load_file or qk_qpy_load_buffer. IBM says the output is compatible with Python’s qiskit.qpy, so a file written from C loads in Python and the reverse. Variants ending in _with_version pin an older format version. Code running inside a Python extension should keep using the Python functions, because the C versions return an error when Python is needed.

The third is custom operations. A QkCustomOp is defined by a vtable of function slots, and only two are required: the name and the qubit count. Optional slots cover the gate’s definition, equality, cloning and deletion. A finished operation goes into a circuit with qk_circuit_custom_operation or into a DAG with qk_dag_apply_custom_operation. IBM presents this as a way to add hardware-native gates without the Python object model.

What changes for upgraders

IBM expects most users to upgrade without code changes. QPY format v18 is now the default in qiskit.qpy.dump(). Files written by 2.6 may not load in older Qiskit releases, so anyone who shares files with older installations should request an earlier version through the version argument. IBM says v18 is mostly internal cleanup plus a more compact register encoding, which matters mainly for circuits with very large registers or many classical registers.

Python 3.10 remains supported, but IBM says this is the last release to do so; Qiskit 2.7 will require Python 3.11 or newer. Building from source now needs Rust 1.89, while users of pre-built wheels are unaffected. IBM also says the C API is not yet declared stable, though it reports no breaking C API changes between 2.5 and 2.6.

Why Python is still hard to remove

The release also continues a quieter job: running the standalone C library on machines without Python installed. IBM says the library never starts a Python interpreter, yet it still needs Python present, because Qiskit’s Rust data model is partly defined in terms of Python types and the linker wants those symbols.

That problem is public and old. The tracking issue on GitHub (#14240) was opened by a Qiskit maintainer in April 2025 and, per its current page, is still open and assigned to the 2.7.0 milestone. It proposes moving the remaining Python-dependent parts of the circuit data model into plain Rust and compiling the Python types only when needed. A sub-issue to remove the PyO3 dependency from the qiskit-circuit crate was added in August 2026. IBM says it hopes to finish the job in v2.7, which fits that milestone but is a goal, not a commitment.

The pace of the C API work is visible in the release notes. On GitHub, Qiskit 2.6.0 is dated 16 October, and its notes list around ten additions touching the C API, including the pass manager, QPY and custom operations. Version 2.5.0, released on 2 July, added C API support for inspecting control flow and classical expressions, along with two-qubit peephole optimization. In other words, each release since 2.5 has widened what compiled code can do on its own, and 2.6 is the one where users can extend the compiler instead of only calling it.

The practical gain is clearest for high-performance computing sites. A C or Fortran program, or a Julia one through its C interface, can now compile a circuit, save it and reload it in a later run without starting Python. IBM adds that QPY in the C API should make its qiskit-ibm-runtime-c client easier to maintain, and let others write their own client layers for submitting jobs to IBM Quantum Platform.

What the announcement leaves open

The summary is a vendor description of its own release, and the performance claims in its framing, such as making Qiskit “the world’s most performant quantum SDK”, come with no benchmarks. The post gives no numbers on file-size savings from QPY v18 or on the speed of custom passes written in C. IBM does not say when the C API will be declared stable, which matters for anyone building long-lived tools on the vtable interfaces. The Python-free build is not finished either: on the current release, a standalone C program still needs Python installed.

For now, the release is aimed at developers of compilers, HPC integrations and language bindings, not at people writing circuits in Python. IBM says the SDK is open source, and it points feature requests to GitHub issues and its public roadmap.