IBM Phoenix opens Nighthawk r2 access—and changes the throughput question

IBM has made ibm_phoenix, its first Nighthawk r2 quantum processing unit (QPU), available to Premium, Flex, and Pay-As-You-Go customers. The September entry in IBM's Compute Service changelog lists a 120-programmable-qubit device and says a faster reset mechanism raises maximum circuit throughput above 100,000 circuits per second.

IBM's August 31 technical post already described Nighthawk r2 as available; the September changelog identifies the backend and eligible plans without giving an exact access-start date. For operators, the practical question is how much faster reset helps their workload once queueing, allocation, and result quality are included.

What changed inside the processor

IBM's processor documentation records Nighthawk r2 as a September 2026 revision with 120 programmable qubits and 458 physical quantum elements. The larger physical count includes couplers and reset elements that users do not program as ordinary qubits.

In IBM's account, each programmable qubit can be reset through a dedicated dissipative element. The company says this cuts the default repetition delay from 250 microseconds to 1 microsecond while maintaining Heron-class gate fidelity. Its technical blog reports more than 100,000 maximum circuits per second and describes a 25-fold throughput comparison with Heron.

IBM's backend documentation defines maximum circuits per second (MCPS) using a circuit with a Hadamard gate and one measurement, including reset and reinitialization. The gate prepares a superposition for the measurement. This short benchmark measures repeated execution, not the number of complete application jobs a service can finish each second.

Preparation, compilation, queueing, data transfer, and classical analysis add time around QPU execution. Error mitigation can also require additional circuit executions. A workload comparison must count that work rather than apply the headline rate to the original circuit count alone.

Access is tied to a plan and region

IBM lists Phoenix for Premium, Flex, and Pay-As-You-Go, with no Open Plan access in the September notice. Its public plan documentation describes Flex as prepaid QPU minutes, Pay-As-You-Go as consumption billing, and Premium as an enterprise subscription. Budget estimates need the account's applicable rate, QPU usage, and any separate classical-computing or storage charges.

The public compute-resource listing identifies Phoenix in the us-east region. Actual use still depends on an account instance granting access. IBM's plan documentation requires purchased Flex minutes to be allocated to instances. Operators should check their instance's remaining allocation alongside backend availability before scheduling a run.

That means a capacity plan should record the plan, instance, region, allocation, pending jobs, maintenance status, and expected retry policy. A new processor does not remove those service-management variables.

Design experiments around the whole clock

Higher circuit throughput matters most when reset and repetition are meaningful bottlenecks. Parameter sweeps, sampling-heavy studies, and repeated calibration or mitigation circuits may benefit more than a small job dominated by queueing or classical work.

Before moving a workload, an operator can measure four intervals separately: preparation and compilation, queue wait, QPU usage, and post-processing. IBM's execution-time guidance says job limits use quantum execution time rather than wall-clock time, reinforcing the need to preserve both clocks.

The same comparison should keep result quality visible. More completed circuits are useful only if the selected configuration answers the research question at an acceptable uncertainty. IBM's reported observable-estimation demonstration on circuits containing 7,500 gates used probabilistic error amplification, an error-mitigation method. That result does not establish the accuracy of an unmitigated circuit or another application.

Phoenix therefore changes the operator's question from “when will Nighthawk r2 be accessible?” to “which workload bottleneck does its reset speed remove under our plan and queue conditions?” A controlled pilot should retain the previous backend as a baseline, cap spending, record total wall time, and compare usable results—not just submitted circuit counts.