Vendor-Agnostic Quantum Sandboxing: Benchmarking IBM, IonQ, Rigetti, and Braket from a Single Codebase

Quantum computing's software stack has a fragmentation problem that mirrors the early days of cloud computing, before Terraform and Kubernetes gave architects a common abstraction layer. Every quantum hardware vendor — IBM, IonQ, Rigetti, and the various QPU providers accessible through Amazon Braket — has historically demanded its own SDK, its own credential model, and its own circuit representation. For an architect trying to answer a simple question — "which backend gives us the best fidelity and cost profile for this workload?" — that fragmentation has meant maintaining parallel codebases, one per vendor, each with its own quirks.

Two tools now address this gap from different angles: qBraid Lab, a hosted, cross-vendor quantum development environment built on the qBraid-SDK, and Qiskit-Braket Provider v0.11, a focused bridge that lets Qiskit-authored circuits run natively on Amazon Braket's hardware fleet. Used together, they let technical teams write quantum circuits once and dispatch them, unmodified in logic, to IBM's superconducting processors, IonQ's trapped-ion systems, Rigetti's chips, and the broader roster of QPUs available through Braket — enabling genuine apples-to-apples benchmarking across the industry's leading hardware modalities.

Why Vendor Lock-In Is a Bigger Problem in Quantum Than in Classical Computing

In classical cloud infrastructure, containerization and orchestration standards emerged relatively quickly, giving architects a shared abstraction over compute regardless of underlying hardware. Quantum computing has lacked an equivalent for most of its commercial history.

Each hardware modality — superconducting qubits (IBM, Rigetti), trapped ions (IonQ), and neutral atoms (QuEra, Pasqal) — comes with different native gate sets, different qubit connectivity topologies, and different noise characteristics. Historically, exploiting any given backend's strengths meant writing circuits in that vendor's preferred SDK: Qiskit for IBM, a Braket-native SDK for AWS-hosted hardware, and so on.

That fragmentation has direct consequences for technical decision-making. Benchmarking hardware providers against each other — a routine exercise before committing budget to a quantum computing contract — has traditionally required either rewriting the same algorithm multiple times or accepting an apples-to-oranges comparison where implementation differences confound the actual hardware comparison. Vendor-agnostic sandboxing tools exist specifically to remove that confound.

qBraid Lab: A Cross-Vendor Runtime and Development Environment

qBraid Lab is a cloud-based quantum IDE, delivered as a hosted JupyterLab environment, with pre-installed quantum SDKs enabling development, simulation, and execution of quantum programs across different vendors from a single environment. The platform is built on top of the qBraid-SDK, which functions as a platform-agnostic quantum runtime framework designed for both quantum software and hardware providers, handling the full lifecycle of a quantum job — from defining the program specification through job submission, monitoring, and post-processing of results.

The Architectural Choice That Enables Multi-Vendor Support

The key design decision underpinning qBraid's interoperability is that the SDK does not adhere to a fixed circuit-building library or quantum program representation. Instead, it allows providers to dynamically register any input program type they want supported, extended by a modular pipeline for validation, transpilation, and compilation.

This is architecturally different from frameworks that treat one vendor's circuit format as the canonical representation and translate everything else into it. By decoupling the runtime from any single program representation, qBraid can accept circuits written in Qiskit, Cirq, PyQuil, or lower-level representations like OpenQASM and QIR, and route them toward whichever backend the developer specifies.

What Hardware Is Actually Reachable

For architects evaluating this as a genuine benchmarking sandbox, the practical question is which QPUs are reachable and how. Using the SDK on qBraid Lab provides direct, pre-configured access to QPUs from IonQ, AQT, QuEra, Rigetti, Pasqal, and IQM, along with on-demand simulators from qBraid, AWS, IonQ, QuEra, Quantinuum, Rigetti, and Pasqal.

IBM hardware is reached through a dedicated integration point: the QiskitRuntimeProvider lets developers submit jobs to IBM Quantum devices directly, with device metadata in the platform showing real backends such as ibm_brisbane — a 127-qubit system — sitting alongside non-IBM hardware in the same interface.

According to the platform's own description, qBraid provides automatic transpilation between frameworks, per-device adaptation, and a unified job lifecycle, enabling any program to run across more than 20 devices and 11 providers through a single SDK and API. The transpilation layer is what removes the manual rewrite burden: the runtime rewrites a program to match each backend's native gate sets, qubit limits, and submission formats automatically, so a developer does not need to hand-adapt code for every vendor they want to test.

