The Quantum OS and Orchestration Layer: Assembling the Software That Runs the Machine

Introduction

The previous article in this series covered the control system, the electronics that physically drive the qubits. This article covers the layer above it: the software that turns a rack of multi-vendor hardware into something a user can submit a job to.

Here is the uncomfortable fact a buyer needs to absorb before reading further. There is no quantum operating system. Not in the sense the word carries in classical computing. There is no downloadable software layer that takes a QuantWare QPU, a Qblox controller, a Bluefors cryostat, and a Riverlane decoder and orchestrates them into a functioning, multi-user machine. No Linux kernel equivalent that lets you swap a hardware vendor without rewriting the stack above it.

This matters for a build because every other article in this series describes a component you can purchase. A cryostat is a purchase. A QPU is a purchase. A control system is a purchase. The orchestration software that ties them together is, for a Western integrator in 2026, not a purchase. It is an assembly job. A buyer who has budgeted for hardware and assumed the software “comes with it” has a gap in the plan, and this article is about closing that gap: what the software layer has to do, what exists to do it, and the build-or-buy decision that has no default answer yet.

The five layers, and which ones a buyer has to think about

The playbook describes the quantum software stack as five functional layers, and an integrator has to assemble a coherent path through all of them.

Layer 1 is pulse and firmware: direct waveform programming, the QUA, Q1ASM, and LabOne Q languages tied to specific control hardware. Layer 2 is calibration: the automated routines that tune the system and fight drift. Layer 3 is the framework: Qiskit, Cirq, CUDA-Q, the high-level environments where circuits are written. Layer 4 is middleware and orchestration: job scheduling, queue management, multi-user quotas, authentication. Layer 5 is the operating system: the unified layer that would, if it existed in mature form, sit over everything else.

Layers 1 and 3 are mostly settled by hardware and framework choices a buyer has already made. Pick a control system and Layer 1 largely follows. Pick Qiskit or CUDA-Q and Layer 3 is decided. The layers that demand active procurement attention, and the ones this article concentrates on, are 2, 4, and 5: calibration, orchestration, and the question of whether anything resembling an operating system sits on top.

The table makes the shape of the problem visible. Two layers come along for free with decisions already made. Three require a deliberate choice, and two of those three have no product a buyer can simply purchase.

What the orchestration layer actually has to do

Strip away the “operating system” label and the orchestration layer has a concrete job description. It manages qubit allocation, deciding which physical qubits a given job runs on. It schedules jobs and manages a queue when more than one user wants the machine. It enforces per-tenant quotas and authentication. It coordinates the hybrid lifecycle where a quantum circuit and a classical computation hand work back and forth. And it does all of this while the hardware underneath it drifts on hourly timescales, which means the orchestration layer is never managing a static machine.

That last point is what makes a quantum orchestration layer different from a classical job scheduler, and it is worth being precise about what the difference looks like in practice. A classical scheduler allocates stable resources. A quantum orchestration layer allocates resources whose error rates change between calibrations, whose best qubits today are not the best qubits tomorrow, and whose jobs cannot be paused and resumed because a half-finished quantum state decoheres the moment the schedule slips. Consider a concrete scenario: a user submits a 50-circuit job at 9 AM. The system was calibrated at 7 AM. Qubits 3 and 7 were the highest-fidelity pair at calibration time. By 10 AM, frequency drift has degraded qubit 7’s T1 by 15 percent, and a TLS defect has shifted qubit 3’s frequency by 200 kHz. Does the scheduler check calibration timestamps before assigning qubits to the remaining circuits? Does it reject the job and trigger a recalibration? Does it silently route the remaining circuits to a different qubit pair? These are design decisions that someone building the orchestration layer has to answer, and they have no classical analogue. A Slurm partition for GPUs does not check whether the GPU has drifted since the last firmware update.

The deeper engineering of this, the NP-hard qubit-mapping problem and the scheduling theory it forces, is the subject of the OS deep dive; for a build guide the point is simpler. The software that schedules your machine has to understand the physics of your machine, and that is why a generic HPC scheduler does not drop in unmodified.

The calibration layer: not optional, and a real procurement choice

