The Gross Code and the Grosser Question

 

Copyright: Sanjay Basu

Is IBM's error-correction breakthrough a reason to pick IBM? Not yet. It is a reason to change how you measure.

A post crossed my LinkedIn feed last week that I have now seen forwarded four times, each time with a version of the same note: "this is why we should standardize on IBM." The post itself is fine. It explains, correctly, that IBM's new family of error-correcting codes needs roughly a tenth of the physical qubits that the textbook approach needs. The forwarding note is where the trouble starts.

I have spent a good part of this year pricing out quantum capacity next to GPU capacity, and I have learned to be suspicious of any single ratio that claims to settle a platform decision. Ten times fewer qubits is a real result. Ten times cheaper useful computation is a different claim, and ten times better than every other way of building a quantum computer is a third claim that nobody has made except the people forwarding the post.

So this issue is an attempt to separate those three claims, put the right numbers next to each, and say what I would actually want to see before betting a data center floor on any one modality. I will try to be fair to IBM, because they have earned it. I will also try to be fair to the people who build qubits out of ions, atoms and photons, because they have been quietly doing things on real hardware that the forwarding crowd has not noticed.

What IBM actually showed

Start with the code, because the code is the whole argument. IBM's result belongs to a family called bivariate bicycle codes, which sit inside the broader class of quantum low-density parity-check codes, qLDPC for short. The specific instance everyone is talking about has the parameters [[144, 12, 12]].

Read that as: 144 data qubits, 12 logical qubits encoded in them, and a distance of 12, meaning it takes a dozen simultaneous errors to flip a logical value without anyone noticing. IBM's engineers call it the gross code because 144 is a gross. A dozen dozen. I appreciate a team that names things with a straight face.

In the implementation IBM published, those 144 data qubits are paired with another 144 qubits that do nothing but check for errors. So the working figure is 288 physical qubits for 12 logical qubits, or 24 to 1. IBM's own writeup says that protecting those 12 logical qubits for about a million rounds of checking would take close to 3,000 qubits under a surface code. That is where the "ten times" comes from, and it is honest arithmetic.

Two more pieces of the picture arrived this autumn and deserve credit. The experimental Loon processor, 112 qubits, now carries the long-range couplers that a qLDPC code needs to connect qubits that are not neighbors on the chip. And IBM demonstrated a real-time decoder for these codes that finishes in under 480 nanoseconds, roughly ten times faster than the previous approach and a year ahead of their own schedule. Decoding latency was one of the two things I expected to sink qLDPC in practice. It appears it will not.

Now the caveat, stated by IBM themselves and ignored by the forwarders: the tenfold overhead figure comes from circuit-level simulations of a quantum memory under specified physical error rates. It is not an experimental measurement of a full fault-tolerant computation. It is a very good model of a storage device.

Ten times smaller than what?

Every ratio has a denominator, and this one is the surface code running on a superconducting chip. That is a reasonable thing for IBM to compare against. It is what IBM would otherwise have built, and it is what Google has built. But it is a comparison inside one modality.

Here is the sentence I keep repeating in meetings: IBM found a way to make superconducting fault tolerance much more qubit-efficient. That sentence does not contain the words trapped ion, neutral atom or photon. The LinkedIn post does not contain them either. The forwarding notes somehow do.

When someone asks whether to prefer IBM over the commercially available alternatives, five separate questions are hiding in that one sentence:

1. Does the qLDPC code deliver its lower overhead at a comparable logical error rate once it leaves the simulator?
2. Can IBM build the long-range connectivity without the extra couplers introducing enough crosstalk and correlated error to give the gain back?
3. Does the advantage survive when the comparison is widened to ions, atoms and photons, which never had the connectivity problem in the first place?
4. Does fewer memory qubits mean cheaper computation, or only cheaper storage, once you account for logical gates and the non-Clifford operations that real algorithms need?
5. Does any of this change time to solution, cost per successful run, or how well the thing bolts onto a GPU cluster?

The post answers the first question with a strong yes from simulation. It gestures at the second. It does not touch the other three. Those are the ones a buyer cares about.

Connectivity is the real story

To see why the other modalities matter, you have to see what the gross code is actually buying.

A surface code is a checkerboard. Every qubit talks to its four nearest neighbors and nobody else. That is lovely for a chip designer, because wires on a chip like to be short, and it is terrible for efficiency, because a code that can only check locally has to spend a lot of qubits to achieve a given distance.

