What a quantum operating system actually does

“Quantum operating system” gets used for everything from a pulse sequencer to a cloud job queue. I work on the layers between the compiler and the quantum OS / runtime, so here is how I think about that layer, and what recent research and industry systems say it should do. This is a general survey. It doesn’t describe the internals of any employer’s stack.

Where the OS sits

A useful way to place it is by what each layer knows about the hardware:

The compiler needs a snapshot of the device. The control stack needs exact timing. The OS is the part that owns the changing state in between: which devices exist, how good each qubit is right now, who is waiting, and what should run next. A classical OS manages scarce, shared hardware; a quantum OS does the same for hardware that drifts by the hour and can’t be paused mid-computation.

1. A device model that includes calibration

Every scheduling or compilation decision depends on a model of the device: qubit count, native gates and connectivity (static), plus T₁ / T₂, gate and readout fidelities, and frequencies (dynamic). On real hardware the dynamic half matters most, because it drifts.

The Munich Quantum Software Stack makes this explicit with QDMI, the Quantum Device Management Interface: an open interface that lets software query both static properties and live calibration data and error rates, so the compiler can make hardware-aware decisions, alongside session management and job submission for multiple users and devices. That split, a stable interface over hardware that keeps changing, is the core abstraction a quantum OS needs if it is going to drive more than one kind of hardware.

In practice this means calibration results are not log files; they are versioned system state. A job should be compiled against a known calibration snapshot, and you should be able to say afterwards which snapshot it ran on.

2. Calibration is a workload the OS has to schedule

Calibration doesn’t happen once. Qubit frequencies, readout discrimination and gate parameters drift, so routines such as spectroscopy, Rabi, Ramsey, readout and gate tuning re-run continuously. Tools like Quantum Machines’ QUAlibrate and Qibo’s Qibocal organise these routines into automated, dependency-ordered workflows rather than one-off notebooks.

From the OS’s point of view, that creates a scheduling problem with two kinds of jobs competing for the same QPU: user workloads that want throughput, and calibration runs that keep the device worth using. Too little calibration and every user result degrades; too much and nobody gets machine time. Making that trade-off explicit, and deciding which qubits need recalibration rather than recalibrating everything, is one of the most practical things a quantum OS can do. It’s also where automation, including AI agents that decide what to measure next, is starting to appear.

3. Scheduling, multi-programming and the fidelity–throughput trade-off

Quantum cloud users routinely wait far longer in the queue than their circuits take to run, while large devices sit partly idle running small circuits. The obvious fix is multi-programming: run several programs on disjoint qubits of the same QPU at once. The catch is crosstalk, which can quietly destroy fidelity.

Recent systems research has quantified this well:

• QOS (Giortamis et al., OSDI 2025) is a modular quantum OS with four components behind a hardware-agnostic API: an error mitigator, an estimator, a multi-programmer and a scheduler. Evaluated with over 7,000 real runs on IBM devices, it reports 2.6–456.5× higher fidelity, up to 9.6× higher utilisation and up to 5× shorter waiting times, at an average fidelity cost of about 1–3% from co-execution. Its multi-programmer scores circuit compatibility and leaves buffer qubits between programs to limit crosstalk, and it can fall back to single-program mode when reliability drops.
• Qonductor (same group, SC’25) applies the idea to hybrid quantum-classical workflows across a fleet of QPUs, reporting up to 54% lower job completion times for a 3% loss in execution quality and up to 66% higher utilisation.
• HALO (Ye et al., 2026) pushes to fine-grained qubit sharing with a hardware-aware qubit-sharing algorithm and a shot-adaptive scheduler, reporting up to 2.44× higher utilisation and 4.44× higher throughput than HyperQ, while keeping fidelity loss within 33%.

The common lesson: utilisation and fidelity trade against each other, and a good OS measures that trade-off at runtime instead of fixing it at design time.

4. Execution modes for hybrid algorithms

Most useful near-term workloads are loops: a classical optimiser proposes parameters, the QPU estimates something, repeat. If each iteration goes back through a public queue, the algorithm spends most of its life waiting.

