IBM Quantum Updates & Release Notes

The first Nighthawk r2 QPU is now available

Premium, Flex, and Pay-As-You-Go Plans now have access to ibm_phoenix, the first IBM Quantum Nighthawk r2 QPU and our fastest processor yet. ibm_phoenix is a high-connectivity, square-lattice 120-programmable-qubit device that delivers up to 25× higher throughput than Heron while matching its fidelity.

The gains come from a newly introduced independent high-speed reset that returns every programmable qubit to the ground state faster and more completely. As a result, the default repetition delay is 1 µs (previously 250 µs), which pushes throughput above 100,000 Max Circuits Per Second (MCPS). For more about how IBM tracks quantum hardware performance across metrics of scale, quality, and speed, see this blog.

The increased speed and connectivity make it possible to do more usable work from the same capacity, with the largest, most demanding workloads benefitting the most. Larger experiments, broader parameter sweeps, and methods that were once too costly at scale are now practical to run routinely.

ibm_phoenix is also built for the next era of quantum error correction research. Alongside high-speed reset, it supports mid-circuit reset and dynamic circuits for real-time control over error correction.

Updates to IBM Quantum Platform

A recent update to IBM Quantum Platform makes it easier to understand your job results, unlocks powerful new circuit design capabilities in Composer, and keeps you informed about your usage limits — so you can focus more on your quantum work.

Job results & workloads

• Bit-by-bit outcomes view — a new way to view Sampler measurement results, breaking down outcomes bit by bit instead of by full state. Useful as an alternative to the Measurement outcomes view when results contain many distinct states.
• Circuit timing chart — shows a scheduled timeline of a circuit's operations (gates, channels, durations). Available for Sampler and Executor jobs. Requires enabling timing data retrieval.
• Chunk/span execution diagnostics panel — a new panel on job details showing chunk- and span-level execution diagnostics. See Sampler input/output for what this data means and how to enable it when submitting jobs.
• Device calibration data at a glance — job details now show the device calibration data from the time of submission or execution via a "View calibration history" link.
• Executor results visualization — job details pages now render results for Executor jobs. See the Directed execution model (beta) guide for more on Executor.
• Dynamic circuits now render on job details — with OpenQASM 3.0 support in Composer (see more below), circuits that previously failed to render (for example, those using dynamic circuits) now display correctly on the job details page.
• Histogram improvements — faster loading, smoother zoom in/out, and a new selection tool for narrowing in on specific result ranges.
• qiskit-ibm-runtime code snippets in job results — copy-ready code to retrieve a job by ID; for Executor jobs, an additional snippet lets you replicate the job.
• Custom date range filter added to the workloads table.
• Clickable instance names and tags in workload detail pages, linking to the related resource.

Navigate to your results on the Workloads page to see these improvements.

Composer: OpenQASM v3.0 support

Composer now supports OpenQASM v3.0, adding:

• Gate modifiers — ctrl, inv, pow, etc.
• Loops — for and while
• Conditional logic — if/else
• Box annotations — group and label sections of a circuit

Also included: smoother rendering for large circuits, and a fix for PNG exports failing on large circuits.

Visit the Composer to explore this new update.

Instance usage limits

• Premium and Open Plan instances that hit their usage limit now display the exact date access resumes, based on the rolling usage window.

See more on your Instances page.

Qiskit Runtime rename

• Qiskit Runtime service is now IBM Quantum Compute Service — This is a naming change only and does not require any code changes or updates to existing applications. You might notice the new name throughout the user interface and documentation.

Historically, the term Qiskit Runtime was used to refer to three related but distinct concepts.

Any hardware provider that wants Qiskit users to run workloads on its quantum computers must provide two provider-specific components:

• A Qiskit SDK extension, which enables users to submit jobs to the provider. In IBM's case, this is the open-source qiskit-ibm-runtime library. Rather than communicating directly with the quantum computer, it submits jobs to a cloud API.
• A runtime execution environment, which runs on the quantum computer itself. This component understands Qiskit primitives, translates them into hardware-specific operations, and executes them on the quantum hardware. In IBM's case, this is IBM Qiskit Runtime.

Between these two components sits a third element: the managed cloud service that receives jobs from the qiskit-ibm-runtime SDK and orchestrates their execution. This service is responsible for capabilities such as authentication, scheduling, queue management, workload routing, usage tracking, limits, and analytics. It does not process Qiskit primitives itself; instead, it dispatches workloads to the appropriate quantum computer, where the runtime execution environment performs the actual execution.

Historically, this cloud service was also called Qiskit Runtime Service, even though it is conceptually different from the runtime itself. This dual use of the term Qiskit Runtime — to describe both the execution environment and the managed cloud service — blurred the architecture and made it difficult to distinguish the open-source components from the managed cloud offering.

Renaming Qiskit Runtime Service to IBM Quantum Compute Service resolves this ambiguity. The resulting architecture becomes much clearer:

• qiskit-ibm-runtime: the open-source Qiskit extension that submits workloads.
• IBM Quantum Compute Service: the managed cloud service that authenticates, schedules, manages, and routes workloads.
• IBM Qiskit Runtime (or IBM Qiskit Runtime Execution Environment): the execution environment running on the quantum computer that processes and executes Qiskit primitives.

Store instruction

• Support for the Store instruction on IBM® QPUs - Now you can simplify complex classical computations in your quantum circuits with the Store instruction.
• Compute a classical expression mid-circuit and save the result to a variable or register, which can then immediately control subsequent quantum gates. Instead of deeply nested inline expressions, you can break computations into named intermediate steps, so that complex classical feedback logic is easier to read and maintain.
  Common use cases include the following:
• Dynamic circuits with mid-circuit measurements and classical feedback
• Long-range entanglement preparation
• Complex conditional logic based on measurement outcomes
  To use the store instruction, first ensure you're running the latest version of qiskit-ibm-runtime (pip install --upgrade qiskit-ibm-runtime), then see the documentation for more information and an example.
  Note that before submitting jobs, you should verify compatibility with each primitive's options in the documentation: Sampler options | Estimator options | Executor options.

Classroom accounts

• New Classroom Accounts: Professors can now request a Classroom Account to manage and facilitate access for their students. With Classroom Accounts, students can use Open Plan resources without needing to provide personal credit card information.
• New export options now available in IBM Quantum: Introducing new export capabilities that make it easier for account administrators to analyze, share, and work with their data.

New in the Analytics page:

• You can now export charts in SVG or PNG format.
• You can export all analytics data, including the data behind the charts, as CSV.

Find the export menu at the top-right corner of each card on the page.

New in the Access management page:

• Export both the Users table and the Access Groups table in CSV format.

Find the export menu at the top-right corner of the table.

• New resources and hardware for Open Plan users: The IBM Quantum Open Plan now features new learning resources, new hardware, and a special one-time promotion for eligible users.
• A new course, Designing and leading quantum projects, is now available. This course covers key topics for users looking to develop or secure funding for a quantum project, including early-stage planning, team roles and responsibilities, identifying meaningful use cases, defining measures of success, and a guide to grant writing best practices.
• The Heron r2 ibm_kingston —one of our highest-performing quantum computers—is now available to all Open Plan users.
• Log 20 minutes of compute in any 12-month period and you can opt in to a special one-time offer: 180 minutes for the next 12 months.

With expanded runtime and new educational resources, users can run everything from introductory circuits to advanced hybrid workflows.

These efforts reflect our commitment to open access, open education, and open science in quantum computing. Read more: Doubling down on open-access quantum computing.

The EU gets its first Heron r3

Maintenance has been completed on ibm_aachen and the QPU is now back online in the eu‑de region.

ibm_aachen has also been upgraded to be the first QPU in the EU to feature the latest Heron r3 processor. It is the third r3 in our global fleet, after ibm_boston and ibm_pittsburgh in the US.

Heron r3 continues to deliver improved error rates and overall system performance compared to Heron r2, demonstrating more reliable execution and better results for workloads. For example, on ibm_aachen, we observe a large boost in 𝑇2 (phase coherence time) from 150 µs to 250 µs. You can view metrics like these for all QPUs in the shared fleet on the Compute resources page.

ibm_torino to retire

The ibm_torino QPU will retire on or around 1 April 2026. Once this QPU is retired, it will no longer accept jobs.

If you would like to retrieve job data from important past jobs, please refer to the following documentation.

Increase in repetition delay time maximum

To provide more flexibility for users, we have expanded the allowable repetition delay time range from 20-500 µs to 20-2000 µs on our Heron and Eagle QPUs. The Nighthawk QPU delay time range continues to be 1000-4000 µs as previously announced. Note that if you choose to increase repetition delay (rep_delay), it will have a direct impact on your execution time and capacity consumption, but it might improve the fidelity of certain circuits. The default rep_delay remains unchanged on all QPUs.

You can find more information about repetition delay time, including how to change it, in Qubit initialization.

The latest enhancements to the Compute resources page include the following:

• Unified QPU view - All QPUs across regions are now displayed in a single table, making it easier to see status and calibrations of the shared fleet across the two regions. (You can still filter the Compute resources table by region using the funnel icon.)
• Single maintenance schedule - The maintenance schedule is now at the top of the page, even when no events are currently planned.
• "Instance access" details - When viewing a QPU's details, a new Instance access section shows all instances that grant the user access to that QPU for the selected account.

The first Nighthawk QPU and latest Heron QPU are now available.

These two powerful new processors debuted at the IBM Quantum Developer Conference in November.

• Premium and Flex Plans now have early access to ibm_miami, the first IBM Quantum Nighthawk QPU. Our most advanced quantum processor to date, Nighthawk is a 120-qubit device with a square-lattice topology (218 couplers versus Heron's 176) that is designed to support more complex workloads. Nighthawk has the highest coherence of our fleet - even higher than what was reported at QDC - with a median T1 of 350 µs.
• Note that ibm_miami is currently an exploratory QPU that is still being tested and optimized as part of our continual cycles of learning. As such, it temporarily has the following limitations:
  • Default repetition time has been temporarily increased from 250 µs to 4 ms, which will impact QPU time required to execute workloads
  • Dynamic circuits are not yet supported, and quality of mid-circuit measurements is limited
• Additionally, Premium, Flex, and Pay-As-You-Go Plans now have access to ibm_boston, our most performant IBM Quantum Heron r3 to date. It has demonstrated an EPLG at 100 qubits of 2.15e-3, with 57 of 176 possible two-qubit gates below the 1e-3 error level.

Introducing instance archiving for administrators on IBM Quantum Platform.

With this update, administrators can archive any instance within their account. Archiving an instance ensures that:

• Collaborators retain access to results and QPU metrics, properties, and calibrations from past workloads.
• No new workloads can be submitted to the archived instance, preventing unintended usage.
• Archived instances do not subtract anything from your account's plan allocation.
• All archived instances are neatly organized under a dedicated "Archived" tab.
• Administrators can reactivate an instance at any time.

Directed execution model.

This new execution model allows you to fine-tune error mitigation and other techniques without sacrificing performance by providing the ingredients to capture design intents on the client side, and shifting the costly generation of circuit variants to the server side. For example, you can use the Samplomatic library to define the exact layers in your circuits to apply Pauli-twirling and to inject noise. The new Executor primitive will then follow your directives to generate and execute the randomized circuit variants in Qiskit Runtime.