Calibration is the one software layer a buyer cannot defer or improvise, because without it the machine does not stay working. Qubits drift. Gate parameters that were correct this morning are wrong this afternoon. A two-qubit gate calibrated to 99.5% fidelity at 8 AM can degrade to 98% by noon if a TLS defect shifts a qubit frequency or if thermal cycling changes the flux bias point. The superconducting build guide covers the bring-up sequence; the calibration software is what keeps that bring-up valid over the months that follow. The IQM team at LRZ published 250 days of operational telemetry in arXiv:2509.12949, and their data makes the operational case concretely: a quick recalibration cycle takes roughly 40 minutes, a full recalibration roughly 100 minutes, and once tuned, their system ran more than 100 days unattended between major interventions. That stability is not a property of the hardware alone. It is the product of autonomous calibration software catching drift before it compounds into errors that a user can see.

The playbook identifies three calibration platforms, and they map onto procurement decisions a buyer has already started making. Q-CTRL’s Boulder Opal Scale-Up is AI-driven autonomous calibration, the engine inside the Q-PAC reference deployment, integrated with QuantWare and with Keysight’s control system. QuantrolOx Quantum EDGE is a direct competitor; the playbook records it achieving fully automated CZ-gate tune-up in under 25 minutes against roughly a week of manual expert effort, and it is installed at the UK’s National Quantum Computing Centre. Quantum Machines’ QUAlibrate ships with the OPX control hardware and is tied to the QUA language.

The pattern worth noting: one of these three is partly a consequence of the control-system choice from the previous article, and one is not. QUAlibrate comes with Quantum Machines hardware. Boulder Opal and QuantrolOx are independent purchases that work across control vendors. A buyer should decide the calibration layer deliberately rather than defaulting to whatever shipped with the control rack, because autonomous calibration is the difference between a machine that needs a specialist babysitting it and one that recalibrates itself and reports drift.

Layer 5: the operating system that mostly does not exist in the West

This is where the honest answer is uncomfortable, and where the competitive picture matters.

A true quantum operating system would orchestrate qubit allocation, error correction, job scheduling, calibration, and security across heterogeneous hardware, and it would be portable and installable rather than locked to one vendor’s machine. By that standard, the West does not have one. IBM’s Qiskit Runtime handles scheduling and error mitigation, but only for IBM hardware. Riverlane’s Deltaflow handles real-time error correction, but it is a decoder, not a system orchestrator. Google, Microsoft, and Amazon each run sophisticated internal control stacks, and none of them are downloadable, portable, or open. The field sits in what the OS deep dive calls its mainframe era: vertically integrated, vendor-specific, pre-standardization.

There is exactly one publicly downloadable quantum operating system as of May 2026, and it is Chinese. Origin Quantum’s Origin Pilot V4.0, released for public download on 26 February 2026, supports superconducting, trapped-ion, and neutral-atom hardware, and provides unified driver management, resource scheduling, multi-user quotas, automatic calibration, and hybrid quantum-classical-AI orchestration. It is not open source in the OSI sense; it is a proprietary system made available for download. For a Western or allied buyer it is not a deployment option. Origin Quantum has been on the U.S. Entity List since May 2024, and the Chinese quantum ecosystem operates under export-control conditions that put its software stack out of reach for most regulated-sector customers regardless of technical merit.

The strategic point is the one I have made before in the China coverage and it bears repeating here. Origin Pilot is not primarily a product release; it is a positioning move in the integration layer. It lets China claim the most complete quantum operating system in existence while the West is still assembling middleware by hand. The specific engineering achievement worth studying is the unified driver model: Origin Pilot abstracts across superconducting, trapped-ion, and neutral-atom hardware through a single driver layer, so the orchestration stack above it does not change when the QPU modality does. No Western stack replicates that portability yet. A Western buyer should treat Origin Pilot as competitive intelligence and a benchmark for what an integrated OS looks like, not as something to install.

So what does a Western buyer actually do for Layer 5

If there is no turnkey Western quantum OS, the orchestration layer has to come from somewhere. There are three realistic paths, and a buyer should choose among them deliberately.

