IonQ Shows a Single Laptop CPU Can Decode a Simulated 408-Logical-Qubit Trapped-Ion Computer in Real Time

September 22, 2026 – IonQ said on Tuesday that its researchers had run a real-time decoder for a simulated fault-tolerant trapped-ion quantum computer with up to 408 logical qubits on a single commercial processor, the Apple M4 Max in a 2024 MacBook Pro. The company announced the software as the industry’s first end-to-end real-time quantum error correction decoder to run on one standard CPU.

The work is described in a preprint by IonQ researchers Min Ye, Andrii Maksymov and Nicolas Delfosse, titled “Real-time decoder for a MegaQuOp quantum computer using a single CPU.” It was posted to arXiv on 25 August and revised on 3 September. It has not been peer reviewed.

A fault-tolerant quantum computer measures parity checks on groups of its qubits in repeated syndrome-extraction cycles, and a classical decoder uses the results to work out which errors occurred. The decoder has to process that data as fast as the hardware produces it. The authors wrote, citing a 2015 review by Barbara Terhal, that a decoder which falls behind builds a backlog that can slow the computation exponentially.

The team tested the decoder on three workloads compiled for IonQ’s Walking Cat architecture, a fault-tolerant design based on quantum low-density parity-check codes that IonQ researchers described in an April preprint. Memory blocks in these configurations use a [[70, 6, 9]] code that stores six logical qubits per block, and each T gate consumes a magic state produced in a factory built on a second code. The largest configuration had 68 memory blocks and 20 factories, which the paper says were formed from 11,680 physical qubits.

The workloads were a measurement-induced phase transition circuit, or MIPT, with 40 layers of random two-qubit gates that occupied 102 logical qubits after compilation, and a single sixth-order Trotter step of a disordered Heisenberg model at two sizes, 64 sites on 102 logical qubits and 266 sites on all 408. The authors compiled each random gate in the MIPT circuit into Clifford and T gates at an average cost of 538 T gates, which gave that circuit more than a million T gates.

The authors measured the cost of decoding delays as stretch: the extra syndrome-extraction cycles the machine executes because decoding finished after its time budget, divided by the cycles the same computation would need with an instantaneous decoder. They assumed a cycle time of 1 millisecond for the two 102-logical-qubit workloads, which they described as a long-term trapped-ion timescale. For the 408-logical-qubit workload they assumed 5 milliseconds, described as near-term.

The simulated two-qubit error rates ran from $10^{-4}$ to $5 \times 10^{-4}$, a range the authors wrote had been achieved on small trapped-ion devices. At $10^{-4}$, stretch stayed below 0.3% for all three workloads, and at $5 \times 10^{-4}$ it stayed below 12%. The timings included generating the decoder’s error model during the run and the memory contention of all decoding processes sharing the chip.

The system runs two sliding-window decoders on each code block’s syndrome stream, both based on the beam search decoder that Ye, Dave Wecker and Delfosse first posted in December 2025 and have since published in PRX Quantum. An error decoder runs continuously and keeps the record of corrections for the whole computation. A faster, less accurate outcome decoder runs only during logical measurements and has until the next cycle boundary to deliver each measurement decision. A late decision costs extra cycles.

Error decoders ran on eight of the processor’s 16 cores and outcome decoders on four. The authors wrote that the Walking Cat design let them reuse one fixed decoding graph for every window in the bulk of a computation, with logical measurements changing only the error probabilities supplied to the decoder. They also wrote that they had cut the decoder’s memory footprint by more than an order of magnitude against the original beam search code.

The syndrome data came from a circuit-level noise simulation, not from a quantum device. The authors did not simulate the factory that prepares cat states, writing that the decoder plays no role in it. The magic-state factories were simulated and decoded. To keep that simulation tractable, the authors replaced the physical magic state that seeds each factory with a stabilizer state. The simulation included the controller’s logical-control operations, which the authors left out of the decoder timings.

