USB With a Q - a Standard Interface for Quantum Computing
If you spend any time tracking the quantum hardware race, the conversations you hear tend to be dominated by the heroic metrics: physical qubit counts, two-qubit gate fidelities, coherence times, and roadmap timelines to fault-tolerant logical qubits. We obsess over the physics inside the dilution fridge or the vacuum chamber.
What we spend almost no time talking about is the plumbing.
Specifically: how does a classical computer actually talk to a quantum device?
Right now, if you are a quantum hardware startup building a trapped ion or neutral atom machine, every route to a user requires a bespoke engineering project. You build a custom integration with REST API for Amazon Braket's backend. You build another custom API for Azure Quantum. You write a provider plugin for Qiskit, another for Pennylane, and a third for an on-premise supercomputing center running Slurm. If an HPC center buys your device and parks it next to a classical cluster, their systems engineers have to write custom integration glue to schedule jobs, pass tokens, monitor status, and pull results.
Every single path from classical software to quantum hardware is currently a bilateral, hand-soldered connection.
We have seen this movie before in the history of classical computing. And we know exactly how it gets resolved.
The Peripheral Chaos of 1994
Before the mid-1990s, connecting a peripheral to a PC was an exercise in bespoke madness. If you wanted to attach a scanner, a joystick, a printer, and an external hard drive, you were juggling serial ports, parallel ports, PS/2 ports, SCSI cards with physical termination jumpers, and custom DIP switches to avoid IRQ conflicts.
Every device manufacturer had to write custom drivers that reached deep into the operating system, and every computer maker had to provide a dizzying array of physical pinouts on the motherboard.
Then came USB (Universal Serial Bus).
USB didn't succeed because it had the highest bandwidth or the lowest latency. It succeeded because it was a rigid, opinionated boundary contract.
USB established two permanent roles: a Host (the PC) and a Device (the peripheral). It defined a tiny, stable set of interaction primitives:
1. Discover: The Host asks the Device for its descriptors (what are you, what class of device are you, and what endpoints do you expose?).
2. Control & Bulk Transfer: The Host sends commands and streams data over standardized pipes.
3. Status: The Host polls or receives interrupts regarding state.
Crucially, USB refused to know what was in the payload. USB does not know what a JPEG is when you plug in a camera; it does not know what an audio stream is when you plug in a microphone; it does not know what text is when you plug in a keyboard. It simply provides a reliable, standardized envelope and an interaction state machine.
Quantum computing is currently in its pre-USB phase.
The Duct Tape Era
To see how urgent this has become, look at the recent work happening across the open-source quantum ecosystem.
Earlier this year, the Munich Quantum Software team released an open-source bridge called amazon-braket-qdmi-device. It connects QDMI (the C-based Quantum Device Management Interface developed in Munich) to Amazon Braket.
It's an impressive and clever piece of engineering: it allows a C/C++ compiler or an HPC runtime written against the QDMI C-ABI to execute circuits on AWS Braket without changing the application code.
Look closely at what is happening across that chain: - At the top, you have an HPC-centric C-library standard (QDMI). - In the middle, you translate those C-function calls into AWS C++ SDK calls over HTTPS. - To handle AWS authentication, credentials files have to be shoehorned into generic QDMI session parameters. - At the bottom, Amazon Braket uses private, bilateral, proprietary APIs to route tasks to physical hardware backends like IonQ or Rigetti.
It works, but it is architectural duct tape. It's a C-library wrapping a proprietary cloud SDK, which in turn wraps a proprietary hardware interface.
What the working group I've been collaborating with (spanning folks from qBraid, OQTOPUS Project, Oak Ridge, Waterloo, and elsewhere) has realized is that we don't need another proprietary wrapper. We need a universal Quantum Device Interface (QDI)—a standard that defines the "USB port" for quantum systems. I can hear some of you saying, "just what we need, another standard!" But we are trying to be mindful and avoid that n+1 trap by defining QDI as a wire protocol, not a library. It seeks to standardize and mediate the interactions between codebases, not supplant any one of them.
Where Does QDI Belong?
When you map the modern quantum infrastructure stack—from the dilution fridge at a national lab, up through cloud-based aggregators, down to user workstations and hybrid supercomputing schedulers—where does a standard interface actually belong?
There are three natural integration boundaries:
1. The Hardware Edge (The Primary "USB Port")
This is the most critical boundary. The hardware vendor exposes a QDI server at the boundary of their classical control electronics. The payoff: The hardware vendor writes their interface once. Whether that machine is accessed over the internet by a hyperscaler, connected via PCIe/network to an on-premise supercomputer, or driven by a diagnostic script in an R&D lab, the interaction model is identical.
2. The Cloud Aggregator (The "USB Hub")
Cloud services (Braket, Azure Quantum, qBraid) act as universal hubs. They consume QDI downstream from hardware vendors, and they can expose a QDI endpoint upstream to users. The payoff: It eliminates cloud SDK lock-in. A researcher writes a single task-dispatch script using standard QDI tools. They can point that script at AWS today, Azure tomorrow, or an on-premise cluster next week simply by changing a URL and an authentication token.
3. The HPC Resource Manager (The "Motherboard Bus")
In hybrid quantum-classical supercomputing (like the work happening at Oak Ridge, LRZ, and RIKEN), a classical workload manager like Slurm, PBS, or Flux orchestrates jobs across classical nodes and co-located QPUs. The payoff: Slurm doesn't need a custom plugin for an IQM superconducting processor and an entirely different plugin for a Pasqal neutral atom processor. The scheduler treats the QPU as a standardized accelerator over QDI.
The Five Verbs: Keeping the Interface Narrow
The cardinal rule of building durable interface standards is payload neutrality. Like HTTP and USB, the protocol must succeed by refusing to know things.
The proposed QDI specification does not know what OpenQASM 3 is. It does not know what QIR is. It does not understand pulse schedules, it does not manage error correction loops, and it does not dictate how your compiler optimizes circuits. Those are payloads, and payloads evolve.
Instead, QDI defines five core operations:
- Discover (Descriptor Request): The Host queries the Device. The Device responds with its unique identifier, whether it is currently operational (is_ready), the authentication schemes it accepts (supported_auth_methods), and the opaque task formats it can consume (supported_task_types).
- Authenticate (Handshake): The Host and Device establish trust using the method negotiated during Discover (OAuth2, mTLS, Kerberos, API tokens). QDI enforces the handshake without prescribing the underlying security mechanism.
- Send (Task Submission): The Host submits an opaque byte payload, declares the task type, specifies execution limits (shots or time), and optionally requests an estimate (dry-run) mode. The Device validates syntax and returns a task_id.
- Monitor (Status Polling/Streaming): The Host tracks task progression through a strictly enumerated state machine: QUEUED, EXECUTING, COMPLETED, FAULTED, or CANCELLED.
- Receive (Result Retrieval): The Host retrieves the output payload (counts, expectation values, syndrome traces) or receives a decoupled handle (like an S3 URI or shared memory buffer) to fetch large results.
Why This Matters Now
In Beginner's Mind, I wrote that we have effectively reset the clock of digital computing back to the late 1940s. We are still figuring out which qubit modalities will scale, what the architectures of fault-tolerant processors will look like, and how error correction will actually be implemented in real hardware.
When underlying technologies are changing this fast, the natural instinct is to build tightly coupled, monolithic stacks where one company controls the compiler, the cloud API, the control electronics, and the dilution fridge.
That approach works for early lab demonstrations, but it cannot scale an industry.
If we want the broader software world---the compiler engineers, the HPC system administrators, the cloud infrastructure architects, and the scientific domain specialists---to build real tools on top of quantum hardware, we have to lower the integration barrier. We have to stop expecting every vendor to invent their own wheel, and stop forcing every user to learn five different proprietary SDKs to run a two-qubit gate.
We need to give quantum computing its USB port. If you are curious or think you might want to pitch in, the spec and a small demo are on GitHub, check it out!
