On September 22, IonQ announced it had developed and tested a decoder that performs quantum error correction decoding in real time using only 12 cores of an Apple M4 Max-equipped MacBook Pro, calling it the "industry's first end-to-end real-time quantum error correction decoder." The largest configuration involved 408 logical qubits in a circuit containing more than 550,000 T-gates. However, the input was simulated error data generated by IonQ from a noise model—no actual quantum computer was used. Why can a laptop CPU keep pace with processing that Google and Riverlane have pursued using dedicated high-speed circuits? And under exactly which conditions in the paper were the figures cited in the press release measured?
IonQ's decoding test at 408 logical qubits
The technical basis for the announcement is a paper posted to arXiv titled "Real-time decoder for a MegaQuOp quantum computer using a single CPU" (arXiv:2608.25027). The three authors—Min Ye, Andrii Maksymov, and Nicolas Delfosse—are all affiliated with IonQ. The preprint, not yet peer-reviewed, was posted as v1 on August 25 and revised as v2 on September 3; the press release followed about four weeks later. The phrase "industry's first" comes from IonQ's press release wording—the paper itself does not use this term.
In quantum error correction, a classical computer reads clues about errors occurring in qubits (the syndrome) and continuously infers where errors have occurred. This inference process is decoding, and it must run in parallel with the quantum computation. If decoding falls behind, unprocessed information accumulates, forcing the quantum computation to wait. In the worst case, this can cause the entire computation to slow exponentially.
The paper's definition of "real-time" means that decoding keeps pace with the rate at which error information is generated, avoiding a backlog that would halt the computation. Even so, when delays do occur, wait cycles are inserted, and the resulting extension in computation time is measured as "stretch."
The evaluation proceeded as follows. For three types of benchmark circuits, the paper generated error information using a circuit-level noise model based on IonQ's Walking Cat architecture. This was then decoded using 12 cores of a 2024 Apple M4 Max (in a MacBook Pro). The Quantum Insider, a specialist outlet, also explicitly noted that the test was not conducted on an operating quantum computer.
The largest configuration, the Heisenberg n266 circuit, allocates 408 logical qubits across 68 Q70 memory blocks (6 logical qubits each) and 20 CH2 magic state factories, for a total of 88 blocks. The assumed number of physical qubits is 11,680. Dividing this by the number of logical qubits gives approximately 28.6 per logical qubit (11,680 ÷ 408, calculated by the editors), though this figure includes the factory overhead and is distinct from the efficiency of the code itself. For the scale of logical operations, the paper cites 555,130 T-gates and 1,318,310 logical measurements, noting that the two figures are given side by side since conventions for counting "logical gates" vary.
Tracing "31.5 million operations" and "0.02%" back to the paper's tables
The press release states that these circuits performed "more than 31 million individual quantum operations." This figure of "31 million" corresponds, in Table 1 of the paper, to 31,548,792 total syndrome extraction cycles for the Heisenberg n266 circuit—a different quantity from a count of operations performed.
This figure of 31,548,792 is the sum of synchronized cycles across all 88 blocks, and moreover represents a scheduled value assuming zero decoding delay. Changing the error rate settings for the same circuit can push this number as high as 38,704,160. Readers seeking the actual number of logical operations should instead look to the T-gate and logical measurement counts discussed above.
Another figure concerns the extension in computation time. The press release states that real-time error correction was maintained with a stretch of "as little as 0.02%," describing this as performing millions of operations without delaying execution time. Lining up the values from Tables 2 through 4 of the paper yields the following:
| Circuit | Logical Qubits | Assumed Cycle Time | Error Rate 0.01% (p=10^-4) | Error Rate 0.05% (p=5×10^-4) |
|---|---|---|---|---|
| MIPT | 102 | 1 ms | 0.24% | 11.53% |
| Heisenberg n64 | 102 | 1 ms | 0.18% | 10.25% |
| Heisenberg n266 | 408 | 5 ms | 0.02% | 0.72% |
The error rate refers to the two-qubit gate error rate, and the stretch figure represents the increase in execution time due to inserted wait cycles. Just as "31 million" turned out to be a cycle count, the press release's "as little as 0.02%" is the value under the single most favorable condition among the three circuits: 408 logical qubits, a 5 ms cycle, and a 0.01% error rate. By contrast, the MIPT circuit with a 1 ms cycle shows an 11.53% stretch at a 0.05% error rate. The paper's abstract also summarizes results as a range—under 0.3% at a 0.01% error rate, and under 12% at a 0.05% error rate. Given that computation time can extend by more than 10% under unfavorable conditions, the description "without delaying" applies only to a portion of the table.
Vertical comparisons within the table are also not on equal footing. Only the 408-logical-qubit circuit was evaluated at a 5 ms cycle, while the two 102-logical-qubit circuits were measured at 1 ms. Given that the time available for decoding differs by a factor of five, one cannot conclude from this table that larger scale necessarily leads to smaller stretch.
The press release further states that it confirmed the classical hardware burden need not scale exponentially. What the paper actually demonstrates is more limited: an empirical finding that the required computational resources scale roughly in proportion to the number of blocks handled per core.
Why a single laptop CPU can keep pace
Most of the answer lies in the vastly different cycle times across qubit modalities. A superconducting-qubit cycle is roughly 1 μs—Google reported a measured value of 1.1 μs for its Willow processor. To keep pace with this rapid cycle, Google, IBM, and Riverlane have competed using dedicated hardware such as FPGAs, ASICs, and GPUs, racing to reduce latencies from hundreds of nanoseconds down to tens of microseconds. IonQ's paper, by contrast, assumes ion-trap cycle times of 1 ms and 5 ms, positioning 1 ms as a long-term representative value and 5 ms as a near-term one. Dividing 1 ms by Willow's measured 1.1 μs yields roughly 909 times more time available for decoding; at 5 ms, roughly 4,545 times more (calculated by the editors).
This comparison comes with caveats. IonQ's figures are assumed values from the paper, not measurements from actual hardware. The error-correcting codes also differ—Google uses a surface code, while IonQ's design uses a quantum LDPC code—so the size of the problem to be solved per cycle is not equivalent between the two. Still, a time advantage exceeding 900-fold leaves substantial room for a general-purpose CPU to keep up.
The measured decoding times fall within this margin. The error decoder, which continuously outputs corrections, averaged 0.99–1.89 ms per window for the 102-logical-qubit circuits, staying under the 3 ms budget. For the 408-logical-qubit circuit, it averaged 3.51–5.97 ms against a 15 ms budget. The outcome decoder, which produces results of logical measurements, averaged 0.26–0.45 ms per cycle (against a 1 ms budget) and 0.79–0.96 ms (against a 5 ms budget). Each of these times includes both the on-the-fly generation of the decoding error model (DEM) and the beam-search decoding itself.
The use of the 12 cores was also divided by role. The paper allocated 4 cores to the outcome decoder and 8 cores to the error decoder—separating the process that outputs logical measurement results from the process that continuously produces error corrections onto different cores. The underlying Walking Cat architecture (arXiv:2604.19481, April 2026, 18 authors) is designed so that the shape of code blocks does not change during computation. The paper's simulation shows that combining this simplicity with the time margin afforded by slow cycles allows a general-purpose CPU to handle the entire computation.
The decoding method employed also has a precursor. The beam-search decoder is a technique published by Ye, Wecker, and Delfosse in PRX Quantum 7, 033002 (2026); XenoSpectrum reported in January 2026 that the company's results showed the technique reducing logical error rates by up to 17-fold compared to BP-OSD. This latest paper extends that decoder from a single code block to the entire computation.
Slow cycles also have a downside. Since each cycle is roughly 909 to 4,545 times longer than Willow's, the total execution time of a computation running the same number of cycles is correspondingly longer by the same factor. The reason a CPU can keep pace, and the reason ion-trap machines run slowly, stem from the very same numbers.
How this differs from real-hardware leaders Google, Riverlane, and Quantinuum
Real-time decoding itself is already running on multiple actual devices. Lining up the major published examples alongside IonQ's latest paper, using the same categories, yields the following:
| Case | Source of Error Data | Decoder Hardware | Target and Scale | Published Timing Metric |
|---|---|---|---|---|
| IonQ (arXiv:2608.25027, Aug 2026) | Simulation | Apple M4 Max, 12 cores | Up to 408 logical qubits, general-purpose circuits | Assumed 1–5 ms cycle |
| Google Willow (arXiv:2408.13687, published in Nature) | Real hardware | Real-time decoder connected to the device | Surface-code memory at distance 5, up to 1 million cycles | Average latency 63 μs, cycle 1.1 μs |
| Riverlane, Rigetti Ankaa-2 (Nature Communications, June 2026) | Real hardware | FPGA embedded in control system | 8-qubit stability experiment | Average 0.44–0.79 μs per round, 9.6 μs response time |
| IBM researchers (arXiv:2510.21600, Oct 2025) | Not specified in abstract | Relay-BP on FPGA | [[144,12,12]] gross-code memory | Average cycle under 1 μs (assuming circuit error rate under 3×10^-3) |
| Quantinuum Helios (announced March 2026) | Real hardware | BP-OSD on NVIDIA GPU | Bring code | Latency and logical qubit count not disclosed in public blog |
All prior real-time decoding examples from Google, Riverlane, and Quantinuum were conducted on actual hardware. However, their targets were memory operations or small-scale logical operations, whereas IonQ's latest result addresses general-purpose computation across hundreds of logical qubits—albeit without using real hardware. The decoder hardware also varies across CPU, FPGA, and GPU; Quantinuum connected an NVIDIA GPU to real hardware via CUDA-Q QEC and NVQLink.
The timing figures cannot be directly compared side by side. Google's 63 μs is an average decoding latency; Riverlane's 0.44–0.79 μs is per-round processing time, while its 9.6 μs is a response time—each measures something different. IonQ's 1–5 ms figures are also qualitatively different from measured values, representing time budgets assumed by the paper rather than actual measurements.
The paper frames its own contribution by first surveying prior work: while decoders for memory blocks and certain logical operations have been optimized, end-to-end real-time decoding for large-scale, general-purpose quantum computation had not yet been demonstrated. Read against this framing, IonQ's claim of "industry first" is limited specifically to real-time decoding of an entire general-purpose computation at the scale of hundreds of logical qubits using a single CPU. The examples in the table of real-time error correction actually run on hardware are limited to the three cases from Google, Riverlane, and Quantinuum.
Two limitations the paper itself acknowledges: can the stretch hold up with real hardware error data?
The paper itself acknowledges two limitations. First, for sufficiently difficult windows, decoding occasionally fails to converge. Second, to enable large-scale simulation, the initial preparation of magic states was replaced with stabilizer states. The paper explains this second point as a simplification intended to measure decoding load rather than output fidelity. In other words, what these figures measure is whether the decoder completes its work within the time budget—not whether the computation's results are correct.
The Quantum Insider noted that actual hardware can experience correlated noise and calibration drift. Error data generated from a noise model does not necessarily capture such disturbances. If error information from real hardware turns out to be more congested, the number of difficult windows could increase, potentially changing the stretch values shown in the table.
There is also a gap in the error-rate assumptions. An error rate of 0.01% corresponds to the 99.99% two-qubit gate fidelity IonQ reported in 2025. The paper treats this error rate as one already achieved on small-scale ion-trap devices; whether it can be sustained on a device with 11,680 physical qubits remains unshown. On September 8, IonQ announced its sixth-generation, 256-qubit device, Superion 256, with customer shipments planned for 2027. The press release positions this latest result as the foundation for a roadmap extending beyond 256 physical qubits—but this is the company's own outlook, and still differs by orders of magnitude from the scale assumed in the paper.
In the press release, Delfosse called the verification of real-time decoding across hundreds of logical qubits and millions of logical operations a milestone, stating that running on a single CPU offers a practical path toward commercial-scale fault-tolerant computation. John Gamble, VP of Architecture, added that directly verifying each component enables cost-effective scaling.
The next test will be whether error data drawn from actual ion-trap hardware—maintaining 1–5 ms cycles and error rates at the 0.01% level—produces stretch values within the paper's range when run through the same 12-core configuration. If that is demonstrated, the path to commercial scale that Delfosse describes will become something measurable outside of simulation.