Delfosse, a co-author and IonQ’s quantum research lead, said in the release that validating real-time decoding at the scale of millions of logical operations, run across hundreds of logical qubits, was an important milestone. He said that running on a single CPU gave the company a practical route to commercial-scale fault tolerance. John Gamble, vice president at IonQ Architecture, said the company verifies each component directly so that scaling stays cost-effective.

The release described the largest benchmark as executing more than 31.5 million quantum operations and said that, under standard operational noise, the decoder added as little as 0.02% stretch. The paper’s first table lists 31,548,792 syndrome-extraction cycles, summed across all 88 code blocks, for that workload. IonQ said the result validated a core element of Walking Cat and laid groundwork for its roadmap beyond 256 physical qubits.

IonQ launched its Superion 256 platform on 8 September, with customer deliveries planned for 2027, and described the follow-on Superion 10K as its first hardware generation built to run Walking Cat. Chris Ballance, IonQ’s president of quantum computing, said at the time that the company expected Superion 10K to reach fault tolerance in a laboratory setting in 2027 and commercial availability in 2028.

The authors wrote that earlier work on real-time decoding had concentrated on error-corrected memories or small numbers of logical operations, citing among others the streaming decoding of a magic-state factory with 15 logical qubits by PsiQuantum researchers in 2023 and of random logical measurements across 100 surface-code logical qubits on networked FPGAs by Yale researchers in 2025.

My Analysis

The computer that kept pace with IonQ’s largest workload was a 2024 MacBook Pro. Twelve of its cores decoded 68 memory blocks holding 408 logical qubits, plus 20 magic-state factories, through 1.3 million logical measurements, and at a two-qubit error rate of $10^{-4}$ the decoding delays lengthened the schedule by 0.02%. My own capability page on decoder performance says that ordinary software on a CPU would be far too slow for this work. I wrote that line with superconducting machines in mind, where one error-correction cycle takes about a microsecond, and it was too broad even there. IonQ’s paper assumes an ion trap with cycles of 1 to 5 milliseconds, and most of this result follows from that difference and from one design decision IonQ made in April.

For IonQ’s own architecture, keeping pace with the decoding of a few hundred logical qubits now looks like a software task for one commodity processor. If the Walking Cat machine that IonQ plans to run fault-tolerantly in its lab in 2027 falls short, I would look for the cause in gate errors, ion transport and ion loss at thousands of ions before I looked at decoder throughput.

All of it ran against a simulated machine. None of the syndromes in this paper came from a real ion.

Why Millisecond Cycles Let a Laptop CPU Keep Up

A decoder’s time budget comes from the hardware clock. Google’s Willow processor completes a surface-code cycle every 1.1 microseconds. IBM’s decoder team has argued that at microsecond cycles, superconducting decoders must run on FPGAs or ASICs. IBM’s FPGA prototype of its Relay-BP decoder runs one belief-propagation iteration in 24 nanoseconds to stay under a microsecond per cycle on its gross code. Google’s AlphaQubit 2 paper puts the two targets side by side: about a microsecond per cycle for superconducting qubits and about a millisecond for trapped ions and neutral atoms.

IonQ’s decoder gets 1 to 5 milliseconds per cycle, between 900 and 4,500 times the budget of a decoder built for Willow. The same group had shown in December that the beam search decoder, running in software on a single core, could decode one cycle of the [[144, 12, 12]] bivariate bicycle code, IBM’s gross code, in under a millisecond at the 99.9th percentile and a physical error rate of $5 \times 10^{-4}$, and they estimated then that three 32-core CPUs could decode a trapped-ion machine with 1,000 logical qubits. The new paper decodes 408 logical qubits on twelve cores of a laptop chip.

IonQ tested its decoder against budgets tighter than its own hardware model. The April Walking Cat paper put the syndrome-extraction cycle of its candidate codes at about 6 milliseconds, 30 operation cycles of 200 microseconds each. In the new paper, the authors assumed 1 millisecond for the two 102-logical-qubit runs, six times faster than that projection. For the 408-logical-qubit run they assumed 5 milliseconds. They chose the longer cycle for the larger run to offset the four times as many blocks each core had to decode. Its lower stretch therefore does not show that decoding gets easier as the machine grows.