Institutional Validation

qBraid's positioning as neutral, cross-vendor infrastructure has received two forms of external validation worth noting for technical decision-makers evaluating the platform's staying power.

First, in September 2025, qBraid was awarded a $300,000 Phase I grant from the National Science Foundation's Pathways to Enable Open-Source Ecosystems (POSE) program, specifically to support the growth of the qBraid-SDK as a hardware-agnostic, open-source runtime and middleware framework. The grant funds development of a graph-based transpiler intended to enable seamless conversion between quantum program types, directly targeting the fragmentation problem created by proprietary, vendor-specific stacks. This built on existing interoperability the SDK already had across more than 25 devices and more than 20 frameworks, including Qiskit, Cirq, and PyQuil, alongside low-level representations like OpenQASM and QIR.

Second, and notably, IBM itself — a vendor whose own SDK competes for developer attention — has endorsed third-party access to its hardware through this kind of platform. IBM has named cloud provider OVHcloud and qBraid as recommended providers of notebook environments for Qiskit users looking to work with Qiskit over the cloud. That IBM directs its own developer community toward a platform that also gives equal-footing access to IonQ, Rigetti, and other competitors' hardware is a meaningful signal about the direction the quantum tooling ecosystem is heading: toward interoperability rather than walled gardens, at least at the development-environment layer.

Qiskit-Braket Provider v0.11: A Narrower, Deeper Bridge

Where qBraid Lab aims to be a full cross-vendor development platform, the Qiskit-Braket Provider serves a more specific purpose: it acts as a bridge between IBM's open-source Qiskit framework and Amazon Braket, AWS's managed quantum computing service. AWS released version 0.11 of the provider on February 20, 2026, and the update meaningfully expands what Qiskit users can do when targeting Braket-hosted hardware. The release expands Qiskit features for Amazon Braket users and improves access to Braket backends, enabling compilation either on the Braket SDK directly or via OpenQASM programs.

What's New in v0.11

Three changes stand out for architects doing cross-vendor benchmarking work:

1. Flexible compilation through to_braket. The release supports flexible compilation features for Braket using common Qiskit transpile functionality through the to_braket function. This function is the practical linchpin of cross-vendor workflows: it accepts inputs from Qiskit, Braket, and OpenQASM3, unlocking compilation directly for Braket devices regardless of which format the circuit originated in.

2. New primitives that mirror Qiskit's own. The release introduces BraketEstimator and BraketSampler primitives, which mirror routines found in equivalent Qiskit primitives and include features aimed at running with Amazon Braket program sets. For teams already structuring their Qiskit workflows around the Estimator/Sampler primitive pattern — the standard interface Qiskit has moved toward for expectation-value and sampling-based workloads — this means Braket-hosted hardware can be slotted into that same pattern without restructuring application code.

3. Qiskit 2.0 support with backward compatibility. The release supports Qiskit 2.0, and is fully back compatible to v0.34.2, meaning teams do not need to fork their codebase or maintain separate branches to support both older and newer Qiskit installations while integrating Braket.

A Concrete Cross-Vendor Workflow

The practical value of the to_braket function is best illustrated through a documented workflow involving IonQ hardware accessed via Braket. The Qiskit transpiler adapts circuits so they are executable on all target devices, and documentation walks through this specifically for the IonQ Aria-1 device. A circuit generated in Qiskit is converted with a call such as to_braket(qiskit_random_circuit, basis_gates=aria_supported_gates), and the developer never has to hand-construct a separate Braket circuit object — that translation happens internally at the moment the Qiskit circuit is submitted to the Backend.

This matters for benchmarking because it means the same circuit-construction code, and by extension the same algorithmic logic, can be submitted to IonQ's trapped-ion hardware via Braket, to Rigetti's superconducting chips via Braket, and — through the separate QiskitRuntimeProvider path — to IBM's own backends, all from Qiskit-native code. Multiple independent outlets covering the release, including Quantum Zeitgeist, The Quantum Insider, and AWS's own engineering blog, converge on the same characterization: the Qiskit-Braket provider functions as connective tissue between IBM's open-source framework and AWS's managed quantum service, rather than as a replacement for either.

How qBraid Lab and the Qiskit-Braket Provider Fit Together

