Skip to main content
Requires the latest qbraid pre-release: pip install --upgrade --pre qbraid. Calibration data is refreshed from each hardware provider roughly hourly.
Superconducting QPUs are not uniform: qubits differ in readout fidelity, and two-qubit gates only exist between physically coupled pairs, each with its own error rate. The QbraidProvider exposes both facts programmatically, so you can inspect a device before you submit to it, and place your circuit on the qubits where it will perform best.

Fetching calibration data

Every QbraidDevice has two entry points:
coupling_map is the device’s physical connectivity: sorted, deduplicated (source, target) qubit pairs, derived from the calibrated two-qubit gate edges. It is cached on the device instance, since hardware topology does not change between calibrations. get_calibrations() returns the full live snapshot and always fetches fresh data. The two most useful fields:
Both return None for devices without published calibration data, such as simulators.

Devices with calibration data

All device IDs that map to the same physical hardware share one calibration snapshot, so rigetti:rigetti:qpu:cepheus-1-108q and aws:rigetti:qpu:cepheus-1-108q return identical data.
A device can have calibration data with an empty edge list. AQT’s Ibex-Q1 is a trapped-ion system with all-to-all connectivity, so there are no discrete coupling edges to report: coupling_map returns an empty tuple, not None. For IonQ trapped-ion devices, see device.profile.characterization instead.
You can also query the underlying REST endpoint directly, which works for any device ID including those not available for direct submission:

Plotting the connectivity graph

The qbraid.visualization module renders the graph in one call, colored by live calibration data. Edges are colored by two-qubit gate error and nodes by readout error, on a single-hue scale where darker is better, matching the topology view in qBraid Lab:
The dotted outline is a qubit in the lattice footprint with no working couplings. Light qubits and edges are the ones to avoid. The layout comes from the device document’s topology config, so square lattices (Rigetti) and clipped lattices (IQM) both render their true physical geometry; devices without a lattice config fall back to a force-directed layout. To build a custom plot, the lattice_positions helper maps qubit ids to grid coordinates from the same config:
The same call works unchanged on any device with calibration data. IQM’s Garnet renders its clipped diamond lattice:

Choosing the best qubits

With the calibration data in hand, qubit selection becomes a graph problem. Build a weighted graph from the coupling map, then the single best-calibrated pair is one line:
For a linear circuit on n qubits, search for the connected chain that minimizes the summed two-qubit error:
Calibrations shift with every refresh, so re-run the selection shortly before you submit. The best chain this hour is not always the best chain tonight.

Running on the qubits you chose

Rigetti direct: hand-placed native gates

On the Rigetti direct path, programs that bypass quilc must already use native gates on physical qubits, which is exactly what the coupling map enables. A Bell pair on the best-calibrated edge:
The correlated outcomes (00 and 11) came back at 88 percent on hardware, consistent with the roughly 0.4 percent CZ error and few-percent readout error of the chosen pair.

Qiskit: constrain transpilation to the real topology

If you would rather let a transpiler do the routing, feed the coupling map to Qiskit and pin your circuit to the chain you selected. This works for any gate-model device on qBraid:
Every two-qubit gate in the transpiled circuit now acts on a physically coupled, well-calibrated pair, and no SWAP overhead is silently inserted for qubits you did not choose.
Transpile against the coupling map of the exact device ID you will submit to. Vendor-routed and direct device IDs share hardware and calibrations, but a circuit laid out for one device will not fit another.