The slow clock that gives the decoder its budget also lengthens the schedule. By my arithmetic from the paper’s first table, which counts cycles at the lowest error rate tested, the MIPT schedule is about 1.13 million cycles deep, roughly 19 minutes of machine time at 1 millisecond per cycle, the 64-site Heisenberg step about 317,000 cycles, roughly 5 minutes, and the 266-site step about 358,500 cycles, roughly 30 minutes at 5 milliseconds. The April paper estimated that a full 100-site Heisenberg simulation to chemical accuracy, including every shot it needs, would take about a month on 10,000 physical qubits. The Heisenberg benchmarks here are single Trotter steps.

At a microsecond per cycle, multi-threaded software kept pace with a single distance-5 surface code on Willow, and IBM is building its qLDPC decoder on FPGAs. A trapped-ion decoder working to a millisecond cycle has about a thousand times as long to finish each cycle as a decoder working to a microsecond cycle. Each cycle of the schedule is also about a thousand times longer. An application’s run time then depends on its logical depth, its factory throughput and the repetitions it needs.

How Walking Cat Keeps the Decoding Graph Fixed

A decoder works from a detector error model. For every way the circuit can fail, the model lists the probability of that failure and the parity checks, called detectors, that it would trip. In architectures that compute with lattice surgery or code deformation, a logical operation merges code blocks with ancilla patches, and the structure of that model changes whenever an operation starts or ends. The authors cite IBM’s Tour de Gross and Iceberg Quantum’s Pinnacle architecture among designs of that kind.

In Walking Cat, memory blocks are never merged or reshaped. Clifford gates within a block are tracked in software, and a logical measurement is made by bringing a cat state to the block and measuring it between ordinary syndrome-extraction cycles. Ye and his co-authors found that each error mechanism a cat-state measurement introduces has a twin in the syndrome-extraction cycle that follows it, a mechanism that trips exactly the same detectors. Two independent mechanisms with the same signature can be treated as one variable whose probability is the chance that exactly one of them occurs: $p_{\text{comb}} = p_1(1-p_2) + p_2(1-p_1)$

The decoding graph therefore stays the same across successive windows, apart from the first and last windows of a run. The software updates the affected probabilities when the decoding window reaches a cat-state measurement and restores the ordinary values once the window has passed it. Without the twin property, a naive implementation would have to rebuild the decoder’s message-passing structure for each new pattern of logical measurements during a run, which the authors call prohibitively expensive. The method depends on measuring logical operators without deforming the code, so it does not carry over directly to architectures whose logical measurements merge or deform code blocks.

IonQ also split the decoding between two decoders with different accuracy targets. Some pairs of errors produce identical syndromes but differ in whether they flip a cat-state readout, so no decoder can distinguish them. The resulting error floor is suppressed by repeating the measurement. The paper says the outcome decoder, which returns each logical measurement result, targets correctable errors below about a tenth of that floor. The error decoder, which keeps the corrections for the whole computation, holds them below about a thousandth of that floor, according to the paper. The outcome decoder uses a beam width of 8 and a two-cycle window, the error decoder a beam width of 32 and a five-cycle window.

A late error decoder postpones its block’s next cat-state measurement. Because every block runs on the same cycle clock, the whole machine runs extra cycles until the backlog clears. A late outcome decoder adds cycles to a measurement already under way.

What the Paper Measured, and What It Left Out

Ye, Maksymov and Delfosse generated each block’s syndrome stream from a circuit-level noise model and timed the decoders on the M4 Max. Every overrun was charged to the schedule as extra cycles. The timings include generating the error model on the fly and the cache and memory-bandwidth contention of twelve decoding processes sharing one chip, which are costs a real deployment would pay.

The stretch figures are totals over the run. The paper’s tables also give the tails: in the 408-logical-qubit run at an error rate of $10^{-4}$, where total stretch was 0.02%, the 99.9th-percentile stall lasted 32 cycles, 160 milliseconds at the 5-millisecond clock. At $4 \times 10^{-4}$, with total stretch at 0.39%, it lasted 252 cycles, about 1.3 seconds.