These two tools are not competitors; they operate at different layers and can be combined. qBraid Lab is the broader sandbox — the hosted environment where an architect can spin up a JupyterLab session with every relevant SDK pre-installed and immediately reach a wide roster of hardware and simulators through one authentication layer. The Qiskit-Braket Provider is the specific plumbing that makes one particular cross-vendor path — Qiskit circuits reaching Braket-hosted hardware — work smoothly, with proper support for modern Qiskit primitives and version compatibility.

In practice, a technical team benchmarking hardware vendors might use qBraid Lab as the workspace where experiments are orchestrated and results from IonQ, AQT, QuEra, Rigetti, Pasqal, and IQM hardware are collected alongside IBM Quantum results reached through the QiskitRuntimeProvider integration. Within that same environment, or independently, the Qiskit-Braket Provider's to_braket function can be used to fine-tune exactly how a circuit compiles for a specific Braket-hosted backend — for example, targeting IonQ's Aria-1 with its particular native gate set — giving finer control over compilation than a fully automated cross-vendor transpiler might offer by default. The combination gives architects both breadth (one environment, many vendors) and depth (fine-grained compilation control for a specific vendor path) without maintaining separate codebases for each.

What's Actually Being Benchmarked: Hardware Context for 2026

Understanding why cross-vendor benchmarking matters requires some context on how fast the underlying hardware has been moving. IBM's 2026 hardware portfolio spans from the 127-qubit Eagle processors available to all IBM Quantum Network members, through the 433-qubit Osprey and 1,121-qubit Condor systems, to IBM's newer Flamingo modular systems, which target configurations exceeding 4,000 qubits. These are dramatically different scales of machine, and a workload that runs well on Eagle-class hardware may behave very differently on a Flamingo-class modular system.

Rigetti's roadmap tells a similarly fast-moving story. Current production systems include the 84-qubit Ankaa-2, built on Rigetti's fourth-generation chip architecture, which features tunable couplers and a square lattice designed for high-fidelity two-qubit operations, achieving a 98% median fidelity on that metric. Since then, Rigetti has progressed further: Helios, shipped in November 2025, delivers 50 error-corrected logical qubits at what is described as an industry-best 2:1 physical-to-logical qubit encoding ratio, and a separate 108-qubit Cepheus-1 modular chiplet system followed in April 2026. IonQ, for its part, has continued to push gate fidelity gains on its trapped-ion platform, a modality with fundamentally different noise characteristics and connectivity properties than the superconducting approaches used by IBM and Rigetti.

Given how quickly each vendor's roadmap shifts — new chip generations, new qubit counts, new error-correction ratios arriving within months of each other — the practical value of vendor-agnostic sandboxing is less about locking in a single "winner" and more about maintaining a repeatable benchmarking process. An architecture team that has built its evaluation pipeline around qBraid Lab and the Qiskit-Braket Provider can re-run the same benchmark suite each time a vendor ships a new chip generation, without having to redevelop vendor-specific harnesses each time.

Practical Considerations for Adoption

For technical decision-makers evaluating whether to build benchmarking infrastructure around these tools, a few practical points are worth weighing.

First, qBraid's transpilation layer, while broad in coverage, still routes IBM access through a dedicated QiskitRuntimeProvider integration rather than a fully unified abstraction — meaning IBM-specific behavior and quotas are still visible to the developer, even within the shared environment.

Second, the Qiskit-Braket Provider's backward compatibility down to v0.34.2 alongside Qiskit 2.0 support reduces the operational burden of maintaining multiple Qiskit versions across a team, which matters for organizations with existing Qiskit codebases that can't be upgraded overnight.

Third, because both tools are under active development — qBraid's NSF-funded graph-based transpiler work and AWS's ongoing Braket provider releases — teams adopting them should expect the underlying APIs to continue evolving, and should structure benchmarking code with that churn in mind, favoring the more stable, primitive-based interfaces (Estimator/Sampler) over lower-level circuit manipulation where possible.

The broader trend these two tools represent is unmistakable: the quantum software stack is consolidating around shared abstractions rather than proprietary silos, even as the underlying hardware landscape continues to diversify and accelerate. For architects and technical leaders responsible for quantum computing strategy, that consolidation is good news — it means benchmarking decisions can increasingly be made on hardware merit rather than on which SDK a team happened to standardize on first.