IBM Quantum Platform: Access, Hardware and Qiskit Runtime Guide

The IBM Quantum Platform is a cloud-based research infrastructure that provides researchers and software engineers with programmatic access to utility-scale quantum processing units (QPUs) and quantum simulators. Administered through IBM Cloud and IBM Research, the service pairs physical superconducting quantum processors with the open-source Journal of Open Source Software (JOSS) recognized Qiskit framework, allowing researchers to compile quantum circuits, test error mitigation, and execute algorithms across physics, chemistry, and optimization.

What it is

The IBM Quantum Platform functions as both an administrative web console and a distributed execution runtime known as the IBM Quantum Compute Service. Originally launched in 2016 as the IBM Quantum Experience, the platform has transitioned from an educational visual tool into a cloud infrastructure where researchers configure compute instances, monitor processor availability, and submit workloads programmatically via the qiskit-ibm-runtime client library.

The core execution model relies on Qiskit Runtime, an architecture that colocates classical pre-processing and post-processing routines with quantum hardware control systems to reduce network latency during iterative circuit execution.

Who runs it and what it covers

The platform is operated by IBM Quantum across cryogenic datacenters housing dilution refrigerators that cool superconducting transmon qubits to millikelvin temperatures. The active cloud fleet is organized by processor families and revisions:

• Heron Family: The primary utility-scale architecture with 156 superconducting qubits. Revision r3 (July 2025) uses high-density flexible cabling to enhance single- and two-qubit gate fidelity and coherence over earlier Eagle processors.
• Nighthawk Family: A grid topology architecture engineered for high connectivity. Revision r1 (December 2025) provides 120 programmable qubits, while revision r2 (September 2026) incorporates 120 programmable qubits across 458 physical qubits with high-speed reset capabilities.
• Retired Families: Earlier processors—including Canary, Falcon, Hummingbird, Eagle, and Osprey—are retired from public cloud service.
• Backend Designations: Processors use the format ibm_<city> (e.g., ibm_kingston); city names serve as identifiers and do not reflect physical installation sites.

Access Tiers and Allocations

Hardware access is managed through four plan tiers on the platform Instances dashboard:

• Open Plan: A free tier providing 10 minutes of QPU runtime per 28-day rolling window, measured in Resource Units (RUs) on the Workloads dashboard. Open Plan accounts access select QPUs but cannot submit Session jobs.
• Pay-As-You-Go Plan: A metered usage tier billed by compute time with configurable financial and execution time caps.
• Flex Plan: A contracted allocation model for mid-scale research projects requiring pre-purchased compute minutes.
• Premium Plan: An enterprise subscription providing dedicated hardware reservations, priority queuing, and direct support.

How to search or use it

Researchers access hardware through a standard six-step workflow using the web dashboard and Python SDK:

1. Create a Service Instance: Sign in with an IBMid, navigate to the Instances page on the IBM Quantum Platform console, and create an instance under the Open Plan or Pay-As-You-Go tier.
2. Save Credentials Locally: Generate an API token and store it in your trusted local Python environment:

   from qiskit_ibm_runtime import QiskitRuntimeService
   QiskitRuntimeService.save_account(token='YOUR_API_KEY', overwrite=True)

3. Query Operational Backends: Instantiate the service and select an operational, unreserved processor:

   service = QiskitRuntimeService()
   backend = service.least_busy(operational=True, simulator=False)

   Topological properties and coupling graphs can be analyzed alongside NetworkX graph analysis to evaluate qubit routing constraints before transpilation.

4. Build Primitive Unified Blocs (PUBs): Transpile quantum circuits to the target basis gates and package them with parameter bindings and observables into Primitive Unified Blocs.
5. Select an Execution Mode: Choose a scheduling mode:
   • Job Mode: Dispatches standalone circuits (mode=backend) through the standard public queue.
   • Batch Mode: Packages independent jobs together (mode=batch), threading classical compilation steps for rapid consecutive execution.
   • Session Mode: Reserves exclusive hardware access (mode=session) for iterative algorithms such as VQE. External workloads and calibrations are blocked during the session window. Unavailable on the Open Plan.
6. Submit Primitives and Monitor Jobs: Run PUBs through SamplerV2 or EstimatorV2. Track Resource Unit consumption on the web Workloads dashboard. Results can be processed alongside scientific computing pipelines such as the Brightway Python framework or evaluated using SHAP value interpretability tools.