No fault-tolerant trapped-ion computer running these workloads at this scale has been publicly demonstrated. The paper puts the largest configuration’s memory and factory blocks at 11,680 physical qubits. The count leaves out the cat-state factories, reservoirs and routing qubits the April paper includes in a full device’s total. The authors simulated those blocks at two-qubit error rates of $10^{-4}$ and above, the order IonQ has demonstrated on a pair of ions. Nothing in the paper runs against syndrome data from a device.

The authors report how fast the decoder ran, and not how often the simulated computations would have returned the right answer. The paper gives no logical error rates for the three workloads and no count of convergence failures, the rare windows in which the decoder does not converge and the computation must restart. The authors wrote that such failures stay rare while the computation’s total cycle count, summed across all blocks, remains well below the inverse of the logical error rate per cycle. That condition is set by the hardware as much as by the decoder.

The timed pipeline also stops at the decoder. The authors excluded from the timings the controller’s work in the simulation: updating the Clifford frame and looking up the physical form of each measured operator. The timings also leave out any transfer of syndrome bits from control electronics to the processor. On Willow, that transfer added about 10 microseconds, which would be small against a millisecond cycle.

The cat-state factory was not simulated, because the decoder plays no part in it. The magic-state factories were simulated and decoded with a stabilizer state in place of the physical magic state that seeds each one. The authors justify the substitution on the grounds that they were benchmarking the decoding workload. The factories’ output quality was therefore not under test. IonQ’s own designs assume a two-qubit error rate of $10^{-4}$, so the results at higher rates show how the decoder degrades under stress.

How the Result Compares With Earlier Real-Time Decoders

IonQ calls this the industry’s first end-to-end real-time decoder. The paper’s own claim is narrower: that nobody had demonstrated end-to-end real-time decoding of a universal quantum computation at scale. I compared the narrower claim with four other real-time decoding results, including the closest prior work the paper itself cites, and each of the four did something IonQ’s has not.

• Google’s Willow team decoded a distance-5 surface-code memory in real time on hardware, with an average latency of 63 microseconds over up to a million cycles of 1.1 microseconds each, as reported in Nature. That was a single logical qubit in storage, and the team had not yet fed corrections back into the circuit.
• Quantinuum and NVIDIA decoded Bring’s code, which stores eight logical qubits in 30 physical ones, in real time on the Helios trapped-ion system with a GPU. According to NVIDIA, the median decoding time was 67 microseconds, with feed-forward corrections applied over three rounds of error correction.
• IBM’s FPGA implementation of Relay-BP reached an average decoding time under a microsecond per cycle for simulated memory experiments on its [[144, 12, 12]] gross code, at circuit error rates below $3 \times 10^{-3}$. IBM’s test harness fed the FPGA synthetic syndrome streams.
• Yale researchers’ DECONET system decoded lattice-surgery operations across 100 distance-5 surface-code logical qubits in real time on five networked FPGAs, with an average latency of 2.40 microseconds, under a phenomenological noise model at a 0.1% error rate.

Google and Quantinuum decoded syndromes from real qubits. IBM and the DECONET team fed their FPGAs synthetic syndromes, and IonQ decoded simulated ones on a CPU. Of the five, IonQ’s run is the only one with magic-state factories and compiled application workloads in the loop, and it has the most logical qubits. Those comparisons support the paper’s narrower claim for this combination, in simulation, although five results cannot settle priority across the whole literature. Google and Quantinuum reached real qubits first.

Three Figures in IonQ’s Press Release, Checked Against the Paper

The paper is careful on all three of the following points, and the press release states each of them with less qualification.

The first is the operation count. The release describes the benchmark circuits as executing “more than 31.5 million individual quantum operations.” The figure is 31,548,792, the paper’s count of syndrome-extraction cycles summed over all 88 blocks for the 266-site Heisenberg workload. A cycle is one round of parity checks on one block and involves many physical gates. John Preskill’s megaquop counts error-corrected operations. The paper counts those separately, listing 555,130 T gates and 1,318,310 logical measurements for that workload. The MIPT circuit, with 1,087,434 T gates, is the only workload above a million T gates. Quantum Zeitgeist put the 31.5 million figure in its headline the same day.

