IBM’s AI Agents Cut a Quantum Decoder’s Estimated Latency 52-Fold for $26 and 204-Fold for $299

October 13, 2026 – IBM Research reported that AI coding agents had optimized the hardware design of a quantum error-correction decoder for an estimated $26 in model inference. With GLM-5.3, an open-weight model from the Chinese developer Z.ai, running on IBM’s own GPUs, the agents cut the design’s estimated latency 52-fold.

When the team put Anthropic’s Claude Opus 5 in every role, the agents found a design 204 times faster than its starting point, at an estimated inference cost of $299. The all-open run cost 11.5 times less, but its best design was about four times slower, according to a preprint IBM posted with its blog announcement.

IBM presented the results as evidence that AI chip design can be made affordable with open models and efficient serving infrastructure. The paper’s corresponding authors are Abhishek Bhandwaldar and Ruchir Puri, an IBM Fellow and chief scientist of IBM Research, in a team of seven.

Their test case was a decoder for the [[144,12,12]] bivariate bicycle code, known as the gross code, which IBM researchers described in Nature in 2024. The decoder runs Relay-BP, an algorithm IBM published in June 2025 for the qLDPC codes on which the company has built its fault-tolerance roadmap.

A coordinator agent planned the search and assigned optimization hypotheses to four worker agents, in a setup IBM calls an agent factory. Each worker rewrote the decoder’s C++ kernel, and a verifier checked each candidate for correctness. The team then synthesized each candidate with AMD’s Vitis high-level synthesis (HLS) tool for an AMD VU19P field-programmable gate array (FPGA).

The coordinator used the synthesis results to choose each next round of hypotheses, over five rounds of 20. Puri described hardware optimization under this approach as “a coordinated cycle of exploration.” IBM first described agent factories in a March preprint, in which its researchers tested Claude-based agents on 12 standard HLS benchmark kernels.

The team compared three configurations under the same 100-hypothesis budget: Claude Opus 5 as coordinator and workers, GLM-5.3 in both roles, and an Opus coordinator directing GLM-5.3 workers. The unmodified decoder design had an estimated latency of 28,231 microseconds (µs).

Source: Bhandwaldar et al., IBM Research preprint posted October 13, 2026. Latencies are HLS estimates, and speedups are relative to the 28,231 µs reference design. Costs are estimates for model inference only. The all-GLM totals exclude one runaway worker execution.

The all-open agents used about 241 million tokens and the all-proprietary agents about 216 million. IBM priced the GLM-5.3 tokens at its estimated blended serving cost of $0.1077 per million, on 544 NVIDIA H100 GPUs that also serve other agent workloads. The team priced Opus tokens at Anthropic’s standard API rates.

IBM serves the open model with llm-d, an open-source inference framework developed by IBM Research, Red Hat and Google with other partners. The authors reported a 98% prefix-cache hit rate for the agent factory’s traffic with llm-d’s cache-aware routing, because the coordinator and its workers repeatedly reread the same design context.

When the team doubled the all-open budget to 200 hypotheses, the agents’ best design came in at 468 µs, 60 times faster than the starting point, with most of the gain inside the first 100 hypotheses. IBM said the all-open agents also produced the design with the smallest hardware area. In the paper’s latency-area plot, the all-Opus agents reached their lowest latencies with larger designs, while the hybrid and all-GLM agents found strong compact designs.

In an appendix, the authors gave an agent the architecture of IBM’s existing hand-written FPGA decoder, the C++ kernel and its testbench, and had it generate register-transfer level (RTL) code. The agent’s RTL decoded the 1,000 test syndromes in about 30,000 clock cycles, the same as the hand-written design, with similar logical error rates.

The agent’s version used about 80% more lookup tables, the FPGA’s basic logic elements. Its feasible clock period was 11.5 nanoseconds, against 10.5 for the hand-written design.

The authors wrote that each configuration ran once and cautioned against reading the results as a ranking of the models. IBM said in its blog that the costs cover model inference and exclude the other stages of the hardware development workflow. The team plans to try adaptive search budgets and selective use of stronger models, and to compare configurations at equal total spending on inference, synthesis and verification.

My Analysis

IBM’s team has shown that general-purpose AI agents can take a quantum decoder’s hardware design through dozens of verified rewrites for an estimated $26 to $299 in inference. By my arithmetic from the paper’s own numbers, the best of those designs is still more than 40 times slower on the paper’s test cases than the decoder IBM’s engineers wrote by hand. The authors don’t claim otherwise.

Engineers retune or redesign a decoder when the code, the measurement circuit or the noise model changes. IBM faces several such changes before Starling in 2029. Agents that make that work cheaper would help IBM’s engineers. I don’t expect fault-tolerant machines any sooner because of this paper.

What Relay-BP Does and Why It Runs on FPGAs

A quantum computer that corrects its errors measures parity checks across its qubits in every round. A classical decoder turns those measurements into corrections. It has to process measurements as fast as the processor produces them. It also has to answer quickly whenever the next operation depends on a decoded result. Because superconducting processors complete a round in about a microsecond, IBM’s decoder team designs its real-time decoders for FPGAs and, eventually, custom chips placed beside the control electronics. Decoder speed is one of the capabilities I track for fault-tolerant machines, under decoder performance.