Strengths and limits

Key advantages and operational boundaries include:

• Utility-Scale Capability: Real hardware access to 156-qubit Heron r3 and 120-qubit Nighthawk r2 processors beyond classical statevector simulation capacities.
• Algorithmic Efficiency: Batch and Session execution modes mitigate classical-quantum round-trip latency and queue overhead.
• FAIR Data Compliance: Open Plan access allows independent reproduction of quantum benchmarks following the RDA FAIR Data Maturity Model.
• Runtime Quotas: Open Plan users are limited to 10 minutes per 28 days and excluded from Session mode.
• Decoherence Noise: Superconducting qubits require error mitigation techniques (ZNE, Pauli twirling, dynamical decoupling) for high-depth circuits.
• TTL Expiration: Batches and sessions enforce interactive and maximum Time-to-Live timers; inactive workloads temporarily deactivate.

Alternatives

Cloud quantum computing platforms offer distinct architectural and commercial models:

Platform	Hardware Modality	Primary SDK	Deployment Model	Free Tier / Allocation
IBM Quantum Platform	Superconducting transmon (Heron 156q, Nighthawk 120q)	Qiskit, Qiskit Runtime	IBM Quantum console & IBM Cloud instances	Open Plan (10 min runtime / 28-day window)
Amazon Braket	Multi-vendor: Ion trap (IonQ), Superconducting (IQM, Rigetti), Neutral atom (QuEra)	Amazon Braket SDK, PennyLane	Integrated AWS cloud infrastructure	AWS Free Tier credits & research grant credits
Azure Quantum	Multi-vendor: Ion trap (Quantinuum, IonQ), Neutral atom (Atom Computing)	Azure Quantum QDK, Q#, Qiskit	Microsoft Azure portal & CLI	Developer credits per workspace instance
Google Quantum AI	Superconducting transmon (Sycamore)	Cirq, TensorFlow Quantum	Academic co-design & research partnerships	Direct research grant allocations
Rigetti QCS	Superconducting transmon (Ankaa)	pyQuil, Quil-T	Rigetti Cloud Services API & partner clouds	Developer tiers & research credit allowances

Frequently Asked Questions

What is the difference between Qiskit Runtime Job mode, Batch mode, and Session mode?

Job mode runs single primitive queries independently in the standard queue. Batch mode submits multiple independent jobs together, allowing the system to thread classical pre-processing and run quantum tasks consecutively. Session mode reserves exclusive QPU access for iterative algorithms, preventing foreign jobs and calibrations from interrupting parameter updates.

Can researchers on the Open Plan run variational algorithms using Session mode?

No. IBM Quantum documentation states that Open Plan instances do not support Session mode. Variational algorithms on the free tier must be submitted as individual tasks in Job mode, which incurs standard queue delays between iterations, or executed on a paid Pay-As-You-Go instance.

How are QPU usage limits tracked and enforced on IBM Quantum Platform?

Usage is tracked in Resource Units (RUs) reflecting actual seconds of QPU execution time. Remaining allowances display on the platform Workloads dashboard. The Open Plan balance resets every 28 days, while Pay-As-You-Go instances allow administrators to establish budget caps to halt jobs when limits are reached.

What programming tools are required to interact with IBM Quantum QPUs?

Access requires a standard Python environment with the qiskit library and the qiskit-ibm-runtime package installed. Browser-based graphical circuits can be assembled via IBM Quantum Composer, but programmatic experiments and primitives require Python execution.

Sources

• IBM Quantum Documentation. “Set up your IBM Cloud account.” Published by IBM. URL: https://quantum.cloud.ibm.com/docs/en/guides/cloud-setup. Read: 2026-11-07.
• IBM Quantum Documentation. “Create and manage instances.” Published by IBM. URL: https://quantum.cloud.ibm.com/docs/en/guides/instances. Read: 2026-11-07.
• IBM Quantum Documentation. “Introduction to Quantum Compute execution modes.” Published by IBM. URL: https://quantum.cloud.ibm.com/docs/en/guides/execution-modes. Read: 2026-11-07.
• IBM Quantum Documentation. “Processor types.” Published by IBM. URL: https://quantum.cloud.ibm.com/docs/en/guides/processor-types. Read: 2026-11-07.
• IBM Quantum Documentation. “View backend details.” Published by IBM. URL: https://quantum.cloud.ibm.com/docs/en/guides/qpu-information. Read: 2026-11-07.