IonQ's 0.02% Decoder Stretch Comes From Its Slowest Assumed Cycle
IonQ says its error-correction decoder adds as little as 0.02% to a computation while running on one laptop CPU. That figure comes from the only workload its preprint ran at a 5 ms cycle. Here is why cycle time decides the result, and which number to quote instead.
Why a decoder that falls behind stalls the whole machine
A slow decoder costs more than a fixed delay. Barbara Terhal's review in Reviews of Modern Physics sets out the backlog argument: if syndrome bits are generated faster than they are processed, a small initial backlog leads to an exponential slowdown over the computation (Terhal, RMP 87, 307).
The mechanism runs through the T gate. Its correction depends on the Pauli frame, so the machine waits for the decoder, and while it waits it generates more syndrome data the decoder must also clear. Terhal draws the distinction that matters for comparing results: a quantum memory never has to wait for the decoder, because its readout can be corrected after the fact. A computation with T gates does.
What the IonQ preprint actually ran
Min Ye, Andrii Maksymov and Nicolas Delfosse of IonQ posted the work as an arXiv preprint on 25 August 2026 and revised it on 3 September (arXiv:2608.25027). Two sliding-window beam search decoders share the stream: an error decoder with a 5-cycle window and a 3-cycle commit region, and a faster outcome decoder with a 2-cycle window used during logical measurements.
The hardware was 12 of the 16 cores of a 2024 Apple M4 Max in a MacBook Pro, eight assigned to the error decoder and four to the outcome decoder. No quantum hardware was involved. The authors simulate all three workloads with a circuit-level noise model on IonQ's walking-cat trapped-ion architecture, built from LDPC memory blocks of six logical qubits and magic-state factories, and replace the physical magic state with a stabilizer state so the circuits stay simulable.
Their metric is stretch: the extra syndrome-extraction cycles executed because decoding missed its budget, divided by the cycles a zero-latency decoder would need.
The 0.02% figure pairs the largest workload with the longest cycle
The preprint reports three workloads, and they were not run under the same timing assumption (arXiv:2608.25027, Tables 1 to 4):
| Workload | Logical qubits | Code blocks | Assumed cycle | Stretch at p = 1e-4 | Stretch at p = 5e-4 |
|---|---|---|---|---|---|
| MIPT | 102 | 22 | 1 ms | 0.24% | 11.53% |
| Heisenberg n64 | 102 | 22 | 1 ms | 0.18% | 10.25% |
| Heisenberg n266 | 408 | 88 | 5 ms | 0.02% | 0.72% |
Here p is the paper's p_CNOT, the two-qubit depolarizing error rate in its circuit-level noise model. The authors say the 5 ms cycle for the 408-qubit run compensates for the larger number of code blocks each core must handle, with the allocation held at 12 cores. They call 1 ms the representative long-term trapped-ion timescale and 5 ms the near-term one.
IonQ's announcement quotes "as little as 0.02%" (IonQ). That is the 408-qubit run with five times the per-cycle budget of the other two. At the long-term 1 ms cycle, the preprint tested 102 logical qubits and measured 0.18% to 0.24% stretch.
The same release describes "more than 31.5 million individual quantum operations". The preprint's Table 1 lists 31,548,792 total syndrome-extraction cycles summed over the 88 blocks of the 408-qubit workload, a count the authors define as schedule depth multiplied by the number of blocks. The workload's gate counts are 555,130 T gates and 1,318,310 logical measurements.
Physical error rate decides how often the decoder overruns
Raising p from 1e-4 to 5e-4 took MIPT stretch from 0.24% to 11.53%. The mean error-decoder time per window rose only from 0.99 ms to 1.89 ms against a 3 ms budget, but the 99.9th percentile rose from 3.32 ms to 13.68 ms. The tail, which overruns the budget, is what inserts stall cycles.
The authors also report rare convergence failures on hard windows, more likely for larger circuits or higher error rates, which force a restart and sit outside the stretch figure. The authors describe the noise range from 1e-4 to 5e-4 as achievable on small trapped-ion devices, so the 5e-4 column sits inside what they treat as realistic.
A 1.1 microsecond cycle is a different decoding problem
Google Quantum AI decoded a distance-5 surface code in real time on its 72-qubit Willow processor, with a 1.1 μs cycle and an average decoder latency of 63 ± 17 μs over up to a million cycles, while staying below threshold (Nature 638, 920). It used the sparse blossom matching algorithm on a specialized workstation fed over low-latency Ethernet.
Set beside each other, the per-cycle budgets differ by a factor of roughly 900: 1 ms in IonQ's long-term assumption against 1.1 μs on Willow. The IonQ preprint itself notes that FPGA, GPU, TPU and ASIC decoders target the microsecond latency requirements of superconducting machines. In the other direction, Willow's real-time result was one logical memory, the case Terhal shows never has to wait, while IonQ's simulated workloads include T gates whose corrections do.
Neither result carries over to the other platform. The earlier post on surface codes on IBM heavy-hex hardware covers the superconducting side, where cycle times sit in Willow's regime.
What to check before quoting a decoder benchmark
Before repeating a real-time decoding number, find three things in the paper:
- The cycle time assumed. A slower cycle buys the decoder time; IonQ's best figure used five times the budget of its other runs.
- Code blocks per core. Fixed cores with more blocks need more time per cycle, which is the trade the authors made explicit.
- The physical error rate. A fivefold rise in p moved stretch by more than an order of magnitude in this preprint.
For IonQ's result, the figure that survives all three is 0.18% to 0.24% stretch at a 1 ms cycle and p = 1e-4, on 102 simulated logical qubits, from an unreplicated preprint by the vendor's own researchers.
The decoder also builds its detector error model from an assumed noise model, so on real hardware that model has to track the device. Google's Willow team adapted its offline decoders to device noise for this reason, fine-tuning a neural network on processor data and optimizing the matching-graph weights (Nature 638, 920). SuperconducTED works on that question for IBM backends; read its calibration-drift approach before trusting a noise model a decoder will inherit.