Relay-BP builds on belief propagation, the message-passing method used to decode classical LDPC codes in 5G and satellite broadcasting. IBM’s researchers added memory terms so that it converges on quantum codes where plain belief propagation oscillates or stalls. In October 2025 a second IBM team described a hand-written FPGA decoder for the gross code on the same AMD VU19P the agents targeted, with a Relay-BP iteration time of 24 nanoseconds. As I noted in September, that team projects under 240 ns of decoding per 12-round window on average, for an academic circuit-noise model at error rates below 10⁻³.

Engineers write decoders like that one in RTL, the circuit description they use when every nanosecond counts. The agents worked a level above, in C++ that Vitis HLS converts into a circuit. Engineers who use HLS save design time and usually accept some loss of performance in return.

What the Agents Changed in the Decoder’s Code

IBM’s starting kernel stored the decoder’s graph in lookup tables, so the code read an index before each message access and used it as the address. Vitis HLS therefore could not tell which memory bank a read would hit. Only 3,672 to 4,320 of the 9,510 message slots it allocated were in use. The authors describe the result as a mostly serial walk through a sparse graph.

The agents rewrote that structure. In the all-Opus search, they moved the messages into a layout indexed by check and slot and split it across memory banks. Each check’s 35 reads could then run in parallel. They also replaced a reduction written as a run-time loop with a fixed tree the tool could unroll. With those two changes alone, a belief-propagation iteration took 14,824 cycles instead of 229,961, while the estimated clock period rose from 2.03 to 2.43 ns.

In the all-GLM search, the agents reached an 8.24× improvement in two consecutive hypotheses. In the second, they kept two copies of the messages in different layouts and added a pass to translate between the copies. With both copies, the design could read all six messages of an error mechanism at once.

The authors compared each measured variant with the original kernel and found almost no pragma-only changes, the synthesis directives HLS engineers usually adjust first. The all-Opus variants differed from the original by a median of 515 lines of code, the all-GLM variants by 428 and the hybrid’s by 197. The all-GLM agents had re-laid out the state arrays in 78 of their 80 measured variants, yet their best design was the slowest of the three. The hybrid’s GLM workers, under an Opus coordinator, made the smallest changes and reached 126× against the all-GLM search’s 52×.

By my arithmetic from the paper’s tables, verification in the hybrid run cost about $1.04 per million tokens, close to the all-Opus run’s $1.11 and almost ten times the GLM rate. I read that as Opus verifying the hybrid’s designs as well as coordinating its search. With one run per configuration and two roles changed at once, I take the hybrid result as weak evidence that the models choosing what to try and checking the results counted for more than how much code the workers rewrote.

The Speedups Are HLS Estimates on a Two-Round Problem

The paper’s results are HLS estimates, with no measurements on an FPGA. The team also judged which designs were feasible without applying a clock-period constraint.

The agents worked on a reduced version of the gross-code decoding problem. The authors give the full detector error model as an 864 × 8,785 matrix, then explain that they used a two-round model of 144 × 1,585 to keep the factory’s turnaround time manageable.

The authors define latency as average cycles multiplied by the clock period, without saying what they averaged. From the cycle counts in the paper’s Figure 1, I get about 2.9 milliseconds for the reference design at the 1,000-syndrome test set’s average of 6.09 belief-propagation iterations per decode. The authors report 28,231 µs. That matches, to the microsecond, the midpoint between the latency of a one-iteration decode and that of a 120-iteration decode, equivalent to about 60 iterations.

The authors note that fixed per-decode work accounts for a growing share of latency as iterations get faster. If they used the same midpoint for every design, as I expect from that match, the 204× and 52× apply to decodes of about 60 iterations, ten times the test set’s average. At the test set’s average, the speedups are likely smaller.

The authors don’t compare the agents with an experienced HLS engineer working on the same kernel. The agents’ 204× and 52× are gains over the unoptimized starting point.

Each configuration ran once, as the authors say. Agents make different choices each time, so the three configurations could finish in another order if the team repeated the experiment.

How the Agent Designs Compare With IBM’s Hand-Written Decoder

IBM didn’t mention the appendix in its blog post. In the appendix, the authors compare agent-written RTL with the hand-optimized RTL they credit to Thilo Maurer’s team, on 1,000 test cases. They don’t state the problem size, but they started the RTL work from the paper’s C++ Relay-BP kernel and testbench. The hand-written RTL decoded the 1,000 cases in about 30,000 cycles at 10.5 ns per cycle, roughly 0.3 µs per decode, against 2.9 ms for the unoptimized kernel at the test set’s average.

Under the paper’s own latency model, the best HLS design’s 139 µs at about 60 iterations means at least 14 µs per two-round decode at the test set’s average, even if the design had no fixed per-decode work at all. A superconducting processor produces those two rounds of syndrome data in about 2 µs. The floor is about 44 times the hand-written RTL’s 0.3 µs. With any fixed time per decode, the total exceeds 14 µs. The authors didn’t test throughput, parallel instances or feedback latency, and they don’t present the HLS designs as real-time candidates. They describe the HLS search as a way to explore architectures, with RTL agents implementing the chosen design points for custom chips.