A qLDPC code loosens the rule. Each parity check still touches only a few qubits, but those qubits need not be adjacent. Let a check reach across the lattice and the code can pack twelve logical qubits where the checkerboard packed one. The price is that you now have to physically wire those long-range connections. On a superconducting chip, that means new couplers, more routing layers, and a new source of crosstalk. Loon exists to find out how bad that price is.

The drawing below is a cartoon, not the real parity-check graph of the gross code. It shows the idea: the left lattice is what a chip wants, the right lattice is what the code wants.

Notice what the right-hand picture is doing. It is forcing a chip that wants to be two-dimensional to behave as if it had more dimensions. Every other modality in this article starts from hardware that already has that freedom. Ions can be shuttled. Atoms can be picked up with optical tweezers and set down next to a new neighbor. Photons do not have neighbors at all. The question of whether IBM's advantage carries across modalities is really the question of whether engineering the connectivity in beats having it for free.

Helios, the inconvenient counterexample

If you want to test the "IBM is uniquely efficient" reading, you do not have to go far. Quantinuum's Helios is a 98-qubit trapped-ion machine with all-to-all connectivity, long coherence times, mid-circuit measurement and real-time classical control. It is commercially available today. I have run jobs on it.

On September 8 this year Quantinuum published results for its Helix code on Helios: a [[20, 2, 6]] concatenated code that uses 10 physical qubits per logical qubit. On October 19 they followed with a color-code experiment on the same machine that held a logical qubit at 99.9995% memory fidelity, five errors per million rounds. That configuration was heavier: up to 37 physical qubits per logical qubit at distance 5, and 73 at distance 7.

Two things to keep straight, because press coverage keeps blurring them. The 10 to 1 ratio and the 99.9995% fidelity come from different codes and different experiments. Do not add them together into one imaginary operating point. And the color-code result is a preprint as I write this, not yet peer reviewed.

With those cautions in place, look at what remains. Quantinuum ran two different code families on the same physical machine within six weeks, measured the trade between qubit overhead and error suppression, and published both. IBM's 24 to 1 figure is still a simulation of a planned architecture.

That does not make trapped ions better. The experiments measure different things, at different distances, on different workloads, and ion gates are slow in a way that will matter enormously once we talk about time to solution. What it does mean is that IBM's tenfold number cannot be used as a cross-platform ranking. On the single axis of physical qubits per logical qubit, a commercially available machine already beats it, on real hardware.

There is a deeper point here that I think is underappreciated. IBM is compensating for a hardware constraint with a cleverer code and more engineering. Quantinuum started with hardware that never had the constraint, which means they can try a new code without taping out a new chip. While the field is still arguing about which codes suit which applications, that agility has a value that does not show up in any qubit ratio.

The wrong unit of measurement

The post's implied economics go like this: a tenth of the qubits, so something like a tenth of the cost. I have built enough infrastructure budgets to flinch at that sentence.

The unit that matters is not qubits. It is what you pay for one successful answer. For a fault-tolerant job the simplest honest version is:

System cost per hour, times how long the job runs, divided by the probability it comes back right. Each of the three terms hides a fight. The hourly cost includes capital amortization, the dilution refrigerator or the laser bench, the control electronics, the maintenance contract, the power, the software stack and the classical decoding cluster. Fewer qubits shrinks some of those lines and leaves others untouched. The cryostat does not get cheaper because you put fewer qubits in it.

To make this concrete, take a reference system at 10 million dollars a year, cut its qubit-related costs by ten, and ask how much of the saving survives once you admit that some costs are fixed and that the new couplers and routing layers are not free. These are hypothetical numbers for illustration, not anyone's price list.

A tenfold qubit cut lands somewhere between a third and three quarters off the bill, and that is before the other two terms in the formula move. If the machine with fewer qubits runs slower, or fails more often per attempt, the denominator eats the numerator. A provider with more physical qubits but higher logical fidelity, more parallelism or faster gates can come out ahead on cost per correct answer. That is not a hypothetical. It is the Helios-versus-roadmap comparison in one sentence.

The field IBM is actually competing in

For readers who do not live in this world, here is the lineup as I would describe it to a product manager who has twenty minutes. Not every name on this list sells a general-purpose QPU you can log into tomorrow; access models and maturity vary a great deal.

IBM's genuine strengths sit in the first row: gates measured in tens of nanoseconds, a 300 mm fab in Albany, the most widely used software toolkit in the field, and a cloud service that has been taking jobs since 2016. If the qLDPC codes deliver high logical throughput at low system cost, that combination is formidable.