Qiskit Runtime’s execution modes are a clean example of the OS-level answer. Its two primitives, Sampler and Estimator, run in three modes: a single job; a batch of independent jobs, whose classical pre-processing is parallelised so quantum execution is packed tightly; or a session, which reserves the device for an iterative workload that adapts to intermediate results. Dynamic circuits push the same idea further down: mid-circuit measurement and conditional feed-forward need classical decisions inside the coherence time, which means the runtime has to hand those parts to the real-time control stack instead of handling them itself.

5. The QPU as an HPC accelerator

The biggest shift of the last two years is that quantum OS work increasingly looks like HPC integration.

• QRMI, the Quantum Resource Management Interface, is vendor-agnostic middleware that exposes QPUs as schedulable resources to HPC workload managers. Pasqal has integrated it with NVIDIA CUDA-Q so QPUs appear as Slurm-native accelerators next to CPUs and GPUs, and a consortium including IBM Quantum, Pasqal, Alice & Bob, CINECA, LLNL, ORNL and the STFC Hartree Centre has extended QPU co-scheduling to Slurm, PBS Professional, IBM Spectrum LSF, Open Cluster Scheduler, Kubernetes and Flux.
• On the compiler side, the toolchains feeding these systems have converged on MLIR and LLVM: CUDA-Q lowers kernels through an MLIR-based representation to QIR, the LLVM-based quantum intermediate representation.
• At the low-latency end, NVIDIA’s NVQLink couples GPUs to QPU controllers with round-trip latency under 4 µs, aimed at real-time decoding for error correction. Riverlane, which started with an OS called Deltaflow.OS, now focuses on real-time error correction; it installed its Deltaflow 2 system at Oak Ridge National Laboratory in 2025, connected to the Frontier supercomputer.

Put together: the quantum OS is no longer a standalone box. It is a resource manager that has to cooperate with the site’s existing scheduler above it and with real-time error-correction hardware below it.

6. How to benchmark the OS itself

Device benchmarks such as RB, XEB and Quantum Volume tell you about the qubits. They don’t tell you whether the OS around them is any good. The metrics I find useful for the OS layer are:

• Delivered fidelity: result quality as users see it, after scheduling, co-execution and mitigation, not the best-case device number.
• Effective utilisation: the fraction of qubit-time doing useful work, counting calibration separately from user jobs.
• Waiting and completion time: queue time and end-to-end job completion, not just circuit runtime.
• Compilation latency: how long the compiler and OS take per job, which starts to dominate for short, iterative circuits.
• Calibration freshness: how old the calibration data was when each job ran, and how much results degraded as it aged.

The QOS, Qonductor and HALO papers all report results in terms like these, which is what makes them comparable. For anyone building a stack, publishing the same set is the honest way to show progress.

What’s still open

• A shared device model across vendors. QDMI and QRMI are steps toward common interfaces, but calibration data still comes in a different shape from every platform.
• Calibration-aware scheduling. Choosing when and what to recalibrate based on the jobs waiting, instead of on a timer, is still mostly done by hand.
• Automation of operations. Automated calibration graphs, and AI agents that can plan and interpret measurements, are moving the routine operation of a QPU from people to software. The open question is how to make those decisions auditable.
• Isolation in multi-tenant systems. Sharing one chip between users raises crosstalk and security questions that classical OS isolation never had to solve.

The pattern across all of this is that the quantum OS is where physics and systems engineering meet: the device model is physics, the scheduler is systems, and the numbers users trust depend on both.

References

• E. Giortamis, F. Romão, N. Tornow, P. Bhatotia. QOS: A Quantum Operating System. OSDI 2025 (arXiv:2406.19120).
• E. Giortamis et al. Qonductor: A Cloud Orchestrator for Quantum Computing. SC’25.
• J. Z. Ye, J. Wang, Y. Qiao, J. Palsberg. HALO: A Fine-Grained Resource Sharing Quantum Operating System. arXiv, 2026.
• The Munich Quantum Software Stack and QDMI on GitHub.
• Examining QRMI as a Unified Interface for Quantum-HPC Integration, and the QRMI consortium expansion.
• IBM Quantum: Execution modes for efficient, utility-scale workloads.
• NVIDIA: CUDA-Q and the NVQLink announcement.
• Riverlane: Deltaflow.