For that flow, I give the RTL experiment more weight than the HLS numbers. Starting from the architecture Maurer’s team published, the agent produced RTL along with its own RTL testbench. The RTL passed every test case from the C++ testbench and matched the hand design’s cycle count.

It needed 503,000 lookup tables against 279,000. At its 11.5 ns clock period, the same cycle count takes about 10% longer. The authors don’t name the model that wrote the RTL, its inference cost or how many attempts it took, or say whether engineers stepped in. The architecture came from IBM’s engineers, and the agent implemented it.

What IBM’s $26 Inference Estimate Covers

Inference is the only cost in the paper’s tables. They include the tokens the agents spent on verification, but not the compute for Vitis HLS runs and testbenches, electronic design automation (EDA) licenses or engineers’ time. The authors say future comparisons should count synthesis and verification. The authors also left one worker execution, which they call a runaway, out of the all-GLM totals, and they don’t say how many tokens it consumed.

The two sides of the 11.5× ratio also come from different price lists. IBM priced the Opus tokens at Anthropic’s list prices for input, output and cache-read tokens, which work out to about $1.39 per million tokens across the run. For GLM it used its own estimated serving cost of $0.1077 per million tokens, on 544 H100s shared with other agent workloads, at a 98% prefix-cache hit rate.

In a September post, IBM’s llm-d team put self-hosting GLM-5.2 at 5 to 10 times cheaper per token than commercial APIs, at current cloud rental rates. In the agent factory the ratio is about 13 to 1. IBM’s per-token figure depends on keeping a large fleet busy with other workloads, so an organization with a smaller or less busy deployment can’t assume it.

For a single campaign the sums are small. The all-Opus run cost $273 more than the all-GLM run, for a best design about four times faster. If I were running a decoder program, I would start from the hybrid configuration, with its 126× design for $105. I would run it more than once before trusting any ranking. The savings from open models grow with volume, across the hundreds of campaigns that IBM says a full chip program could require.

GLM-5.3’s Developer and the US Entity List

IBM names neither model in its blog, and the authors don’t say who developed GLM-5.3. Z.ai, the Beijing company formerly known internationally as Zhipu AI, launched GLM-5.3 on August 14 and published its weights on Hugging Face about two weeks later. In January 2025 the US Commerce Department added Zhipu and nine related companies to its Entity List because, it said, they advance China’s military modernization through advanced AI research.

Under the listing, anyone exporting, reexporting or transferring items subject to US export regulations to those companies needs a license, with a presumption of denial. IBM’s team downloaded the published weights and served them on its own GPUs, so inference didn’t require sending prompts or design files to Z.ai. The authors give that control over design artifacts as a reason to choose open weights.

IBM’s team showed a model from a listed Chinese lab doing useful work on quantum hardware design, at the lowest cost of the three configurations. Many governments fund quantum hardware as national strategy, so their agencies will have to decide which models may write its code.

Decoder Redesigns Between Kookaburra and Starling

On its roadmap, IBM has scheduled Kookaburra, its first module built to store information in a qLDPC memory and process it with an attached logical processing unit, for 2026. Starling, planned to run 100 million gates on 200 logical qubits, follows in 2029.

A decoder’s problem changes along the way, because a detector error model depends on the code, the measurement circuit and its schedule, the noise model and the number of rounds. IBM’s FPGA team has already designed decoders for two codes, a [[56,2,10]] code for its Loon processor and the gross code.

IBM’s engineers could use an agent factory to explore a redesign each time the problem changes. On the two-round problem a campaign cost an estimated $26 to $299 in inference. The authors give no cost figure for the full problem. If agents can match a hand-written design’s cycle count on full-size problems, as one did in the appendix, they could also write much of the RTL once engineers have fixed an architecture.

In April I wrote that decoder performance might be the most consequential single capability for predicting when a cryptographically relevant quantum computer (CRQC) arrives. In September I moved it down, because physical qubit counts, error rates and the engineering of machines at scale had become the harder constraints. IBM’s team worked on the classical side and reported no progress on any of the three. My readiness rating for decoder performance is unchanged, since nobody on IBM’s team decoded syndromes from a quantum processor for this paper. My CRQC estimate is unchanged too.

What I would like to see next from IBM’s team:

• the same search on the full 864 × 8,785 gross-code problem
• the averaging behind the reported latencies, with each design’s latency at the test set’s average iteration count
• several independent runs of each configuration, enough to show how much the results vary
• a comparison with an HLS design optimized by an experienced engineer
• synthesis and verification costs, engineering time and any human intervention, reported with the inference estimate
• agent-written RTL for a full gross-code decoder, running on an FPGA against syndromes from a quantum processor

With the first five, readers could compare the paper’s numbers with other work. With the sixth, IBM’s team could show whether agents can shorten the decoder engineering between Kookaburra and Starling.

From the author