The first path is to roll your own. Most Western integrators today assemble the orchestration layer from Kubernetes and Slurm plus custom REST and gRPC APIs. This is the most flexible option and the most demanding in engineering effort. In practice it means building: a Slurm plugin or custom scheduler that knows about QPU availability and calibration state; a metadata store that tracks which qubits were last calibrated and at what fidelity; gRPC services that translate circuit submissions into control-system instructions; an authentication and tenant-isolation layer; monitoring dashboards that surface both classical infrastructure health and qubit performance metrics; and a job-lifecycle manager that handles the hybrid handoff between classical pre-processing, quantum execution, and classical post-processing. That is a genuine software engineering project: three to six months of development for a small team, with ongoing maintenance indefinitely. For a national laboratory with a strong in-house software group, this is often the right answer because it produces a stack the lab fully controls and can adapt to its own research workflows. For a first-time enterprise buyer, it is a larger commitment than it looks from the outside.

The second path is to build from a reference architecture. The Quantum Utility Block, the QuantWare, Q-CTRL, and Qblox joint reference design, includes an orchestration layer and gives a buyer a pre-validated blueprint rather than a blank sheet. The emerging QRMI standard, demonstrated by Pasqal with NVIDIA’s CUDA-Q in March 2026, provides a route to expose a QPU as a Slurm-native schedulable resource, which narrows the custom-integration work. This path trades some flexibility for a faster, lower-risk assembly.

The third path is to engage a systems integrator to deliver the orchestration layer as a turnkey component. The playbook names Applied Quantum, Orange Quantum Systems, ParTec, and TreQ as firms that do this. For a buyer whose core mission is running quantum workloads rather than maintaining quantum middleware, paying a specialist to assemble and support Layer 5 is often the rational choice, the same calculation that leads most organizations not to build their own database engine.

There is no default answer among the three. The decision turns on in-house engineering depth, on whether the deployment is a sovereign national program or a commercial installation, and on how much the buyer values control over the stack against speed of deployment. What a buyer should not do is assume the question answers itself, because it does not, and discovering that in month six of a build is expensive.

Where this connects to HPC integration

One boundary is worth drawing clearly, because the next article in this series covers it. The orchestration layer decides how jobs are scheduled and how the machine is shared. The HPC integration layer is the physical and architectural coupling between the quantum machine and classical supercomputing: NVQLink, the GPU interconnect, the RDMA fabric. The two are related but distinct purchases. QRMI sits on the seam: it is the abstraction that lets the orchestration layer present a QPU to a classical HPC scheduler as just another schedulable resource. At CINECA in Bologna, Pasqal’s 140-qubit neutral-atom QPU appears in the Slurm queue alongside Leonardo’s GPU partitions, and researchers submit hybrid jobs through the same interface they use for classical workloads. That is what the seam looks like when both layers are working. A buyer planning an HPC-coupled deployment should treat the orchestration layer and the HPC interconnect as two coordinated decisions, not one.

What a buyer should take away

The software that runs a quantum computer is the part of the build most likely to be underbudgeted, because it is the part that does not arrive in a crate.

Layers 1 and 3, pulse-level programming and the high-level framework, mostly follow from hardware and framework choices already made. Layer 2, calibration, is a genuine and non-deferrable procurement decision; choose Boulder Opal, QuantrolOx, or QUAlibrate deliberately rather than accepting whatever shipped with the control rack. Layers 4 and 5, orchestration and the operating system, are where the real gap sits. No turnkey Western quantum OS exists. The buyer chooses among rolling their own on Kubernetes and Slurm, building from the Quantum Utility Block reference architecture, or engaging a systems integrator, and that choice should be made explicitly and early, with the engineering effort costed honestly.

The one quantum operating system a buyer can download today is Origin Pilot, and for Western and allied customers it is a benchmark to study, not a product to deploy. The West will get an integrated quantum OS eventually. Until it does, the orchestration layer is an assembly job, and a build plan that does not account for that is a build plan with a hole in it.

For the full engineering treatment, including the hardware abstraction layer, the NP-hard qubit-mapping problem, compilation pipeline internals, decoder algorithms, and the calibration-drift physics, my deep dive on the quantum OS stack goes well past what a build guide needs.