Most explanations of quantum error correction end at the same place. You encode a logical qubit across many physical ones, you run parity checks with ancilla qubits, you detect errors without collapsing the state — and then the article stops, having implied that detection is correction.
It isn't. In our companion post on logical qubits and fault tolerance, we listed real-time decoding as one of four things a fault-tolerant machine needs, and then moved on. This post picks up that thread, because it is the requirement least likely to be explained anywhere else, and it has a property the others don't: it is not really a quantum problem at all. It is a classical computing problem sitting inside the quantum computer, and it is currently one of the harder ones.
What syndrome measurement actually gives you
The QEC basics post covers the mechanics of parity checks, so we won't re-derive them. The relevant point is what comes out.
A round of syndrome extraction hands you a list of bits. Each bit says whether one particular parity check agreed with its previous value or flipped. A flipped check means an error touched at least one of the qubits it monitors. That's it. You do not learn which qubit. You do not learn whether it was an X, Z, or Y error — see the Pauli operator breakdown for why those are the only cases that matter. You learn only that the parity structure has been violated somewhere in the neighbourhood of that check.
Worse, the measurement circuits are themselves noisy, so some flipped checks correspond to no data error at all — the check itself misfired. And errors that happen to straddle two checks flip both, while an error in the middle of a chain of errors may flip nothing, because two violations cancel.
So the syndrome is not a diagnosis. It is a constraint. The job is to find the most probable physical error consistent with that constraint, then apply (or, more often, simply record) the correction. That inference step is decoding, and it is a genuine combinatorial optimisation problem.
The part that makes it urgent
Here is where it stops being an interesting algorithms question and becomes an engineering crisis.
Syndrome extraction is not a one-off. It runs continuously, in rounds, for the entire duration of the computation. On superconducting hardware a round takes roughly a microsecond — Google's Willow experiments ran a cycle time of about 1.1 µs. Every one of those cycles emits a fresh syndrome frame from every logical qubit on the chip. For a machine of any interesting size, the syndrome data rate runs into millions of measurements per second.
Your decoder has to consume that stream at least as fast as it arrives. Not "reasonably fast." At least as fast, sustained, forever.
If it doesn't, you get the backlog problem, and the backlog problem does not degrade gracefully. Suppose your decoder processes each round 10% slower than rounds are produced. Undecoded frames pile up. The queue grows linearly in wall-clock time — which sounds survivable until you remember why you needed the decode result in the first place.
Certain operations in a fault-tolerant computation are conditional: what gate you apply next depends on the decoded outcome of measurements already taken. The canonical case is a non-Clifford gate implemented via magic state injection, where a correction is applied or not depending on a measurement result that must first be decoded. At each such branch point, the machine must stop and wait for the decoder to catch up to the present moment. But while it waits, more syndrome rounds are being produced — the qubits don't stop decohering just because the classical side is busy. So the wait itself extends the backlog, which lengthens the next wait, which extends the backlog further.
The result is an exponential slowdown. Each conditional operation takes longer than the last by a compounding factor, and the computation grinds to a halt long before it finishes. A decoder that is 10% too slow doesn't cost you 10%; it costs you the entire computation. The requirement is a hard throughput threshold, not a performance preference.
This is why the word "real-time" is load-bearing. Offline decoding — recording the syndrome stream and analysing it afterwards — is perfectly fine for a memory experiment, where you just want to know whether the stored state survived. It is useless for computation.
The decoder families, and their bargains
The decoding problem has a beautiful structure in the surface code, and a much uglier one elsewhere.
Minimum-weight perfect matching (MWPM). In the surface code, errors have a geometric signature: a chain of errors flips exactly the two checks at its endpoints. Syndrome violations therefore come in pairs, and finding the most likely error reduces to pairing up the flipped checks so that the total length of the connecting paths is minimised. That's a classic graph problem with a classic polynomial-time solution, Edmonds' blossom algorithm. MWPM has long been the accuracy benchmark for surface-code decoding — roughly a 0.94% threshold on weighted decoder graphs in commonly cited comparisons. Its problem is speed: polynomial time is not the same as fast enough, and the constant factors are unfriendly at microsecond deadlines.
Union-find. The pragmatic answer. Union-find grows clusters around syndrome violations until each cluster can be explained by an internal error, using disjoint-set data structures that run in almost-linear time. It's a fast approximation of what matching does — and the accuracy cost is real but modest, with reported thresholds around 0.83% weighted versus MWPM's 0.94%. That trade has made it the workhorse for hardware implementations, particularly FPGA ones.
Belief propagation plus ordered statistics (BP-OSD). This is what you reach for when the matching trick stops working, which is exactly what happens with quantum LDPC codes.
Why qLDPC decoding is genuinely harder
The surface code's decoding advantage comes from a property most codes don't share: each error chain flips precisely two checks, so the syndrome maps onto a matching problem. Take that away and you're back to general belief propagation over a Tanner graph — the same message-passing machinery used for classical LDPC codes in modern telecoms.
Except it works worse in the quantum case, for two structural reasons.
First, short cycles. Belief propagation assumes the graph is locally tree-like; the loops in quantum code Tanner graphs break that assumption and hurt convergence.
Second, and more fundamentally, degeneracy. In a quantum code, genuinely different physical error patterns can be equivalent — they differ by a stabilizer and therefore have identical syndromes and identical effects on the logical state. Classically, this doesn't happen; each syndrome points toward one most likely error. Quantum mechanically, belief propagation gets stuck oscillating between equally valid candidates it has no basis to choose between. It's not that the decoder can't find the answer — it's that there are several answers and the algorithm's tie-breaking machinery wasn't designed for that.
The standard fix is to bolt ordered statistics decoding onto the back: when BP fails to converge, OSD solves a linear system to pick a candidate. It works, and it costs you. Plain BP scales roughly linearly in code size; the OSD post-processing step is around O(N³). For a decoder on a microsecond budget, cubic scaling is precisely the wrong shape.
So qLDPC codes present the field with an awkward bargain: better codes, worse decoders.
Why anyone puts up with it
Because the encoding rate is dramatically better. Surface codes are extravagant — the logical qubit overhead runs to hundreds or thousands of physical qubits each, and the fault-tolerance estimates that produce headline figures of millions of physical qubits are mostly surface-code estimates. qLDPC codes, including the bivariate bicycle family, promise far more logical qubits per physical qubit. If that holds up, it moves the timeline for useful fault tolerance by a large margin. That is a prize worth accepting a harder decoding problem for.
This is where vendors have entered the picture, and where the claims need careful handling.
IonQ reports having developed a "Beam Search" decoder intended to replace BP-OSD for quantum LDPC codes. On bivariate bicycle codes, IonQ claims a 17x reduction in logical error rate relative to standard BP-OSD, along with a 26x reduction in worst-case (99.9th percentile) runtime, which IonQ states it brought under one millisecond on a single core of a commercial CPU. IonQ further estimates that three 32-core CPUs could suffice to decode 1,000 logical qubits in its trapped-ion architecture, contrasting that with roughly 1,000 FPGAs for surface-code approaches and 84 FPGAs for superconducting LDPC implementations.
Those are vendor-reported figures, measured under vendor-chosen conditions, on vendor-selected codes and noise models, and IonQ is a hardware company with a commercial interest in the conclusion that its architecture needs less classical support than its competitors'. The direction of the work is credible and the problem is real; the specific multipliers should be treated as claims pending independent reproduction, in the same way we'd treat any benchmark that hasn't been replicated by a disinterested party.
Why you can't just pick the fast decoder
The obvious response to a latency problem is to accept a worse answer faster. In decoding, that instinct can be fatal.
A less accurate decoder produces a higher logical error rate for the same physical error rate. And the logical error rate is exactly the quantity the threshold theorem is about. Google's 2024 below-threshold result — the first experimental demonstration that increasing code distance suppresses logical errors rather than amplifying them, descending from Kitaev's topological codes and ultimately Shor's original 1995 code — was a narrow win. Each distance increase roughly halved the error rate. A decoder that degrades logical fidelity enough can eat that margin entirely and put you back above threshold, at which point adding qubits makes things worse and the whole exercise inverts.
So the decoder isn't a peripheral. It sits inside the threshold calculation. You cannot report a threshold crossing without saying which decoder produced it, and a below-threshold result obtained with an offline MWPM decoder is a weaker claim than the same result obtained in real time. Notably, Google's experiment did decode in real time, reporting average decoder latency around 63 µs at distance 5 while sustaining below-threshold performance across up to a million cycles — using an ensemble of neural-network and matching approaches rather than a single clean algorithm.
Where the decoder physically lives
The last constraint is a plumbing one. Syndrome bits have to travel from the QPU to whatever computes on them, and the answer has to travel back, inside the error-correction cycle time.
That budget covers readout, digitisation, transmission over the classical link, the decode itself, and the return trip. On superconducting hardware the qubits sit in a dilution refrigerator and the classical processor generally doesn't, so the link crosses a temperature boundary. Implementations split roughly three ways: software decoders on CPUs or GPUs, which are flexible and easy to iterate on but carry OS-level latency jitter; FPGA decoders, which are the current sweet spot for real-time surface-code work; and ASICs, which are fastest but freeze your algorithm into silicon in a field where decoding algorithms are still actively improving.
Slower gate speeds change the maths considerably. Trapped-ion systems operate on microsecond-to-millisecond gate timescales rather than nanoseconds, which relaxes the per-round decoding deadline by orders of magnitude — part of why a sub-millisecond software decoder is a plausible proposition in that setting and not in a superconducting one. This is another place where modality differences drive architecture rather than being incidental, and it's visible in the hardware landscape if you know to look for it.
The honest state of things
Real-time decoding is not solved. It is an active, competitive, genuinely open engineering problem, and it scales in an uncomfortable direction: more logical qubits means more syndrome streams, and the classical side has to grow with the quantum side.
What makes it worth understanding is what it reveals about the shape of the machine. A fault-tolerant quantum computer is not a QPU with a control rack attached. It is a quantum processor and a substantial classical real-time computing system operating as one device, where the classical half's throughput is a hard constraint on whether the quantum half works at all. The decoder is not support equipment. It is part of the computer.
That framing also explains why progress here is slower to make headlines than qubit counts. There is no satisfying number to announce. But if you're tracking whether fault tolerance is actually arriving, decoder latency and accuracy under real-time conditions are among the more informative things to watch — more so than most of what appears in quantum news.
None of this is a reason to wait. The concepts underneath — noise, decoherence, what a qubit does under measurement — are the same ones you'd work with on a fault-tolerant machine, and you can build that intuition now on free simulators. The research library has the primary sources, syndrome decoding has the compact definition, and if you want to see what problems this infrastructure is ultimately being built for, the use cases page is the place to start.