But look down the third column. Ions and atoms never had the connectivity problem the gross code solves. Photons distribute entanglement by a completely different mechanism. IBM is solving a hard problem brilliantly. Some of its competitors chose hardware where the problem does not arise.

What IBM still has to show

IBM's roadmap is public and specific, which I respect. Kookaburra in 2026 is meant to be the first module that both stores and processes encoded information. Starling in 2029 targets 200 logical qubits and 100 million gates, on the order of 10,000 physical qubits. Blue Jay in 2033 targets 2,000 logical qubits. These are dates on a slide, not results in a paper, and IBM says so.

If I were writing the acceptance criteria for a purchase committee, there would be six, and I would want evidence against each rather than a press release:

The second row is the one I would underline. The gross code is a memory. Useful algorithms are not memories; they are long sequences of gates, and the expensive ones are the non-Clifford gates, the T gates and Toffolis that give a quantum computer its edge over a classical one. Those are produced in magic-state factories, and in most resource estimates I have seen the factories, not the memory, dominate both qubit count and run time.

So here is the uncomfortable arithmetic. If IBM saves ten times on memory and the factories stay expensive, the saving on the whole computation might be two times, or less. If IBM also finds cheap logical gates on top of dense qLDPC memory, the approach becomes very attractive indeed. Nobody knows which yet, including IBM. That is the honest state of play, and it is why the five-questions list above does not collapse into one.

Three other benchmarks worth noting

Google. The Willow paper in Nature demonstrated below-threshold surface-code error correction: a distance-7 logical memory on 101 physical qubits with a logical error rate near 0.143% per cycle, and the error falling exponentially as the code grew. That is the experimental benchmark for superconducting error correction. It is also, interestingly, the baseline IBM's tenfold claim is measured against. IBM promises higher encoding efficiency; Google has shown error suppression working on a real chip. Those are different achievements, and neither alone gets you to a full logical computer.

QuEra and the neutral-atom camp. Atoms held in optical tweezers can be moved during a computation, which turns nonlocal gates from a wiring problem into a scheduling problem. Peer-reviewed work has shown the building blocks of universal fault tolerance on hundreds of atoms. The roadmaps project much larger logical machines; the systems you can rent today are mostly analog simulators, and the two should not be confused. For many-body physics and large simulations where geometry matters, atoms are the modality I would look at first.

PsiQuantum. A different thesis altogether: silicon photonics, fusion-based computation, optical interconnects, and a bet that semiconductor manufacturing solves scale. Their economics will be settled by photon loss, detector cost and resource-state generation, not by anything in IBM's paper. The gross code neither helps nor hurts that comparison. It simply does not apply.

I include these because the forwarding notes implied a two-horse race between IBM and "everyone else doing surface codes." It is a six-horse race, and at least three of the horses are running on a different track.

Which platform for which job

People always ask me for a winner. I do not have one, and anyone who gives you one in November 2026 is selling something. What I do have is a working map of where I would start for a given class of problem, knowing that it will be wrong in eighteen months.

These are starting points for evaluation, not claims of demonstrated advantage. For chemistry, materials and biology in particular, I would refuse to name a single platform until I had run representative Hamiltonians through each candidate and compared circuit depth, measurement budget, sensitivity to error and total cost per converged result. The answer will differ by molecule. It may differ by basis set.

Build the cloud so the question does not matter

Here is where I land as an architect rather than a spectator. If you are integrating QPUs into a GPU and HPC estate, separate two decisions that the forwarding notes have fused: which quantum hardware to buy, and how to orchestrate quantum work. The second decision should be made in a way that makes the first one reversible.

The shape I keep coming back to is a modality-agnostic stack. Applications at the top. A workflow orchestrator underneath that knows about schedulers, resource estimators and a heterogeneous programming model such as CUDA-Q. Below that, three peers: GPU simulation, a QPU gateway that speaks each provider's API through an adapter, and an error-correction service for the decoding that can run off the box. Then the providers themselves, interchangeable at the bottom.

The benefit is that nothing above the gateway depends on IBM's roadmap, or Quantinuum's, or anyone's error-correction strategy. CUDA-Q can carry a good part of the heterogeneous programming model today. Provider-specific compilation, logical instruction sets and calibration live behind the adapters. One caution from experience: "supports CUDA-Q" means different things at different vendors. Validate it with a real job before you draw the box.

Then make the vendors compete on the same test. I would ask IBM, Quantinuum and a neutral-atom provider to run an identical benchmark suite rather than scoring their headline metrics against each other. The suite: a logical-memory test, logical two-qubit operations, a non-Clifford-heavy circuit, a small chemistry simulation and one hybrid quantum-classical workflow. Record success probability, circuit duration, queue time, classical overhead and total cost. Then weight the results:

You can argue with my weights. Please do. The point is that "physical qubits per logical qubit" does not appear in the table, because it is an input to several rows and the answer to none.

Four questions I would fund

If a graduate student or a well-staffed lab asked me where the open problems are, I would hand them this list. Each one turns a slogan into a measurement.

1. Does qLDPC efficiency survive universal computation? Take the gross-code memory and add everything a real algorithm needs: lattice surgery or its equivalent, magic-state factories, logical routing, decoder load. Compare the total against a surface-code implementation and a trapped-ion one at the same logical error target.
2. Does hardware connectivity change the best code? All-to-all ions, rearrangeable atoms and photonic interconnects may admit higher-rate codes without any of IBM's coupler engineering. Nobody has done that comparison cleanly.
3. Which modality minimizes spacetime cost? Physical qubits multiplied by wall-clock time, adjusted for success probability, utilization, energy and classical decoding. Run it at several logical error targets, not one code distance.
4. Does any of it beat the GPUs? Measure scientifically meaningful results against the strongest classical baselines we have: tensor-network simulation, modern quantum-chemistry methods, classical optimizers on a few thousand H100-class accelerators. If the quantum answer is not cheaper or better per converged result, the modality argument is academic.

The fourth question is the one my GPU colleagues ask with a smile, and they are right to. A quantum data center has to justify itself against the classical data center next door, not against a surface code from 2014.

Three decisions, not one

So, back to the forwarding note. Should you standardize on IBM because of the gross code? I would split the answer in three.

IBM is a strong candidate for future fault-tolerant infrastructure. The qLDPC strategy, the fast gates, the fab investment and a modular roadmap with named processors and dates add up to a coherent engineering thesis. The tenfold reduction in qubits is real in simulation and partly demonstrated in hardware. It is not yet a tenfold reduction in the cost of a useful answer, and IBM has never said it was.

Quantinuum is the compelling choice for logical-qubit work you want to do this year. Helios has produced measured logical fidelities and run more than one code family on real hardware. The open question is whether that translates into throughput and economics at scale, and whether slow ion gates stay tolerable once circuits get deep.

A commercial quantum cloud should stay modality-agnostic. Let superconducting, ion, atom and photonic machines compete on verified end-to-end workload results. Put the hardware specialization below a portable orchestration layer and keep your options open until the data closes them.

The LinkedIn post identified an important breakthrough in the economics of error correction. Its weakness, and more so the weakness of the people forwarding it, is treating a win against one baseline inside one modality as a general commercial verdict. The defensible conclusion is narrower and, I think, more interesting:

IBM may have found a way to make superconducting fault-tolerant quantum computing far more resource-efficient. Whether that makes IBM the cheapest place to get a correct answer is an open engineering question, and the right response is to build so that you can change your mind.

If anyone wants to turn that into real numbers, the next piece of work is clear enough: a side-by-side resource estimate for IBM Starling, Quantinuum Apollo and QuEra's next logical system on one common fault-tolerant chemistry workload, with demonstrated capability and roadmap promise kept in separate columns. That turns an architecture argument into an investment decision. I would happily help write it.

Until next time, keep your couplers short and your assumptions shorter.

---

My research agent (hand-built on NVIDIA DGX Spark) fetched these:

Sources

• IBM Research: the gross code and bivariate bicycle qLDPC codes (IBM's own explainer of the Nature paper)
• IEEE Spectrum: IBM's fault-tolerant roadmap, Loon, Kookaburra, Starling
• Quantum Computing Report: IBM's qLDPC architecture and the 10 to 14 times efficiency claim
• Converge Digest: IBM Loon, Nighthawk and the sub-480 ns qLDPC decoder
• Live Science: IBM Starling, 200 logical qubits on about 10,000 physical
• HPCwire: Quantinuum reports 99.9995% logical fidelity on Helios, Oct 19 2026
• The Quantum Insider: Helix at 10 to 1 versus color code at up to 37 to 1
• Quantum Computing Report: Quantinuum's Helix [[20,2,6]] architecture on Helios, Sept 2026
• PostQuantum: distance-by-distance color-code numbers from the Helios preprint
• Google Quantum AI, "Quantum error correction below the surface code threshold," Nature (2024)
• Bluvstein et al., fault-tolerant neutral-atom architecture work, Nature

The original LinkedIn post that prompted this issue is linked here. The cost-sensitivity figures in the economics section are my own illustrative model, not vendor data.