The second is the 0.02% stretch that the release attaches to standard operational noise. It is the smallest of the fifteen stretch values in the paper, from the 408-logical-qubit run with the 5-millisecond budget at an error rate of $10^{-4}$. The same error rate with the 1-millisecond budget gave 0.18% and 0.24%. IonQ’s record two-qubit gate, measured on a pair of ions in October 2025, had a fidelity above 99.99%, an error rate just under $10^{-4}$, and the paper itself describes its tested range as achieved on small trapped-ion devices.

The third is the statement that the result confirms classical hardware overhead need not grow exponentially as quantum systems scale. I don’t know of a serious argument that decoding hardware grows exponentially with qubit count. The exponential risk the paper cites is a slowdown in time when a decoder falls behind. The provisioning rule the authors suggest is that decoding compute grows with the number of code blocks assigned to each core, which is linear.

The paper contains the results behind the first two and the provisioning rule behind the third, each stated more narrowly than in the release. Delfosse’s own quote in the release stays close to what the paper shows.

What the Result Changes in My Decoder Capability Assessment

Decoder performance is capability D.2 in my CRQC Quantum Capability Framework. My last assessment, from November 2025, put it around technology readiness level 5: decoders proven fast enough on small codes, with scale, concurrency and duration still open. The IonQ paper adds no result integrated with a quantum processor, so the rating stays where it was. Ye, Maksymov and Delfosse have answered the concurrency question for slow-clock machines, in simulation, with 88 blocks decoded at once while factories and logical operations run, where IonQ’s April paper decoded one block at a time. My page’s line about CPUs also needs a clock speed and a code size attached to it, since Google decoded Willow’s distance-5 memory in software, and I will update it.

Two weeks ago, reviewing IonQ’s secp256k1 resource estimate, I listed a decoder keeping pace across every block at once among the results I would watch for. In that design, 69 memory blocks of the larger [[102, 22, 9]] code must be decoded without interruption for 25.7 days per attempt. This paper supplies the concurrency in simulation, for the smaller [[70, 6, 9]] code and for runs equivalent, by my arithmetic, to 5 to 30 minutes of machine time. The secp256k1 design differs in more than code size: it runs on a modified Walking Cat device with CCZ-state factories in place of this paper’s T-state factories, a new loss-correction protocol and its own measurement schedule. Its run is also about 1,200 times longer, which is a question of continuous operation, capability D.3, as much as of decoding.

The nearest date on IonQ’s roadmap is 2027, when Ballance has said Superion 10K should reach fault tolerance in the company’s lab. The paper does not map its configurations onto that machine. It shows that, in simulation, twelve cores kept pace with 88 blocks at a 5-millisecond cycle, slightly faster than the roughly 6 milliseconds IonQ’s architecture paper projects, with four of the processor’s sixteen cores unused.

What IonQ Still Needs to Show

Five results would narrow the gap between this benchmark and a decoder running on IonQ hardware:

1. The decoder running against syndromes streamed from IonQ hardware, with the transfer from the control electronics and the controller’s own logic inside the measured time.
2. Logical error rates and convergence-failure counts for these same three workloads, so that speed and correctness can be read together.
3. Simulated runs of days, the length of IonQ’s own application estimates, reporting the longest stall and the convergence-failure rate at that duration.
4. The [[102, 22, 9]] code, which IonQ’s dense configuration and its secp256k1 design both use. In the April paper, a single block of that code had a mean decoding reaction time of 0.85 milliseconds, against 0.35 for the [[70, 6, 9]] code.
5. The real-time pipeline released as code. The original beam search decoder is on GitHub under a non-commercial licence, and the paper does not say whether the new stack will follow.

IonQ put its first cryo-CMOS test chips for Superion 10K on display at the New York Stock Exchange on 8 September. The decoding in this paper kept pace on a laptop against simulated ions. The 2027 test is whether it keeps pace when real ions, read out through control electronics like those chips, supply the syndromes.

The post appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.