Real IBM Quantum hardware
QubitLab runs on IBM's superconducting processors through qiskit-ibm-runtime using your own API token. Here is what the machines are, what the names mean and what the limits protect you from.
The machines
| Processor family | Qubits | Two-qubit gate | Example backends |
|---|---|---|---|
| Eagle r3 | 127 | ECR | ibm_brisbane, ibm_sherbrooke, ibm_kyiv, ibm_osaka |
| Heron r1 / r2 | 133 / 156 | CZ | ibm_torino (r1), ibm_fez, ibm_marrakesh (r2) |
| Fake twins | same | same | fake_sherbrooke, fake_torino, fake_manila (5q), fake_belem (5q)… |
Names and availability change: machines are retired and new ones appear. The Hardware tab lists exactly what your IBM account can see right now, with qubit count, queue length and whether the backend is operational.
Getting access: IBM Quantum Platform on IBM Cloud
Since 2025 IBM Quantum runs on IBM Cloud. Create a free IBM Cloud account, open the Quantum Platform and create an instance on the Open Plan (10 free minutes of quantum time per month). You then have two strings: an API key (the token) and the instance CRN, which starts with crn:v1:bluemix:public:quantum-computing. Paste both into QubitLab → Settings. The token is validated by listing your backends, encrypted and never shown again.
Demo (October 2026, a fresh free account): QubitLab listed three Heron r2 machines, ibm_kingston, ibm_fez and ibm_marrakesh, 156 qubits each, with thousands of queued jobs. The calibration panel showed median T1 ≈ 358 µs on ibm_kingston, readout errors around 1.2 % and CZ errors near 0.12 % on the best couplers. A Bell circuit was submitted from the IDE and tracked in the Jobs drawer until IBM returned the counts.
Calibration and topology, live
Every backend row in Run as → Hardware has a calibration button. It fetches the device's current Target from IBM: T1 and T2 per qubit, readout error, sx error, the two-qubit gate error on every coupler, the queue length and the calibration time. The topology map draws the qubits as nodes coloured by readout error and the couplers as edges coloured by two-qubit error (green = low, red = high), the same information IBM shows on its device pages, so you can pick a machine whose good qubits fit your circuit. The same panel exists for the fake backends in Run as → Simulate, without a token.
Compare machines. Tick up to five backends and press Submit: QubitLab creates one job per machine and shows them side by side with status, the IBM job id (linked to the IBM workload page), the top outcomes and the Hellinger fidelity against the ideal distribution, so you can see which device gave the cleanest Bell state today.
How a hardware run works
How a run works. 1) Your token is checked by listing backends, then encrypted (Fernet) and stored; only abcd…wxyz is ever shown again. 2) The circuit is transpiled for the chosen backend; qubits ≤ 6, shots ≤ 4096 and depth ≤ 300 are enforced before anything is sent. 3) SamplerV2 submits one job; QubitLab stores the IBM job id and polls every 10 s, so a retry never submits twice. 4) When DONE, counts are fetched and compared with the ideal statevector and, optionally, the fake twin.
Limits
| Limit | Default | Why |
|---|---|---|
| Qubits | 6 | Keeps the ideal reference cheap and the result interpretable; raise MAX_QUBITS_HARDWARE in .env. |
| Shots | 4096 | Open Plan minutes are limited; 4096 gives ±0.8 % statistics. |
| Transpiled depth | 300 | Beyond a few hundred layers the result is mostly noise on today's devices. |
Reading a backend's calibration. Each qubit has its own T1, T2, readout error and gate errors, and each coupling has its own two-qubit error (ECR or CZ). The transpiler at level 2–3 uses them to choose good qubits. Expect a Bell state to come back with roughly 90–97 % in {00, 11} on current hardware.
Statuses you will see: QUEUED (waiting; can be minutes to hours), RUNNING, DONE, ERROR, CANCELLED. Cancel in QubitLab cancels the IBM job too.