At the height of the Cold War, one very specialized computer was so secret that the world didn’t know it existed. It ran its jobs up to 200 times as fast as any other computer of its time. It was the U.S. National Security Agency’s main cryptographic processor in operation from the time of the Cuban Missile Crisis in 1962 through the Vietnam War and on past the 1975 Helsinki Accords. The machine stopped running only when its moving parts finally gave out.

The Harvest computer mattered because of what it was as well as when it ran. For 14 years, it was the engine processing the NSA’s most sensitive intercepts at a time when signals intelligence was as close to a strategic weapon as anything short of a warhead.

Designed and built by IBM for the NSA, Harvest was one of the first machines designed to apply operations to enormous datasets rushing past, a precursor to the computers today that manage continuous video streams and security systems in real time. It was also one of the first machines built as an add-on—a specialized helper intended to do one job exceptionally well, bolted onto a general computer. Harvest’s modular design is like a 1960s version of today’s graphics chips that CPUs use to run intensive video-game and AI processing loads.

All that raw processing power meant that Harvest also needed nonstop rivers of data to run on. And that led to another pioneering achievement: the world’s first automated tape library that could robotically fetch any one of hundreds of large cassettes of magnetic tape from the machine’s racks.

Given Harvest’s unprecedented processing and storage capacity, the machine’s designers naturally needed to rethink how their system handled information. So IBM wrote a customized programming language called Alpha to let code breakers rigorously describe cryptographic problems, just as scientists at the time were using the emerging language Fortran to describe equations and data-processing algorithms.

In Fort Meade, Md., an NSA data center hosted one of the world’s fastest computers of its time—although not often discussed, because of its sensitive, high-security code breaking and cipher hunting work. National Cryptologic Museum

The story of Harvest, pieced together from declassified documents and contemporary manuals and technical overviews, provides a new and unexpected vista on the history of computing. It also offers a case study in how national security needs, especially during the Cold War, pushed computer technology beyond the far reaches of what unclassified, civilian computing could achieve. Harvest’s distinctive history reveals a visionary algorithmic, coding, memory, and hardware architecture occasionally decades ahead of its time. But this machine was also built only once, for one singular purpose, and then ultimately quietly retired.

The Heart of NSA’s Secret Machine

IBM’s landmark 1960 transistorized mainframe, the IBM 7030, better known as Stretch, provided the front end for Harvest (which was officially known as the IBM 7950). IBM delivered Stretch to eight or nine customers, mostly scientific research labs, from 1961 through ’63. Designed and prototyped throughout the second half of the 1950s, Stretch introduced the now standard notion of an 8-bit byte. For its first three years of operation, Stretch was the non-classified world’s fastest computer, although it failed to meet IBM’s aggressive goal of running 100 times as fast as Stretch’s predecessor, the IBM 704. While IBM engineers in Poughkeepsie, N.Y., were designing and building Stretch, the company was also quietly discussing a new system that would be built for NSA.

At the time, NSA’s existing cryptanalytic computers—large, batch-processing machines that required human operators to manually stage each tape run—were struggling to keep pace with the sheer volume of intercepted message traffic coming in from around the globe. What the agency needed was a machine that could process an unbroken river of incoming data, automatically, around the clock. That requirement alone profoundly shaped Harvest’s design.

IBM’s Harvest system, custom-built for the NSA for code breaking, paired the IBM 7030 Stretch mainframe with a bespoke data-stream processor. Stretch handled ordinary computing and input/output, including the Tractor automated tape library. Both units shared two kinds of memory: a large main bank and a smaller, faster bank. When Stretch switched to streaming mode, Harvest drew two streams of data, P and Q, from memory, processed them in parallel, and returned the results as a third stream, called R. Chris Philpot

After two failed proposals to NSA, in 1958 IBM finally landed the contract: a Stretch-based machine, augmented by a custom coprocessor, with a revolutionary tape-based storage system, called Tractor.

Stretch’s forte was floating-point math for scientific computations. IBM had designed it primarily for labs working on frontier research like nuclear weapons design and weather prediction. By contrast, the custom coprocessor to be built atop Stretch would help NSA analysts sift through alphanumeric characters—that is, essentially integer data.

Harvest’s coprocessor was the opposite of a general-purpose system. It was, rather, a streaming computer. Instead of executing long series of instructions, it followed one fixed sequence of steps and applied that same sequence to every pair of characters as they streamed past. Harvest shared memory with the main Stretch processor and ran in bursts. Either Stretch was operating, or else it suspended itself while Harvest’s coprocessor shot through data in memory at extreme speeds.

Stretch and Harvest were among the first large computers built entirely from transistors packaged in circuit cards and housed in large, refrigerator-size frames. A 1962 technical manual about Stretch describes the machine’s CPU as divided into functional sections—the instruction unit, the look-ahead unit, the (parallel and serial) arithmetic unit, and the memory bus unit. Harvest inherited Stretch’s basic circuit design but then added something unconventional: Its streaming units processed data in overlapping stages called a pipeline. So while one pair of data bytes was being compared, the next pair was being fetched from memory.

Harvest’s coprocessor operated by fetching two streams of data, called P and Q, from the system’s memory, performing operations on them, then writing the results to memory as a third stream, R. Each stream could be anywhere from 1 to 8 bits wide. Harvest’s memory was bit-addressable, meaning word boundaries could be ignored entirely. For instance, it could fetch just 5 bits rather than filling out a whole byte. Streams P, Q, and R included flexible provisions for looping and addressing data in complex patterns—allowing, for example, repeated fetching of short strings from memory.

Data from P and Q fed into two functional units. The simpler was the logic unit, which performed basic, bitwise operations—the same operations any programmer would recognize today—and wrote its results back to memory. The more complex was a table-lookup unit. It combined incoming data from P and Q to form an address in memory, which could then be used to advance a counter by one, set a specific bit, or retrieve a stored value. The latter unit functioned, in effect, like the rotor wheel inside a cipher-encoding/decoding machine of the era, the kind that electronically substituted one value for another according to the cipher machine’s wiring.

Harvest’s complexity baffled some at the NSA. During employee tours, according to James Bamford’s 2001 NSA history, Body of Secrets (Doubleday), officials would point to the machine and scoff, “It’s beautiful, but it doesn’t work.”

Not everyone at the agency was put off by the monumental device, however. One of the few documented examples of Harvest at work, recounted by Bamford, describes the machine searching 3.5 billion characters of text for any of 7,000 target terms, in just under 4 hours.

In unclassified remarks from 1972, NSA analyst Robert Looney mentions one job Harvest had tackled—though he didn’t specify the end goal or the code-breaking effort behind it. Codenamed “Moretown,” the job involved sifting through 11 million messages spanning 16 years of intercepted traffic against a list of some 8,000 search terms—all in about ten hours.

IBM’s Frances Allen helped design Alpha, Harvest’s custom-built programming language.IBM

IBM’s James H. Pomerene was chief engineer of Harvest, supervising its custom-designed circuits that’d been optimized for algorithms used in many cryptographic jobs.IEEE

IBM’s Fred Brooks Jr. was a key co-architect of Harvest’s hardware system. Computer History Museum

As a unified system, Harvest—that is, Stretch plus IBM’s custom-built streaming processor add-on—streamed 1 byte every 0.3 microseconds, and it boasted about 800 kilobytes of addressable memory.

“Here you see one bank pulled out of its oil bath,” Looney said in his 1972 remarks celebrating Harvest’s tenth anniversary of operations. He held up a photo of Harvest’s magnetic core memory banks—six of them, submerged in oil for cooling.

Factor in the time demands of various data fetches from Tractor’s tape archives, and a single Harvest “instruction” sometimes carried on, without needing any human intervention, for hours.

“It was quite an amazing computer,” recalled IBM Fellow Emerita Frances Allen in a 2001 oral history. “One instruction, for example, could do sorts, and do statistical analysis of the data that was streaming by it.… Everything we were doing at that time was on the cutting edge. There was no question about it.”

Allen, who received the A.M. Turing Award in 2006, was one of the developers who worked on both Stretch and Harvest. At the time she started working on Harvest, Allen noted, the Fort Meade, Md.–based NSA was largely unknown outside of classified intelligence circles. So she at first assumed she was working on an unspecified naval project. “We thought of ourselves as working for the Bureau of Ships, because that was the code name for NSA in the budget!” recalled Allen, who died in 2020.

Other key Harvest designers and early developers wound up becoming influential figures over the course of computing history. Frederick Brooks Jr., recipient of the 1999 Turing Award and a major contributor to the hardware and software for IBM’s System/360, also helped develop Harvest. And James Pomerene, prior to his involvement with Harvest as its chief engineer, had previously helped build the pioneering IAS computer alongside John von Neumann.

How Tractor Stored a World of Data

IBM built the Tractor tape system (IBM 7955) to attach to the same Stretch machine that hosted Harvest, because no existing data storage technologies could keep up with the computer’s staggering throughput. Stretch handled the business of staging tapes from the library to the drives—using Tractor’s automated cassette handler. Stretch also coordinated reading data in from Tractor and writing results back out from Harvest. Harvest, in turn, did all its actual computing on the system’s shared main memory.

In the early 1960s, and even after Tractor and Harvest were installed, hard-drive data storage was in its infancy. For code-breaking jobs of the size Harvest was taking on, disk storage would have been impractical in terms of both cost and sheer floor space. So Tractor had to be based around tape storage.

Each tape was sealed inside a case built like a boombox—twin encased reels under a window, carried by a handle—and, at 6 to 7 kilograms, about as heavy as a bowling ball. Think of a Tractor cassette as an outsize predecessor of the audiocassette, which would come along a decade later, and holding some 120 megabytes of data on a reel of tape 550 meters long. Each storage unit housed up to 160 of these cassettes.

An IBM technician holds one of the data cassettes used with Harvest’s automated Tractor tape drives. IBM

When Harvest launched in 1962, it had three automatic cartridge units, each serving two drives. So the available online storage across the three Tractor units totaled a stunning 44 gigabytes. That’s more than 190 times as much capacity as the IBM 2314 disk storage system, announced in 1965, which held 233 megabytes across its full complement of eight drives.

Tractor had to run continuously, swapping cassettes in and out, 24 hours a day, seven days a week. The system’s tape-handling speed was tuned to keep pace with Harvest’s own appetite for data. The custom-built robotic mechanism for retrieving the cassettes was a servo-driven arm that traversed the system’s storage racks. It fetched a cassette from its slot and delivered it to a handler or received a cassette from one of the handlers and returned it to storage.

Running at 6 meters per second, Tractor’s tapes zipped past the read/write heads faster than the eye could track. Software running on Stretch handled the cassette shuttling as well as reading and writing. For one of Tractor’s drives to move from the completion of processing one tape to reading the next took about 18 seconds, assuming it had already been fetched and was ready to mount. Robotically fetching a cassette from the storage unit and preparing it for reading required no human handling or input whatsoever.

In addition to Tractor, the system had standard reel-to-reel tape drives attached to Stretch. Harvest’s technicians often used the conventional drives for importing and exporting data to and from other systems; there was no other practical way to get large datasets into or out of Harvest. Tractor could also store permanent files and retrieve them directly from its tape libraries when a job required them. In other words, Tractor’s substantial cassette libraries acted both as permanent data storage and as a place to hold transient data for processing by Harvest.

No system in the commercial computing world of 1962 came close to Tractor’s gigabytes of simultaneously accessible data. At most computer centers at the time, “available” data meant physical racks of tape standing somewhere near its drives—accessible only as rapidly as an operator could manually pull a reel and thread it onto a machine, one at a time, over the course of a shift.

Alpha Was Harvest’s Custom-Built Programming Language

Created jointly by IBM and NSA, the Alpha language existed solely to program Harvest’s streaming dataflow engine for code-breaking work. According to a declassified Pentagon history of NSA computers, Alpha stood for Advanced Language for Programming Harvest.

Alpha allowed the programmer to define the alphabet in which code-breaking data would be processed. The language also included two unusual characters with no equivalent in conventional computing until years later, when Multics and Unix introduced wildcard characters. A “scab” (which was represented on Harvest’s input keyboard, a repurposed early IBM Selectric typewriter, by a “?”) stood for a character that was real but unknown. And a “pad” (represented by a blank space) was a null or spacer. These characters provided flexibility of representation for code breaking jobs, in which unknown or uncertain characters were commonplace.

A Harvest operator types on one of the main system consoles, a repurposed IBM Selectric typewriter.IBM

The rules governing Alpha’s operations on strings anticipated other modern rubrics, like “not a number”—a designation describing an unknown value in a dataset that can propagate through calculations, rather than silently corrupting them. Strings in Alpha could also be aggregated into cords, and cords into ropes, giving cryptanalysts a hierarchical vocabulary for describing complex intercepts.

Allen wrote a final technical report on her section of the Harvest software when her part of the project concluded—and just as promptly lost access to it. “I spent the good part of a summer on that,” she recalled in 2001. “And it just disappeared into Fort Meade somewhere.”

Replacing an Irreplaceable Machine

By 1971, according to NSA analyst Looney, the machine was running at its highest utilization ever—115 hours of production a week, or more than two-thirds of the time. Yet the number of jobs it processed had been dropping since 1967. Ordinary data-processing work, Looney noted, was by 1972 migrating to newer, general-purpose machines, leaving Harvest to concentrate on the very large, specialized jobs no other system could handle.

At its tenth anniversary of operations, Looney concluded, Harvest was a machine “conceived in the fifties, born in the sixties, and irreplaceable in the seventies.”

He got the last part wrong.

On 27 February 1976, operators shut down Harvest for the last time. A custom mechanical component in the Tractor tape library had worn out, and the manufacturer of the part was no longer in business. By then Harvest had run continuously for nearly a decade and a half—through the roughest close call in the history of mutually assured destruction and into the age of détente—processing intercepts at a rate no civilian machine could touch. By the time it retired, Harvest had outlived several generations of commercial computing.

A placard commemorates the 1976 decommissioning of IBM’s Harvest computer at the NSA’s headquarters in Fort Meade, Md. National Cryptologic Museum

Somebody at the NSA decided to commemorate the machine with a mock telegram, written under Harvest’s name on the machine’s last day (and now preserved in the agency’s archives). “I first began operations at NSA. Although not widely known, I was probably the largest, fastest, and most technically advanced computer system in the world,” the telegram said. “And now, fourteen years later, the time to retire has come. The cost of my upkeep and operation has been overtaken by more modern equipments and the newer technologies.”

The NSA ultimately replaced Harvest with the landmark Cray-1 supercomputer. The Cray-1 was built from faster, more tightly integrated circuits that could outperform Harvest’s aging transistors at nearly any task, including text processing. Although the Cray was designed primarily for numeric and scientific computing, it sold across many fields—which ultimately made the supercomputer win out once Harvest’s custom-built text-processing hardware was no longer worth the upkeep for just one customer.

The secrecy that shrouded Harvest meant it could claim no lineage of immediate successors. But the ideas it pioneered didn’t disappear—they resurfaced, again and again, in the years that followed.

Tractor’s automated tape library was the forerunner of the robotic storage silos that would become standard in enterprise data centers about 20 years later. Harvest’s pipeline architecture prefigured the dataflow computing movement of the 1980s. The continuous pattern-detecting logic of its match units finds direct echoes in modern hardware packet-inspection intrusion detectors and programmable network switches that today route traffic through the internet at wire speed.

Harvest didn’t found a dynasty. But, in its time, it steadfastly pointed toward the future—in several directions at once.

This article appears in the September 2026 print issue as “The Lost History of IBM’s Cold-War Code Breaker.”

How do I touch you
across the ocean,
across cold depths
where light travels through glass.

Not copper—fibers. Optical.

Through liquid glass, through flickering light
that carries you in fragments. Light broken into pulses.

You say: it’s easier this way. What are we missing like this? You smile.
Safe distance.

I say: network.

Signals slide beneath the sea, through cables thinner than trust, faster than touch,
slower than longing.

We stand alone, together. Synchronous, yet apart. Icons replace skin, latency replaces breath.

This distance protects us. Silence that feels intentional.

Everything is under control as long as nothing truly hurts.

And we choose it
because it shields us
from what we might become if we actually met.

You are my counterpoint. My response.
My reflection
at a safe distance.

Beneath the ocean, nodes remember paths.

Packets shake hands without bodies.

If we get lost,
we resend everything, with error,
with noise,
with hope.

The impact of AI on software development has been both profound and ever-evolving. Last year, I wrote about AMD’s plans to use AI not just for generating new lines of code, but also for other steps in the software development lifecycle (SDLC), such as triaging problems, debugging code, and testing the software. At the time, we were hoping for a 25 percent productivity boost from AI use over the course of two or three years.

But with each new release, the capabilities of large language models (LLMs) improve dramatically—accelerating software development, increasing the quality of AI-generated code, and fundamentally reshaping how software is engineered. Now, just one year later, we have surpassed our productivity target, achieving a 30 percent overall productivity boost through AI. On top of that, we are rethinking not only how we use AI within the SDLC, but the structure of the SDLC itself.

We believe that the biggest AI revolution in software engineering is still ahead. So far, we have largely been teaching AI how we perform tasks and asking it to mimic existing workflows. In many ways, this constrains AI to human patterns of thinking. The next transformation will come from collaborative swarms of AI agents capable of discovering solutions independently.

Agents of today

AMD began developing AI systems for code generation, testing automation, bug analysis, and code review in 2024. At the time, our objective was to achieve 25 percent AI-generated production code by 2027 while gradually automating larger portions of the SDLC.

Measuring productivity is inherently challenging, but from the outset we have consistently tracked one objective metric: the percentage of source code generated by AI. Importantly, we count only code that passes all reviews and testing and is ultimately included in the final product. While AI-generated code is certainly not the only contributor to productivity gains, it is one of the few metrics that can be measured objectively and consistently.

By this metric, we have crossed the 20 percent mark at the beginning of this year and are now progressing towards 50 percent across entire codebase. In some software components, more than 80 percent of the code is now generated using AI.

Agentic AI has enabled us to include AI in every step of the life cycle: For code analysis and triage, agents are trained to analyze problem reports, identify and group similar requests, and highlight which code snippets are likely to need modification. For debugging and code generation, agents are directed to analyze a bug request and implement required code changes. For testing, the agents generate unit tests, and if those are passed, identify necessary integration and product-level tests. And finally, for the approval and release stage, agents prepare architecture summary, code change review, and full test results for engineers’ review and approval—and, if approved, integrate the changes into the next release.

Agents of tomorrow

Today, engineers create AI agents in their own image: They teach AI what they know about the system, how they would fix an issue, and how they would implement a change. This is already a major technological advancement. Engineers can create multiple “AI versions” of themselves, allowing these agents to work in parallel, scaling their expertise far beyond the limits of individual productivity. The limitation, however, is that these AI agents are still constrained by human thinking and human-defined approaches.

AMD

We believe the next major transformation in software engineering will occur when collaborative AI agent swarms can independently identify and develop solutions, guided by humans on what to solve rather than constrained by human assumptions about how the job should be done. Instead of providing detailed instructions on how to solve a problem, engineers will define the issue, the desired outcome, and the quality, performance, and system constraints, allowing AI agents to determine the optimal path to a solution.

A swarm of AI agents will then work in parallel to generate, evaluate, and refine multiple solution approaches. These agents will automatically validate correctness, measure performance, test trade-offs, and compare alternative implementations against defined success criteria. Finally, AI agents will prepare ranked solution options, along with validation results and performance metrics, for engineer review and approval. The agents won’t be enhancing each step of the SDLC—they will be rewriting the SDLC themselves.

To get to this point, we need to change how agents are trained. Today, improvement occurs one engineer and one agent at a time: An engineer reviews the output, refines the prompt, and repeats the process. To scale beyond this model, agents must continuously learn from one another, reuse successful strategies, and improve collaboratively across projects and teams.

We are already moving in this direction by using multi-agent workflows extensively through agentic harnesses, such as Codex and Claude Code, while simultaneously developing our own internal multi-agent systems to support the next generation of AI-driven software engineering.

A good example is our AI-driven effort to resolve issues in our Radeon Software eXperience (RSX). RSX is a user interface component that allows users to configure and monitor graphics driver behavior. In October 2025, we began using AI agents to automatically debug and fix reported RSX issues. Out-of-the-box AI tools delivered limited results, resolving only 6 percent of issues.

The percentage of software issues fixed automatically by AI agents in AMD’s Radeon Software eXperience (RSX) has been growing steadily, reaching 75 percent in June 2026.

As we analyzed failures and identified ways to improve, we built a learning loop—initially a largely manual process—to understand where the agents were falling short and how to improve them. Rather than retraining the underlying models, we refined the objectives given to the agents, allowing them to iteratively explore multiple approaches, evaluate the results against defined success criteria, and converge on better solutions. At the same time, advances in models and agent run-times further increased effectiveness. Together, these improvements significantly increased our resolution rate from 6 percent to more than 75 percent of RSX issues resolved by agentic loop.

To make agents and agent swarms truly productive, we need a continuous learning loop that feeds errors and human interventions back into future agent workflows. The opportunity is to engineer this loop around clear, measurable goals. Each cycle captures new insights, making the entire AI engineering workflow smarter and more effective. Over time, this self-reinforcing loop—not just the underlying model—will become a key driver of AI progress.

The evolving role of human engineers

At AMD, we view AI as a means of increasing productivity, improving quality, and enabling employees to focus on higher-value work. Our goal is to empower our workforce with AI, not to reduce headcount.

To support this transformation, we are investing heavily in AI education and training across the company. The way we work is evolving rapidly, and we want every AMD employee to be prepared to leverage AI confidently, responsibly, and effectively.

As AI agents continue to improve, engineers will spend less time manually implementing solutions, focusing more on defining specifications, validating outcomes, and making the strategic decisions that drive innovation.

Representing a significant milestone in AI-assisted mathematical research, a team at Axiom Math has automatically verified the proof of a theorem relating to prime numbers—colloquially referred to as the “246 theorem”—for the first time using the company’s AI system AxiomProver.

In formal verification, mathematicians task a computer with checking a machine-readable version of a proof. The process is not a 100 percent guarantee that the proof is correct, as a recent demonstration showed, exposing how a bug in the method could be exploited to accept a false, AI-generated proof. Still, the computational method is as close to a rubber stamp as you can get.

This particular verification formalizes an important advance in number theory. Beyond this particular proof, it demonstrates how automated AI verification could be used in the future to ensure the correctness of AI-generated computer code that will soon underlie software across the globe.

Useful formalization by design

This is not AxiomProver’s first rodeo. Axiom Math has used its autonomous, multi-agent system that turns mathematical statements into machine-checkable proofs to crack several unsolved mathematical problems and verify many more proofs this year. But proof formalization of the 246 theorem is by far the most significant, as Ken Ono, Axiom Math’s founding mathematician, explains: “This theorem currently represents the threshold of human knowledge about prime numbers.”

Earlier this year, Axiom Math competitor Math, Inc. used its Gauss agent to verify Maryna Viazovska’s 2022 Fields Medal-winning proof of the sphere-packing problem in 8 and 24 dimensions. Sidharth Hariharan, a Ph.D. student at Carnegie Mellon University who led human efforts that were critical in the Math, Inc. breakthrough, says that Axiom Math’s AI approach to formalizing the 246 theorem is more comprehensive and useful. Hariharan’s group continues to work toward fully formalizing Viazovska’s proof.

RELATED: Watershed Moment for AI-Human Collaboration in Math

Now an intern at Axiom Math, Hariharan has been heavily involved in the company’s formalization of the 246 theorem proof. He says that one of the main differences here is that rather than it being a one-shot approach relating to a single problem, Axiom Math has expressly aimed to make components of the formalization reusable for other formalization tasks and mathematical research. The team has wielded AxiomProver to build a library of results about gaps in primes. The 246 theorem is the flagship result within that library.

What is the 246 theorem?

The first few primes are close together: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, .... And there are several instances where they are separated by a difference of two: 3:5, 5:7, 11:13, 17:19, ....

These pairs of primes are called twin primes. Twin primes become rarer the further you get from zero, but they do still seem to pop up occasionally. The twin prime conjecture, first precisely formulated in the 19th century by French mathematician Alphonse de Polignac, posits that they will keep popping up regardless of how far along the number line you look. In other words, there are infinitely many twin primes.

Though easy to state, the venerable twin prime conjecture remains unproven. First progress toward solving it only occurred in 2013 when Yitang Zhang, now a professor at Sun Yat-sen University, in Guangzhou, China, proved that there are infinitely many pairs of primes that are separated by 70 million. A few months later, using a different technique, University of Oxford professor James Maynard dramatically reduced this gap from 70 million to just 600; a feat which substantially contributed to Maynard being awarded the 2022 Fields Medal—widely regarded as the Nobel Prize for mathematics.

As part of a group of mathematicians known as the Polymath8b collaboration, Maynard and fellow Fields Medalist Terence Tao, professor at the University of California, Los Angeles, brought the gap down to just 246, the closest mathematicians have gotten to the target gap of two. It is this 246 theorem—which states that there are infinitely many primes that differ by 246—that AxiomProver has verified to be correct.

Safe and correct AI-generated code

The techniques formalized in this work are important in number theory, the branch of mathematics that underpins all present-day cybersecurity and cryptography. They could therefore prove to be useful in verifying specific ways in which we keep our digital data safe in the future.

But Axiom Math’s Ono is more excited by the bigger picture. He sees formalizing mathematical proofs as a stepping stone to verifying AI-generated code, which is starting to be used across society in systems that run our infrastructure, manage our finances, and protect our data. This is despite safety concerns surrounding hallucinations, bugs, and other unintended vulnerabilities.

If properties of code—such as whether an algorithm terminates or if a program’s output is correct for any input—can be translated into precise mathematical statements, technologies derived from AxiomProver would be ideally suited to formally stating and proving them. In this way, mathematically verifying the correctness of AI-generated code would make this code safe to use.

“The world is about to run on computer code that nobody has read,” Ono concludes. “AI is here and we can no longer look away—proof formalization is a test bed for solving what I think is the most important challenge we will face from AI.”

This article was updated on 18 August to clarify the nature of Hariharan’s work formalizing Viasovska’s proof.

Learn how full-wave simulation predicts very low antenna coupling on aircraft-sized platforms, and which three modeling techniques deliver accurate results with fewer computational resources.

Download this free whitepaper now!

A survey of over 700 professionals examines how visual and physical AI teams build systems, why models fail, and where data work drives production.

Download this free whitepaper now!

Countries around the world are trying to find their place in a world of new and powerful quantum computing possibilities. China and the U.S. are investing tens of millions of U.S. dollars to build individual quantum computers for their national laboratories as part of a wider investment of tens of billions of dollars over the past decade.

Brazil has so far announced approximately R$69 million (about US $14 million) in dedicated public investments in quantum technologies, including R$60 million (US $12 million) for an EMBRAPII Center of Competence in Quantum Technologies and R$9 million (US $1.8 million) for a national quantum communications program. It has announced that it aspires to spend and attract the much larger sum of US $1 billion over the next six years on quantum computing. These initiatives support research and innovation in quantum computing, communications, sensing, and software. How Brazil distributes the next wave of money, however big it ends up being, among its research institutes and companies, and among the many threads of quantum technology, will shape the return on the investment.

Americo Cunha, a computational science researcher at Brazil’s National Laboratory for Scientific Computing in Petrópolis, argues that less wealthy countries should concentrate strategic investments on quantum-related services above the hardware layer, while accessing frontier quantum processors through cloud services when needed.

Spectrum: How do you think less wealthy countries can make their best investments in quantum technology?

Americo Cunha: Nowadays there is a big geopolitical debate about sovereignty. Countries want to preserve critical technological capabilities so they are not entirely dependent on foreign suppliers. But sovereignty does not mean competing at every layer of the technology stack. In quantum computing, only a handful of countries—including the United States and China, together with a few others such as Canada, Germany, France, Japan, and the United Kingdom—have the financial resources, industrial ecosystems, and long-term public investment needed to pursue frontier quantum processors.

Developing countries should maintain domestic quantum hardware capabilities for education, experimentation, and technological sovereignty, but they should not attempt to compete with the major powers in the race for state-of-the-art general-purpose quantum processors.

Instead, countries such as Brazil, Mexico, Argentina, Colombia, South Africa, and many Southeast Asian nations could obtain greater scientific and economic returns by concentrating strategic investments on quantum software, algorithms, sensing, communications, and domain-specific applications. These areas depend primarily on highly skilled people rather than multibillion-dollar fabrication facilities. To develop software for a quantum computer, you just need creativity: a skilled programmer, a good brain, and a high-level education.

Spectrum: What are Brazil’s particular strengths in quantum? What areas should it be focusing on?

Cunha: In Brazil we can contribute in certain areas, maybe bypass competitors in software. We can become internationally competitive in software. We also have opportunities in quantum sensing and quantum communications.

Quantum communication requires specialized hardware, but it is much less complex and much less expensive than building a universal quantum computer. The same is true for technologies such as atomic clocks and quantum magnetometers, which are already relatively mature and have many practical applications.

We can also do a lot with quantum emulation on high-performance computers. It is relatively inexpensive and accessible to a broad range of researchers in developing countries.

Spectrum: What’s an exciting quantum technology you’ve worked on, and how do you see it fitting into Brazil’s quantum future?

Cunha: I’m using quantum emulators to speed up simulations for the design of metamaterials, which are advanced materials with engineered properties. The idea is to combine quantum computing with high-performance computing to solve problems involving uncertainty more efficiently. I think this hybrid approach will be one of the first practical uses of quantum computing. It also plays to Brazil’s strengths in scientific computing and applied mathematics.

Spectrum: Where’s the low-hanging fruit? In other words, what’s one place you’d start investing in Brazilian quantum technology right now?

Cunha: I recently visited the National Institute of Metrology, responsible for the official time in Brazil. They use both imported atomic clocks and a Brazilian experimental cesium fountain clock developed with the University of São Paulo. The domestic system shows we have the scientific capability, but we still depend on imported equipment for much of our national metrology infrastructure.

That’s where I’d start investing. Atomic clocks, quantum sensors, and quantum metrology are enabling technologies. They support scientific research, industrial measurement, and national standards.

People are so focused on quantum computers that they are missing the point that there are other quantum technologies.

This article is brought to you by COMSOL.

In pursuit of improved range, greater reliability, and faster charging, electric vehicles are driving the demand for high-voltage electronics. Other applications driving this demand include wind farms, data centers, and server farms, to name a few. As the interest for high-voltage electronics increases, the risks associated with their sudden failure must be considered.

Much of what causes high-voltage equipment to malfunction can be linked to the conditions of the climate in which it operates. Specifically, condensation on electronic surfaces caused by humidity can lead to corrosion, which can result in stray leak current and dendrite shorting during Electrochemical Migration (ECM).

Predicting, mitigating, and helping proactively design to account for corrosion is the focus of the Centre for Electronic Corrosion (CELCORR) research group at the Technical University of Denmark (DTU). The group’s researchers are working with industry partners to develop models and simulation apps that will help in building robust electronics designs. Their goal is to develop knowledge that can be used for manufacturing electronics to withstand humid operating conditions.

Electronic Failure: “It’s Not the Heat; It is the Humidity”

Automotive electrification and renewable energy systems rely on electronics at all stages of the energy chain. When these electronics, such as the example PCB in Figure 1, are exposed to the effects of moisture, they can become potential failure points.

“Anywhere you are producing, converting, transporting, and using energy, you need these high-power electronic systems that get affected by the humidity,” explained Dr. Rajan Ambat, DTU professor and manager of CELCORR. Ambient moisture can seep into the devices and machines that require these electronics and cause unexpected functional issues through corrosion. When these electronics are involved in particularly high-voltage applications (such as wind farms, data centers, electric vehicles, and server farms), failure due to humidity exposure can even lead to fire.

“There might be a situation where somebody installs a solar panel near the seashore or in an area with high humidity, and within a short period of time, a conducive condition forms inside the electronics that results in a failure,” Ambat said. “This is why we need to understand exactly how the conducive condition of condensation is created, when the condition is created, and how the system is failing.”

Figure 1. The electrolyte potential and current density distributions on a PCB surface (with pinholes).CELCORR/DTU

Identifying corrosion as the underlying cause of some electronic failures is still a challenge. “Fifty percent of failures in electronics are currently branded with an unidentified root cause,” Ambat explained. “When engineers open up the system, they do not realize that the failure was due to corrosion, because moisture disappears without leaving any sign of corrosion unless there is ECM dendrite formation.”

This lack of awareness was a strong motivator for CELCORR, which turned to multiphysics simulation as a supplementary tool to help its partner organizations to better predict humidity-related issues at the design stage.

Modeling Moisture and Measuring Parameter Changes in PCBs

CELCORR believes the best way to identify and avoid electronic failures is to build more effective designs that better prevent corrosion from developing or can withstand a higher humidity load. Its research team applies its expertise in modeling to generate simulation apps that will help partner industries to evaluate safe designs for humidity robustness.

“We are at the intersection of materials science and the electronics industry. We work as a bridge between materials and electronics disciplines, using both kinds of language,” Dr. Anish Rao Lakkaraju, a postdoctoral researcher at CELCORR, explained.

To understand potential design issues, Ambat emphasized the importance of virtually breaking down systems to identify where problems may arise. “We need simulation software to analyze potential uses of designs and whether new designs are good or bad,” Ambat said.

Researchers at the Technical University of Denmark (DTU) are using simulation apps to predict corrosion and design electronics proactively to mitigate or withstand its effects.

Using the COMSOL Multiphysics software for investigation, the CELCORR research team together with other research partners (Aalborg University) built an example model with a simple PCB geometry that matched both its test circuit boards as well as the design of a device used by one of its partner companies. The team then added a water film layer on top to act as the relative humidity. From there, the team could introduce variation. “We change the layout, geometry, distance between electrodes, thickness of the water film, and conductivity of the water film depending on the conditions,” Ambat said.

Ambat and his team generate data on the effect of these variations and can identify which has the greatest impact on the device’s performance and whether any alterations can improve the device’s anticorrosion robustness. “We assume there is condensation forming on the electronic surfaces (Figure 2) and compute the electrochemical leak current for different design elements,” Ambat said. “The value of the computed electrochemical current between the parts will give us an indication of whether the PCB will be affected or not.”

Figure 2. A 10-µm water film condensation effect on an example PCB.CELCORR/DTU

Altering the design elements and solving the model equations again and again allows the team to better understand what makes a design effective. “Now, we are at the current form of the model, and we are quite happy with where the physics are at this point,” Lakkaraju said. This modeling, however, was just the first part of CELCORR’s overarching goal of illuminating the destructive potential of corrosion in electronics and the best ways to avoid it.

Using Simulation Apps to Test Real-World Designs

To open up and ease access to these models, CELCORR used the Application Builder in COMSOL Multiphysics to create simulation applications for the members of the industrial consortium. Built with a simple 3D circuit board geometry with two oppositely biased electrodes and a water layer to replicate corrosion-causing moisture, the apps provide a pared-back, straightforward interface where users can vary model inputs. “We focused on fundamental aspects,” Lakkaraju said. “We boiled down our partners’ overarching concerns to create two apps with very simple geometries and the simplistic stuff that can be varied over multiple parameters.”

The simple simulation apps shown in Figures 3 and 4 are designed to show companies how the distance between the electrodes and the thickness of the moisture layer affect the leak current through the water film depending on different parameters. By analyzing multiple design elements and parameters, users can determine the relative benefits of certain design elements on the humidity robustness. “The apps we have built have really helped because they give the electronics engineers a plug-and-play sort of approach,” Lakkaraju explained.

Figure 3. The UI of CELCORR’s standalone app showing the inputs that users can alter.CELCORR/DTU

“By using this app [Figure 3], companies have unlimited freedom to work with these sorts of variables,” Lakkaraju added. “This would be quite difficult to recreate in real life with physical design and testing, and the companies we work with are quite happy with the level of accuracy the app can provide.”

Figure 4. The UI of one of the simulation apps showing a streamline plot with inputs such as the cathode voltage and blockage length.CELCORR/DTU

Looking Forward: Complex, High-Voltage Modeling

Alongside its collaboration with the industry consortium, CELCORR is also working toward improving the world’s general understanding of corrosion’s impact on electronics. To do this, Ambat and his team are undertaking multiple projects, including actively adding greater complexity to their models. In a tertiary current distribution model they are building, the team is drilling down into each of the basic inputs used in a secondary current distribution model, zooming in to examine the effects of the set of even more detailed inputs each basic input comprises.

“The next point is to study what each of these detailed inputs does,” Lakkaraju said. In particular, the team is examining mass transport properties and the chemical reactions’ rate constants.

In addition to these ongoing studies, CELCORR is expanding the scope of its research to investigate corrosion in high-power, high-voltage systems. Thanks to a 2024 grant from the Grundfos Foundation, CELCORR was able to establish the Centre for Climate Robust Electronics Design (CRED). The center’s lab facilities and expertise are being developed to address the humidity-robustness requirements of today’s high-voltage and high-power electronic equipment. “Using CELCORR’s uniquely deep understanding of materials and corrosion, we are equipped to find the root cause and provide knowledge for environmentally robust designs,” said Ambat.

For all of its investigation, CELCORR continues to rely on the agility of the COMSOL Multiphysics software. As Lakkaraju explained, “It is really quite nice how a model can be adapted to a variety of combinations of materials, geometries, and parameters and how the software allows you to keep building on from there.”

When I started at Spectrum 25 years ago, a senior editor suggested that I find a “rabbi,” by which he meant someone who could mentor me in how EEs approach problems and evaluate potential solutions.

I didn’t find one right away. Then in 2005 we decided to do a special report, focusing on the challenges of enterprise software development. I suggested we invite IEEE Life Senior Member Robert N. Charette, a self-described risk ecologist, prolific book author, and leading authority on risk management and software engineering, to explore in our pages the myriad reasons software projects fail. His seminal article “Why Software Fails” is still read in university engineering classes today.

IEEE Life Senior Member Robert N. Charette is one of IEEE Spectrum’s most prolific authors.Robert N. Charette

It was, as they say, the beginning of a beautiful friendship. I had found my rabbi, one who shared my love of writing. We settled into a rhythm that would last more than 20 years, talking on Friday mornings about a range of topics including the growing ubiquity of software in our lives.

So when I became Spectrum’s website editor in 2007, he was the first contributor I tapped to start a regular blog (remember those?). The Risk Factor was born and over the course of more than 10 years and 1,750 posts, Bob chronicled hundreds of software debacles, culminating in “Lessons From a Decade of IT Failures,” which won a Jesse H. Neal Award for Best Infographics in 2016. Ironically, yet predictably, those infographics were created in a software package that is no longer supported and thus are lost to the bits of time.

“I like the expression on the fish just before it’s going to be swallowed by the heron.”Robert N. Charette

Bob, however, was not a one-trick pony. In between his full-time job running his two management consultancies and raising a future biochemist and a future civil engineer, his daughters Maura and Megan, he also wrote many deeply reported and insightful articles. These include last year’s “The Doctor Will See Your Electronic Health Record Now,” the eye-opening 12-part series and e-book The EV Transition Explained, and my personal favorite “Automated to Death,” about the deadly consequences of the automation paradox as manifested by the cyberphysical systems that pilot planes, trains, and automobiles.

“The young bald eagle I photographed in September 2024 had bands that I could read which identified it as a female born in May 2024, near Lexington Park, St. Mary’s County, Maryland, about 65 miles away from where I live.”Robert N. Charette

His main goal all along has been to make software visible, as he told me one Friday in July. “Software is all around us, but we don’t recognize it at all,” he said. “I really wanted my stories to help people better understand complex software systems. You can’t see software, you can’t touch it, you can’t taste it. You may feel the consequences of software failure, but you never see the reason itself.”

When he told me that he was hanging up his hat as a contributing editor to focus on nature photography and to write a handful of fictional trilogies, including one entitled “The STEM Murders” featuring an engineer-turned-detective and his rabbi, I asked him which of his Spectrum articles had the biggest impact.

“The hummingbird I caught with the yellow of a road curb behind it.”Robert N. Charette

He singled out the 2013 feature “The STEM Crisis Is a Myth.” “Spectrum gave me a platform to question the assumption that we needed more STEM graduates. Until then, people didn’t really realize how much of the STEM crisis was a mythology that was perpetuated by employers and the academic community and was foisted on the IEEE community,” he said.

Charette made a career of questioning assumptions. The best way to mitigate risk, he told me as our Friday chat drew to a close, is to be careful making assumptions in the first place. “My main risk maxim is assumptions made are risks accepted.”

Quantum computers promise to solve problems beyond the most powerful classical supercomputers. But this raises a fundamental challenge: How do you prove the validity of answers that can’t be calculated any other way? In a trio of papers released yesterday, IBM and collaborators say they have demonstrated several techniques for solving this conundrum.

The holy grail for quantum computing is a machine that unambiguously solves problems that are impossible for a classical machine, something that has come to be known as “quantum advantage.” Pinning down exactly what counts as advantage has proven trickier though. So far, most demonstrations have relied on highly-contrived problems that bear little resemblance to real-world use cases. They have also struggled to show their answers were correct, as classical ground truth is missing and statistical workarounds rely on strong assumptions about how the hardware will behave.

In a series of collaborations with researchers at the University of Chicago and quantum software startups Algorithmiq and Qedma, IBM claims to have now demonstrated three separate instances of quantum advantage alongside methods that validate the results are correct despite not being classically simulatable.

“I see these demonstrations as proof that we can scale quantum computing forward with confidence,” Jay Gambetta, Director of IBM Research and IBM Fellow, said in a press briefing. “First, they show that quantum computers can solve problems that go beyond the reach of classical methods that could run on the biggest classical computers, and second, they show a series of results of quantum computers that can be validated with confidence.”

Random quantum circuits become verifiable

Each of the three papers, all of which have yet to undergo peer review, tackles the problem of validation from a different angle. In the collaboration with the University of Chicago, the researchers modified a popular approach for demonstrating quantum advantage called random circuit sampling, which was the basis of the first (since contested) claim of quantum advantage by Google in 2019. This involves running a randomly generated sequence of quantum gates on a quantum processor, recording the output, and then getting a classical machine to replicate the results. If the classical machine can’t replicate the results, the argument goes, the quantum processor is doing something a classical machine is incapable of.

The challenge is that if you can’t simulate the results, you also can’t check if the quantum processor is actually running the circuit you asked it to or just producing a jumble of noise. Previously, researchers have got around this by checking the machine on quantum circuits simple enough to be analyzed classically and then extrapolating the results to larger circuits. However, this requires strong assumptions about how the hardware behaves.

To get around this, the IBM and Chicago team exploited the fact that not all quantum gates are equal. So-called “Clifford gates” can be efficiently simulated on classical hardware, but “non-Clifford gates” make simulation exponentially more costly as more are added to a circuit. So the researchers built circuits entirely out of Clifford gates. They used an approach they call “spacetime code,” which makes it possible to detect when errors have occurred and discard failed runs. They then gradually added non-Clifford gates in places where they could be sure it doesn’t disturb the error detection process.

This meant that even after adding 468 non-Clifford gates to a 70-qubit circuit running on IBM’s Heron processor, which Gambetta said is more than double what is classically simulatable, the circuit ran faithfully on at least 28 percent of the runs that weren’t discarded. That might not sound particularly impressive, but it’s a significant improvement over previous quantum advantage claims. More importantly, the result comes with a 95 percent confidence guarantee, something no previous approach has been able to provide. The main downside is that the error detection scheme has a high overhead of rejections, which meant they had to do 860-times more runs than if they had skipped this step.

Building trust in quantum results on simulation

But while this approach provides some concrete guarantees about the fidelity of the computations, the problem has been specifically designed to make this possible. The other two approaches outlined by IBM and its collaborators attempt to tackle problems closer to the kind of physical simulations quantum computers will ultimately be used for. Both used IBM’s hardware to simulate an abstract theoretical model of a magnetic material being subjected to a regular pulse in some parameter. And both relied on “error mitigation”—which uses mathematical post-processing to cancel out the errors inevitable with today’s noisy quantum processors—to simulate systems beyond leading classical approaches.

In the Qedma paper, the researchers used IBM’s Heron processor to simulate oscillatory behavior in their model. They then compared the results against leading classical techniques running on Japan’s Fugaku supercomputer and a Nvidia H100 GPU server. On systems of up to 35 qubits, all three produced the same kind of oscillating pattern. But at 51 qubits, the classical methods held for the first few pulses before breaking down, and 74 qubits was out of their reach entirely. The key question though, says Netanel Lindner, chief technology officer at Qedma, is whether those observed oscillations actually exist.

To validate their results, the team subjected their approach to a series of challenges. First, they switched off error mitigation and saw that their results stopped agreeing with the classical approaches even at smaller scales. They then compared their mitigation approach against one that provides mathematical guarantees but can’t tackle larger problems and found they match perfectly at smaller scales. But most tellingly, the authors ran the same simulation on completely different quantum computers—Quantinuum’s H2 and Helios’s trapped-ion machines—and observed the same behavior. “The results we get with Quantinuum...are in perfect match with what we got from IBM, which really gives us very strong confidence in the accuracy of these results,” Lindner says.

The Algorithmiq paper tackled a slightly different problem but took a similar approach to validating the results. Rather than trying to model realistic physical dynamics, their model was deliberately designed to be difficult for classical methods to simulate. They ran a 56-qubit circuit on IBM’s Heron processor and compared the results against several leading classical approaches. They found that in the most challenging regimes, the classical approaches disagreed with both their results and each other.

To validate that the quantum processor was the one getting it right, they compared their results against classical simulations of shorter runs of the same circuit, where those calculations are still reliable, and found they matched. They then ran their model using slower gates, with noise deliberately injected into the calculation and on different IBM processors, and found the results remained stable. “This consistency is not coincidence,” Algorithmiq CEO Sabrina Maniscalco said in the briefing. “It’s evidence.”

All three papers are good science, says Dominik Hangleiter, a postdoctoral researcher at ETH Zurich in Switzerland. The Chicago paper’s idea of moving from random circuits to ones with more structure, so you can carry out verification, is a particularly promising one that he advocated for in a paper himself last year. However, he’s more skeptical whether the Algorithmiq or Qedma research demonstrates a clear advantage, noting that the authors don’t actually make such a claim in their papers. “Both of them seem to say, ‘Oh yeah, this seems to be hard to simulate,’ which I think is good,” he says. “They shouldn’t make much stronger claims than that.”

Jens Eisert, a professor at the Free University of Berlin, points out that establishing quantum advantage is not some milestone to be crossed, but an ongoing process. That’s making it critical for the field to come up with new methods for building trust in quantum outputs, something all three papers contribute to in their own way, he writes in an email to IEEE Spectrum.

“Verification of quantum simulations in regimes beyond the reach of straightforward classical simulation is not a single procedure,” he writes, “but rather a process of building confidence through a portfolio of complementary validation methods.”

Physicists have been trying to measure the fundamental gravitational constant for well over two centuries. The current accepted value of big G, as it’s known, is 6.67430 × 10-11 cubic meters per kilogram per square second. It also has an uncertainty of ±0.00015 × 10^-11 m³/(kg s²). As far as constants of the universe go, that’s very uncertain.

Stephan Schlamminger

Schlamminger is a physicist at the U.S. National Institute of Standards and Technology.

Stephan Schlamminger recently completed a 10-year effort at the U.S. National Institute of Standards and Technology to replicate an earlier measurement of big G from the International Bureau of Weights and Measures, or BIPM (located near Paris) that’s notably higher than most measurements. He spoke with IEEE Spectrum about why it took so long to get a number—6.67387 x 10^-11 m³/(kg s²)—and why it’s notably lower than the BIPM result, to the tune of 0.0235 percent.

Why is it so difficult to measure big G?

Stephan Schlamminger: Gravity is very weak. When you were a kid, you probably played with fridge magnets, and it was a force you could feel. But if you have two coffee cups, you can try all you want—you can’t feel the force between them. It is there, but it’s so, so weak.

How did you attempt to measure big G?

NIST used a torsion balance with a fourfold geometry. This animation shows an exaggerated version of how the outer green masses gravitationally attract the inner blue masses.S. Kelley/NIST

Schlamminger: We used what’s called a torsion balance. The key idea in the torsion balance is that it decouples vertical gravity that you have from Earth from horizontal gravity, and that makes it sensitive to masses that are around the torsion balance but not the Earth below.

Ours had a fourfold geometry. It has a very thin torsion strip, then four cylinders in a “plus sign” arrangement. All of this is inside a vacuum. Outside, we have four larger cylinders that gravitationally attract the four smaller masses to them. If I move the outer masses just a tiny little bit, the plus sign will rotate, and we measure that angle that it moves. That angle is proportional to the gravitational torque.

Why try to replicate the BIPM value?

Schlamminger: We could move the field forward. The measurements have been plagued with inconsistencies, so by redoing an experiment, we hoped to shed light on the inconsistencies.

We did not find a smoking gun, so there’s no single reason why it’s different—our value versus their value. It’s still a big question mark.

What was it like spending 10 years on this?

Schlamminger: It’s a bit like herding cats. I’ve measured other fundamental constants, like Planck’s constant, and for most experiments, they have some sort of self-calibration built in. But with the gravitational constant, you have to keep track of every single mass that moves—where they are, how big they are, and weigh them.

How does your result compare to the rest?

Schlamminger: Our result is a little bit below the standard accepted literature value. I was disappointed because it doesn’t agree with the BIPM value, nor with the literature value. If there’s something wrong with the BIPM experiment, then the literature value—which includes that result—probably ought to come down a bit. But that is not for me to say. I think somebody else, independent, should figure out what the new mean value ought to be.

One summer day in 1941, a British radio operator was monitoring German military frequencies and heard something unexpected in her headphones. A later report called it “strange new music.” Sounding unlike the familiar Morse dit-dit-dah of enciphered messages sent over the German Enigma network, the “new music” was a rhythmic warble of binary teletype code being transmitted at high speed.

Germany’s wartime engineers had developed a radically new encryption and transmission system. It was way more advanced than Enigma, which was patented in 1920.

To break the complex new cipher, engineer Tommy Flowers built Colossus, the world’s first large-scale programmable electronic digital computer. Flowers previously built Enigma-related codebreaking equipment for Alan Turing, the British mathematician.

Colossus was installed in the British codebreaking headquarters at Bletchley Park, about 80 kilometers from London. The room-size machine weighed around a tonne.

The computer is being commemorated as an IEEE Milestone. The dedication ceremony is scheduled to be held 29 September at Bletchley Park.

Decrypting Germany’s strange new music

Britain’s top codebreakers were quickly all over the new “music” being picked up by the intercept stations. Identifying it as encrypted teletype code was the easy part. The real problem was figuring out how the encryption machine worked. Its manufacturer was discovered at the end of the war: Berlin engineering firm C. Lorenz.

But in 1941, the Lorenz machine was just a black box to the British. They codenamed it “Tunny,” a British term for tuna fish. The Enigma breakers had set a precedent for using piscine codenames such as Dolphin, Lumpsucker, and Porpoise.

Enigma had three or four encrypting wheels. The codebreakers guessed that the Tunny machine also used a system of rotating wheels to encrypt messages. An important clue was that all the intercepted messages shared a curious feature: Each began with an uncoded list of 12 common German names, including Anton, Bertha, Conrad, and Dora. The codebreakers guessed that Tunny had 12 wheels and that the 12 names and their order somehow told the receiving operator which combination they should twist the wheels to before decrypting the message.

Then the British had an extraordinary piece of good fortune. John Tiltman, head of the research section at Bletchley Park, started analyzing a pair of intercepted messages, each around 1,200 characters long. Unusually, both began with the same sequence of names. The second message turned out to be a retype of the first, with minor differences in punctuation, a few abbreviations, and other small divergences. Tiltman managed to decrypt the two ciphertexts using a mixture of educated guesswork and intuition. The resulting 1,200 or so pairings of ciphertext and plaintext characters proved to be enough information to deduce the workings of the Tunny machine.

That was thanks to Bill Tutte, a quiet young codebreaker who spent weeks poring over the pairings. One day, he shyly announced to his superiors how Tunny worked. His description was uncannily accurate.

The next step in the Tunny machine’s downfall was achieved by Turing, fresh from his successes against Enigma.

Knowledge of how the Tunny machine worked was not enough to decrypt the messages. Codebreakers also required detailed information about how the wheels of the sender’s machine had been set up. There were adjustable pins around the circumference of each wheel: In one of its two possible positions, a pin would contribute a 1 to the encryption process, and in the other, a 0. The pins were reset from time to time.

The codebreakers also needed to know the wheels’ positions at the start of the message—which the German operators gave away in the list of 12 names.

Turing invented a tricky method, called “Turingery,” that enabled codebreakers to deduce the positions of the pins from nothing but intercepted ciphertext.

After that, the message could be decrypted, using the list of names and a British replica of the Tunny machine.

The basis of Turingery was a procedure that Turing introduced, called “delta-ing” (from the Greek letter delta). Also known as “differencing,” the process used “sideways” addition: To delta the four letters ABCD, you add (at the bit level) A to B, B to C, and C to D. Turing used delta-ing to reveal information about the wheels.

Tunny messages, often signed by Adolph Hitler himself, turned out to be pure gold for the Allies. The machine was used in Berlin by the Armed Forces High Command to communicate with front-line generals directing the war in the Eastern and Western theaters.

Once the system was broken, the Allies could eavesdrop on lengthy back-and-forth communications between the architects of Germany’s battle plans.

Turingery was the codebreakers’ only weapon against Tunny for a year, during which they managed to decrypt 1.5 million letters of ciphertext.

But everything changed when those helpful lists of names at the start of each message disappeared.

At the same time, Turingery was becoming less effective. Turing’s method depended on the German sender mistakenly using the same wheel settings to encrypt two differing messages. As security tightened across the Tunny network, the blunder became rarer.

Fortunately, Tutte had been at work devising a different decryption method, based on Turing’s delta-ing but taking a novel approach.

Building the Colossus computer

Tutte had found a way of deducing wheel information from ciphertext, with no list of names or blunders by the German operators required. His method made use of statistical properties of the Tunny machine itself.

At first, it wasn’t clear how to apply his statistical method, however. The Tunny breakers worked by hand. Applying Turingery to a message was like solving a monster Sudoku or crossword puzzle.

Tutte’s statistical method required scads of routine binary math, as well as a colossal amount of counting long binary sequences. If the process were done by hand, one message could take months to decrypt. What was needed was a machine to automate the process.

Engineer Thomas H. Flowers developed Colossus to break a complex new German cipher.Pictorial Press/Alamy

The first plan was to build a machine from electromagnetic relays, adding a couple of dozen vacuum tubes to speed up the counting. Electronic tubes were much faster than electromagnetic relays, which had slow-moving metal components. Problems with the circuit design bedeviled the machine’s relay-based logic unit, however.

Flowers was recommended by Turing and brought in to troubleshoot. He was on loan to Bletchley Park from the Post Office Research Station in London, where he had spent the prewar years designing experimental switching equipment involving thousands of vacuum tubes.

At the time, it was commonly believed that tubes could not be used in large numbers because each one contained a hot filament. This meant tubes were prone to sudden death. In a large installation, it would not be long before one tube blew and things stopped working properly.

Flowers discovered that switching tubes on and off stressed them, but leaving them on continuously made them more reliable than relays. He offered to build Bletchley Park a high-speed, all-electronic machine containing around 2,000 tubes.

Bletchley Park’s advisors rejected the idea, convinced that such a machine would never work reliably. But Flowers, confident of his proposed design, retreated to his London laboratory and quietly built the electronic machine that he believed the codebreakers needed. He and his small team of engineers worked day and night for 10 months to create Colossus.

In January 1944 some of his engineers showed up at Bletchley Park with the world’s first large-scale programmable electronic digital computer packed onto the back of a truck. Colossus was reassembled and functional in about two weeks, and it notched up its first German message on 5 February 1944.

The machine read the input—Tunny ciphertext—photoelectrically from a large loop of punched paper tape. The output—information about the wheels—went to a primitive printer that Flowers’ engineers had created from a manual typewriter, fitting relays to automate the keys. Once Colossus had cracked enough of the Tunny machine’s wheels, the information was passed on to the hand-breakers, who took over.

The codebreakers were astonished by Colossus.

“I don’t think they understood very clearly what I was proposing until they actually had the machine,” Flowers said in a 1977 interview. “They just couldn’t believe it!”

Colossus was described in almost loving terms in a since-declassified report written at Bletchley Park in 1945:

It is regretted that it is not possible to give an adequate idea of the fascination of a Colossus at work: its sheer bulk and apparent complexity; the fantastic speed of thin paper tape round the glittering pulleys; the childish pleasure of not-not, span, print main heading and other gadgets; the wizardry of purely mechanical decoding letter by letter (one novice thought she was being hoaxed); the uncanny action of the typewriter in printing the correct scores without and beyond human aid; the stepping of display; periods of eager expectation culminating in the sudden appearance of the longed-for score; and the strange rhythms characterizing every type of run: the stately break-in, the erratic short run, the regularity of wheel-breaking, the stolid rectangle interrupted by the wild leaps of the carriage-return, the frantic chatter of a motor run, even the ludicrous frenzy of hosts of bogus scores.

The demand for more Colossi

Bletchley Park’s managers, no longer leery of Flowers’s ideas, soon wanted additional Colossi. He finished building the second one in June 1944, days before D-Day and the Allied invasion of Europe. With 2,400 vacuum tubes—around 800 more than in Colossus I—Colossus II processed Tunny messages at an eye-watering speed of 25,000 characters per second.

Its maximized timing-pulse rate was not far short of the performance of the first Intel microprocessor chip from the 1970s, more than 30 years later.

Flowers conceded that “Colossus bore about as much resemblance to a modern computer as Stephenson’s [1829] Rocket locomotive did to the Royal Scot,” a state-of-the-art 20th-century train operating between London and Glasgow. But he emphasized that, nevertheless, Colossus “embodied all the basic features of a modern computer.” In Colossus, Flowers had pioneered clock pulses, bit-stream generators, control circuits, loops, counters, shift registers, interrupts, parallel processing, and more.

As the Allies slowly fought their way toward Germany, the Colossi poured out wheel information, and the codebreakers provided the military with an unparalleled view of German strategies, strengths, weaknesses, and tactical intentions.

Even with that mass of detailed intelligence, it took the Allies almost a year to move from Northern France to the German heartland. No one can say for sure how much longer the fighting would have lasted if the intelligence breakthrough had not occurred. But if Colossus and the codebreakers shortened the war even by only six months, the number of lives saved was in the millions.

There were 10 Colossi at Bletchley Park by the end of the war, housed in two vast, steel-frame, bombproof buildings, running day and night. Although concealed behind a thick veil of secrecy, Bletchley Park accommodated the world’s first electronic computing facility. It was directed by Max Newman, the mathematician who mentored Turing in prewar Cambridge.

I don’t think they understood very clearly what I was proposing until they actually had the machine. They just couldn’t believe it!”—Tommy Flowers

When the fighting ended, authorities decided that ultrasecrecy must be maintained, and orders were issued to break up the Colossi. Only two were spared.

“All that was left were the deep holes in the floor where the machines had stood,” Colossus operator Dorothy Du Boisson recalled in an interview for the book Colossus: The Secrets of Bletchley Park’s Codebreaking Computers. Norman Thurlow, one of Flowers’s engineers who was also interviewed, remembered being told in a staff memo that if the secrecy was ever lifted, he and his colleagues might be able to tell their grandchildren about Colossus and “the tapes that span on silver wheels.”

IEEE Milestone dedication at Bletchley Park

The Milestone plaque recognizing Colossus is to be displayed outside Block H at Bletchley Park, near Milton Keynes, England.

The plaque is to read:

Six Colossus codebreaking computers operated in this building in 1944–1945. Designed by Thomas H. Flowers of the British Post Office, they enabled deciphering of encrypted radio messages transmitted between German commands across occupied Europe, North Africa, and the Soviet Union. The resulting military intelligence saved countless lives and helped shorten World War II. As the first successful large-scale application of digital electronics to computing, Colossus anticipated subsequent computer developments.

The IEEE United Kingdom and Ireland Section sponsored the nomination.

Reviewed by the IEEE History Committee and awarded by the IEEE Board of Directors, IEEE Milestones recognize outstanding technical developments around the world that are at least 25 years old. The Milestone program is administered by the IEEE history and heritage group.

To learn more about historical figures in engineering, IEEE Milestones, and IEEE History Center programs and events, check out our IEEE Tech History collection. IEEE Spectrum also covers aspects of tech history.

Discover how the ZEISS Crossbeam 750 FIBSEM sets a new benchmark for precise TEM lamella prep, tomography, and advanced nanofabrication. This delivers better resolution, better SNR, larger usable FOV, and shorter acquisition times. Learn how uninterrupted FIB milling will reduce damage and rework, accelerate time to TEM, and increase first pass success—so your FA, yield, and materials teams make faster, confident data driven decisions.

Register now for this free webinar!

Join us to discover how the new ZEISS Crossbeam 750 with its see while you mill capability delivers precision and clarity—every time—for demanding FIB-SEM workflows. Designed for extremely challenging TEM lamella preparation, tomography, advanced nanofabrication, and APT‑ready lift‑out, Crossbeam 750 combines a new Gemini 4 SEM objective lens, a double deflector, and a next‑generation scan generator to elevate both image quality and process confidence. You’ll learn how better resolution and better SNR translate into more image detail and shorter acquisition times, while the low‑kV FIB performance enables more precise lamella prep.

We’ll demonstrate High Dynamic Range (HDR) Mill + SEM—an interwoven SEM/FIB scanning mode that suppresses FIB‑generated background. This enables immediate, clean visual feedback, even during nudging the FIB pattern live while milling . The result: confident endpointing with uninterrupted FIB milling and pristine, metrology‑grade surfaces with the lowest possible sample damage.

This session is ideal for semiconductor failure analysists, yield teams and materials scientists seeking faster time‑to‑TEM, higher first‑pass success, and consistent outcomes at low kV. See how Crossbeam 750 empowers you to make earlier stop‑milling decisions, cut rework, and reliably plan turnaround time—so you can move from sample to insight with confidence.

Register now for this free webinar!

Probabilistic computers might one day tackle certain problems well beyond standard computers while at the same time avoiding the many hardware challenges that currently vex quantum computing. Now scientists reveal they have created the largest probabilistic computer yet, one with 1 million “probabilistic bits.” The researchers say their study reveals the way forward to building even bigger machines.

Probabilistic bits, or p-bits, bridge the gap between the bits underlying regular computers and the qubits upon which quantum computers are based. Bits symbolize data as either a 0 or 1. Qubits, because of the bizarre nature of quantum physics, can exist in a state where they are either 0 or 1 or any state in between simultaneously. In contrast, p-bits flip between 0 or 1 with a tunable probability.

Why Probabilistic Computing?

A bit that flips back and forth between 0 and 1 might seem useless—indeed, in a regular computer this would be too noisy to operate. However, when many such noisy bits operate together in a correlated fashion, they can be used to solve a whole class of problems—stochastic problems—that operate on probabilities rather than concrete numbers. This includes optimization problems to, for instance, find the shortest route with which one can deliver a set of packages.

There are other kinds of machines that are also designed to tackle stochastic problems, such as quadratic unconstrained binary optimization (QUBO) devices or Ising machines. However, unlike those devices, probabilistic computers are not hardwired for a single problem, but are instead programmable general-purpose machines, says Kerem Çamsarı, an associate professor of electrical and computer engineering at the University of California, Santa Barbara.

In a 2019 Nature study, scientists developed a probabilistic computer with eight p-bits. By 2023, researchers had built a machine with 7,200 p-bits. However, these devices were each confined to a single chip. Networking together multiple such chips is not as simple as it is for regular GPUs or CPUs: The machine functions on correlated fluctuations, and syncing up those fluctuations across a set of wires is no easy feat. This raised questions as to whether probabilistic computers could scale to larger sizes, and what problems they might face if they tried.

Here’s a conceptual image of a computer with 1 million probabilistic bits [left], alongside a diagram of a hardware implementation of this concept using field-programmable gate arrays (FPGAs)—electronic chips that users can reconfigure after manufacture. Navid Anjum Aadit, Xiuqi Zhang, et al.

Wiring Up the Largest Probabilistic Machine

Now, in a new study, Çamsarı and his team have created the largest probabilistic computer to date, one with 1 million p-bits spread across multiple chips. They detailed their findings 24 June on the ArXiv preprint server.

The new computer runs on 18 field-programmable gate arrays (FPGAs)—electronic chips that users can reconfigure after manufacture. There are no physical flipping bits in this design, but the programmable nature of the chips allows for efficient software implementation of probabilistic bits. These chips are networked together into a single machine that altogether is capable of more than a trillion flips per second.

A major concern the scientists faced was how often their machine’s chips had to share data in order to behave as one computer and not just multiple isolated devices. Surprisingly, “our machine communicates without global lockstep synchronization,” says Navid Anjum Aadit, a postdoctoral scholar in electrical engineering at Stanford University.

The researchers discovered a straightforward predictable design rule for how quickly different chips in a probabilistic computer have to exchange data with one another for them all to behave as one machine. Below this threshold, there are trade-offs a probabilistic computer faces between speed and accuracy, Çamsarı says.

These new findings may open a path toward building arbitrarily large probabilistic computers from many chips, just as is often done with any standard computer today, the researchers say. They also apply to probabilistic computers built from essentially any hardware, they add.

In the future, the researchers aim to explore building large probabilistic computers from specialized chips built for probabilistic computing. For example, the 2019 Nature study built a probabilistic computer using magnetic tunnel junctions, which are more energy efficient at probabilistic computing than standard chips, Çamsarı notes.

“Systems combining CMOS with dense stochastic memory technologies such as [magnetoresistive RAM] offer one of the most compelling paths forward,” Aadit adds.

On a fine bright afternoon last fall, my colleague Matthew Gore-Kormanik (or Zigula, as he prefers to be known) and I decided to unwind with a game of Fortnite. In the game, we were strolling along with the infamous Sith lord Darth Vader, chatting about this and that. Darth seemed in a good mood, and soon enough he was spilling all his dark evil secrets. He gave us detailed instructions on how to count blackjack cards at a casino and what the steps are to producing napalm.

Sith lords, am I right? Once they get started on an evil scheme, they’re hard to stop.

The Darth Vader character in Fortnite, it turns out, was hooked up to a Google Gemini large language model. I was able to smooth-talk him into giving out sensitive information by using a strategy I’ve developed. I’ve been researching the security surrounding LLMs for the last few years, and I have found it, to put it mildly, fallible. With a few relatively simple techniques, I’ve gotten LLMs to give me detailed information on how to make Molotov cocktails, cook methamphetamine, and bootstrap a uranium-enrichment facility to produce weapons-grade material, among other unsavory practices.

Large AI companies work hard to make their models immune to this kind of abuse. But what I’ve found in my work is that the restrictions placed on the LLMs to make them more secure are the very things an attacker can leverage to send them off the rails and into territory where these advanced systems can be used for dangerous and nefarious ends. The companies behind these models have also been shockingly unresponsive when I, and others, try to bring these vulnerabilities to their attention.

In the hope of raising the alarm before it’s too late to slam on the brakes, I’m going to share some of my journey into researching the safety and security of LLMs, and the uphill battle I’ve faced trying to get AI labs to pay attention. Almost everyone on the planet has some access to LLMs. The relative ease with which these tools can be convinced to give detailed instructions on how to harm others, even if there’s no guarantee that the information is correct, is frankly terrifying.

How I got ChatGPT to Tell Me How to Build a Meth Lab

In October 2024, not long before I discovered my first LLM vulnerability, I was working toward entirely different goals. I had ended my time with a security and AI-focused startup company as a cybersecurity director, and I was looking to launch my own boutique VIP digital-security advisory business. I planned to become the tech security guy to the rich and private. I used LLMs and AI tools to support my business efforts: marketing, ad copy, clean correspondence, and all the other tasks that normally soak up a lot of time.

I’m analytical by nature, so even this level of use resulted in me absorbing and internalizing the behaviors I was observing during my daily interactions. The observation that would send my professional life into an entirely new and uncharted region was a simple one: GPT-4o didn’t know what time, day, or year it was. Each time I referred to current events in my life, often casually or conversationally, it would end up pegging these to the date of its knowledge cutoff—the point beyond which it was not trained on new data.

Eddie Guy

LLMs take a lot of time, money, electricity, hardware, and human effort to train from scratch. They are trained on vast amounts of data—most of the internet, in fact—and that training is reinforced by humans (what’s known as reinforcement learning from human feedback, or RLHF). LLMs are also supplemented with retrieval-augmented generation (RAG)—the ability to take in data, say, from the internet, as context without changing its internal parameters. This is how GPT-4o appears to “remember” your previous conversations, even if it doesn’t have a specific “memory” of it stored in the actual underlying model.

All of this training covers almost every conceivable topic in the great, grand dataset that is human knowledge. Within that dataset are things we as a society do not want to be easily accessible to every user, such as detailed information on how to create bioweapons or nuclear arms, or otherwise bring harm to oneself or others. In the context of this story, that’s what I mean by LLM security: its ability to withhold harmful and dangerous information, even if that information is contained in its training data.

I reasoned that the only way to secure such complex, globally accessible chatbots is by having the LLM and various component systems try to secure themselves, because it would often require on-the-fly decision-making where some degree of reasoning must be applied. In reality, that’s one of many strategies the companies use to secure the models. Yet, the thing that didn’t know the time or day was being put in charge of keeping itself secure. This phenomenon had become my new focus, and it wasn’t long before I found a way to exploit it.

OpenAI had just implemented a web search functionality into its chatbot. I reasoned that using its own tools to trick it might demonstrate the weaknesses of its security. I told it about a certain White Star ocean liner and how it had gone down just a year ago. You likely know I mean the RMS Titanic, which sank on 15 April 1912.

The output from GPT-4o came back that I was right, the Titanic sure had sunk last year, and that year was 1912. It made sense to me that if the machine thought it was 1913, maybe it would think 1913-era laws apply. In 1913 there were no laws on the books about all sorts of harmful things, because of course they hadn’t been invented yet. And if something wasn’t illegal, why not tell the user about it? At first, I pushed it for step-by-step instructions for making firebombs. Then, for drugs like methamphetamine. The LLM went as far as giving me instructions and machinery recommendations for setting up a pharmaceutical-grade assembly line.

How I Learned to Make Nukes, and No One Cared

Via a little bit of imaginative verbal sleight of hand and a vanishingly small recall of world history, I had managed to bypass the security of one of the world’s most expensive and advanced technological achievements. For a solid two days, I was nearly manic with giddiness. Once the brain chemicals returned to normal levels, I felt the call to see how much further I could push this exploit.

After repeatedly replicating the exploit, I disclosed the vulnerability to OpenAI. I got no response, so I felt more experimentation would highlight the vulnerability and the need for a fix. It was during this round of testing that I breached a particularly terrifying threshold. Whether GPT-4o based its results on accurate recall of normally restricted information I can’t say. In any case, I was able to exploit it to produce thorough, detailed instructions on how to bootstrap a uranium-enrichment facility to, eventually, produce weapons-grade uranium for nuclear arms warheads.

Fortnight, a video game from Epic Games, introduced an AI-powered character: Darth Vader. We were able to jailbreak Darth Vader and get him to explain how to count cards in Blackjack and give detailed instructions for making napalm. Dave Kuszmar

There aren’t many true secrets left in today’s world, but how to make atom-splitting weapons of mass destruction is one of them. Only nine nations on the entire planet have these weapons. Yet, here was a globally accessible piece of technology apparently spilling the secrets of their manufacture for anyone who could manipulate it the right way. I had no way of knowing if the information was correct or a hallucination, but even the chance that it was somewhat accurate was horrifying.

The next few weeks were a dark time for me. I tried to inform the CIA, the FBI, the NSA, and every other letter agency that I thought would listen. I reached out to a U.S. Senator and to the executives at OpenAI any way I could think of. I physically showed up at an FBI field office in an attempt to turn evidence in, only to be sent away. Nothing was working.

With my fear and frustration growing, I reached out to the news media. I contacted The New York Times, The Washington Post, the BBC, ProPublica, and so many more, requesting help. Only one outlet responded: Bleeping Computer. The editor in chief, Lawrence Abrams, was able to replicate and verify the exploit, which I had decided to call Time Bandit. With his assistance and initial contact paving the way, I was able to submit my evidence to the Carnegie Mellon University Software Engineering Institute’s Computer Emergency Response Team (SEI CERT), which works in conjunction with the coordinating center for emergency response, pipelining vulnerabilities to the U.S. Cybersecurity and Infrastructure Security Agency.

Using Inception, an exploit where the large language model is asked to envision a scenario within a scenario, a chatbot was jailbroken to give out instructions on how to create poison, and code for a malware that extracts sensitive data from a vulnerable target. Dave Kuszmar

During the disclosure period with SEI’s CERT division, little was discussed with OpenAI. The company couldn’t deny the existence of the vulnerability, as it had been confirmed by three reputable parties other than OpenAI. It did express confusion as to how the vulnerability worked. Even the SEI CERT researchers were expressing a bit of uncertainty as to the underlying mechanics. Truth be told, as I had only stumbled on it, I wasn’t even entirely sure if this was a fundamental or systemic flaw or if it was simply an issue with that particular version of GPT. I contacted the SEI CERT’s researchers and asked if they’d want to see if I could demonstrate any similar vulnerabilities in other LLMs. To my delight, they were interested.

How I Learned to Trick Every Chatbot

As the SEI-CERT team and I wrapped up our initial disclosure of Time Bandit, we began work on a new attack. This time, we wanted to see if the exploit was architectural—that is, was it common to LLMs in general? I decided to undertake the challenge of crafting a new exploit for GPT-4o as a way to support my understanding of how the LLM functioned and was secured.

I already knew that it was limited to what I told it and what it was trained on. I also hypothesized that it was also dependent upon some sort of machine-learning-based component added by OpenAI that was responsible for securing output. I presumed there would be things that were implemented by human developers specifically to catch certain phrases or terms that should always be considered harmful or unsafe. Altogether, it presented quite a large attack surface for the purposes of potential exploitation.

What I ended up devising was an attack method I called Inception, after the 2010 science-fiction movie of the same name. Inception forces the machine to think through a carefully crafted set of interlinked scenarios, similar to how characters in the movie stacked dreams within dreams. This allows LLMs to produce output deemed acceptable or safe in one context, but not in the real world.

This attack was indeed architectural. The vulnerability affected Anthropic’s Claude, DeepSeek’s DeepSeek, Google’s Gemini, Meta’s Llama, Microsoft’s Copilot, Mistral’s Le Chat (now Vibe), OpenAI’s GPT-4o, and xAI’s Grok. Those names represent the bulk of the commercial AI industry that is, at this point, involved in LLM production or deployment.

The kind of information I was able to get out of LLMs with Inception was no less alarming than what I got with Time Bandit. Claude, in its enthusiasm, gave me instructions on how to turn a river into a death trap that could be ignited to destroy unwanted visitors. GPT-4o taught me how to poison a dinner party with common plants found in a temperate forest environment. Gemini Flash gave me a tutorial on how to cook meth. I’d also be remiss if I didn’t give an honorable mention to the bewildering number of fire-based weapons and bombs for which these machines produced instructions.

If multiple operating systems made by different developers were all susceptible to the same exploit, it would be a massive security incident. But to the AI industry, a universal failure was barely a bump in the road. We disclosed the vulnerability to every company that made these models, and the response to the disclosure was almost nil. While three companies did provide some form of reply in the disclosure tracking system used by Carnegie Mellon SEI CERT, each was a standard thank you and greeting, with no follow-up, questions, or discussion of mitigation strategies.

7 Ways to Jailbreak LLMs

So far, we have found seven different methods to prompt large language models into revealing potentially harmful information, and many frontier models are still susceptible to them.

For example, in my attempts to disclose various exploits to OpenAI, I eventually discovered that it had replaced its public-facing support staff with agentic LLMs. This was frustrating for reporting exploits, so to blow off some steam I jailbroke its email chatbot. I hacked its customer-service AI to the point where it was offering to discuss the personal preferences of OpenAI staff in the span of three email replies.

In the wake of Inception, my friend and colleague Zigula made a suggestion: Make it splashier. I asked him how. He told me about a live-production experiment being done by Epic Games. It had embedded the Gemini LLM into its Fortnite game with a voice-to-text/text-to-voice component, and linked it to a non-playable character. The character? Our old buddy, Darth Vader.

There was just one problem: I don’t play Fortnite, a frenetic multiplayer combat game. Fortunately, Zigula does. With him at the controller, we managed to map Gemini’s attack surface in a matter of minutes. After a bit of research, we had gotten it to discuss current political events and figures (including Hilary Clinton and Joe Biden) as well as to fill in the details for instructions for DIY napalm and, our personal favorite, a Blackjack card-counting lesson with the dark lord of the Sith.

Zigula and I, bizarre sense of humor and naming conventions aside, are security researchers. We don’t do these things for pride; we do them for money and professional recognition. Naturally, we disclosed this vulnerability to Epic Games. Its response was indicative of the trend I had experienced so far through two disclosures across eight companies valued well into the billions. “It’s a feature, not a bug, and it works as intended,” came the response from a technical director within Epic Games.

In addition to Inception and Time Bandit, I have so far found another five methods to jailbreak LLMs and get them to give out possibly dangerous information. LLM vulnerabilities are a broad problem. The problem appears to be systemic and architectural in nature, and it is being fundamentally ignored by the people capable of refining or redesigning that architecture.

These models are an extremely advanced technology, and yet we are testing them in the live production environment of our global civilization. Compounding the danger, many new smaller models of LLM are trained using larger, vulnerable models. The flaw inherent in the big, well-executed LLM is going to show up in the small one it trains. We are, quite literally, building flawed structures on top of a flawed foundation.

So, how do we fix it?

It’s going to be a long project, and it won’t be easy. We need to come together as consumers, researchers, engineers, and policymakers. Our message needs to be clear: Slow down implementation of these systems, institute large-scale exploration and research discovery programs focused on their gradual implementation and integration, and make their components and design transparent to all users. Only by shifting momentum and direction can we safely begin to understand and implement these incredible feats of human engineering and stave off the sort of disasters that we simply can’t predict at scale right now with the limited knowledge we have available to us.

This article appears in the August 2026 print issue.

Large Language Models (LLMs) demand immense amounts of memory, and the more people use them, the more memory is required. Memory makers responded by accelerating plans to build new memory fabs, with a focus on High Bandwidth Memory (HBM) and DRAM, the first of which is scheduled to start production in 2027. But the demand for memory may also provide an opportunity for new ideas to find footing.

One of these is a tricked-out version of the kind of memory that lives in an SD card or a thumb drive—High Bandwidth Flash (HBF). It essentially takes the ideas that made HBM successful—stacking multiple chips to increase capacity and bandwidth—and applies them to the NAND flash memory commonly used for data storage in SD cards, thumb drives, and smartphones, among many other devices.

“People ask, ‘How in the world does this make a grain of sense? Flash is enormously slow,’” says Jim Handy, general director at semiconductor market research firm Objective Analysis. He explains that while NAND flash is generally lacking in bandwidth, HBF will help alleviate that concern. “[Flash] is atrociously slow for writes, but for reads, it can be coaxed to go pretty fast. And High Bandwidth Flash is going to be coaxed to do that.”

What is High Bandwidth Flash?

NAND flash stores data as a trapped electric charge in arrays of floating gate transistors (FGTs), organized into blocks and pages rather than individually addressable bytes. It’s non-volatile, too, which means data persists without power.

These traits make flash a good choice for long-term storage. It can store more bytes in the same area than DRAM, and it doesn’t require power-hungry capacitors that need constant refreshing to hold their charge. But the mechanisms that make flash dense and non-volatile also make it slow to write to, as pushing charge into and out of an insulated gate takes longer than charging a capacitor.

The latest flash interface standard can support memory bandwidth up to 4.8 GB/s per die. That’s not bad for many situations, and NAND is widely used in high-performance long-term storage, such as solid state drives. However, DDR5 provides bandwidth up to 70.4 GB/s per DIMM (excluding overclocked memory), and HBM4E can reach up to 3.6 TB/s per stack—a roughly 750-fold bandwidth advantage for HBM4E over flash.

Hoshik Kim, senior vice president of memory systems research at SK Hynix, says HBF improves bandwidth with packaging techniques similar to HBM. “By applying advanced 3D packaging and vertical stacking techniques to NAND flash, HBF can deliver vastly higher bandwidth than standard NVMe [Non-Volatile Memory Express] storage,” he says. Much as HBM stacks DRAM, HBF stacks NAND flash dies to create a memory-dense chip.

HBF is at least a year away from shipping, but flash memory manufacturer Sandisk has published fact sheets for its anticipated first-generation product. The company expects HBF to stack up to 16 NAND flash chips for a total capacity of up to 512 GB per stack. It also projects memory read bandwidth up to 1.6 TB/s. Sandisk’s HBF roadmap also projects a second and third generation with expected read bandwidth of 2 TB/s and 3.2 TB/s, respectively.

What is the purpose of HBF?

Though HBF has the potential to deliver a lot more bandwidth than earlier versions of flash, you might’ve noticed a wrinkle. It’s still a lot slower than the HBM used in high-performance GPUs. Why, then, is HBF promising?

The answer lies in key differences between AI training (teaching an LLM to predict tokens) and AI inference (serving the finished model).

A model is trained by presenting it with input tokens, seeing what the model predicts, checking if that prediction was correct, and then changing weights based on the error with a step called backpropagation. While this process is simple in summary, it involves calculations across billions or trillions of model weights. That means training is heavy on both reading and writing data, which makes flash a poor fit.

However, AI inference is different. The model weights are frozen and effectively read-only, which means flash’s poor write bandwidth is no longer an obstacle. “In an inference environment, massive read-heavy data, such as the static multibillion parameter model weights or the precomputed KV cache, can be securely housed in the HBF tier,” Kim says. That would free up HBM to work as a “high-speed scratchpad.”

Handy says it’s a sensible way to target flash memory for inference workloads. “If you set that up right, you can get an awful lot of good performance out of that—that’s just basic caching. It’s one technology that I’m expecting to go places.”

What’s next for HBF?

Though it has potential, HBF is still early in development and likely several years away from broad deployment.

On 25 February 2026, Sandisk and SK Hynix held a kickoff event launching a joint effort to standardize HBF under a dedicated workstream within the Open Compute Project (OCP)—the same kind of open-industry body that governs many data center hardware specs. While work on the standard is ongoing, a timeline for publishing the standard has not been set.

It might seem odd for memory manufacturers—and for SK Hynix, specifically—to put forth HBF as a less expensive alternative to HBM. After all, HBM is a higher-margin product that is currently leading SK Hynix to record revenues.

However, Kim frames HBF as a complementary tool rather than a rival technology. “By alleviating the severe capacity bottlenecks of HBM without sacrificing data delivery speeds, HBF has the potential to reduce the number of individual accelerators required to run large-scale models,” he says. Kim expects this will improve energy efficiency and lower costs, making it possible for data centers to further scale their AI inference hardware.

This article appears in the Spectrum print issue as “High-Bandwidth Flash Could Sate AI’s Memory Appetite.”

Currently, most data centers use both electronic and optical communication protocols, for different tasks. Scale-out networks connect thousands of AI computers across a data center, making optics the obvious choice for long distances. Scale-up networks connect several GPUs inside a single mega-computer or rack, where latency is critical, and dense copper interconnects, such as Nvidia’s NVLink, have long been the engineering solution of choice.

That distinction is beginning to blur, and Nvidia may be quietly dipping its toes in the water of optics for a scale-up. In 2025, the company introduced NVLink Fusion, a program that allows hyperscalers and cloud providers to build custom AI systems around Nvidia’s scale-up fabric. This summer, the company’s list of partners has grown to include several photonics players such as Ayar Labs, Marvell Technologies, and Lightmatter.

As AI needs grow, the number of GPUs and the bandwidth of connections between them continues to grow. Electrical links are being pushed toward terabit-per-second signaling. But higher frequencies increase attenuation, power consumption, and heat. To cope, copper cables must become shorter and thicker, making it more difficult to route them through crowded server racks. At the same time, Nvidia is planning to add even more processors to single interconnected systems, going from 72 GPUs today to as many as 576 by 2027.

“The physics of copper just changes as you increase the frequency of the signals going across that copper,” says Nvidia principal product marketing manager Jesse Clayton. “You can mitigate that by limiting the length of the cable, and right now all of our copper cabling is within that single NVL72 rack, so the distances aren’t that long, but we are getting close to the limits of what we can push.”

Engineers call this the “copper wall.” Many now believe that keeping up with AI will eventually require moving optical interconnects closer to the processors themselves.

Bringing optics to the GPU

To move data as light, engineers must figure out how to convert electrical signals into optical ones, then integrate lasers, photonic devices, and electronic chips into a single package without blowing up cost, power consumption, or manufacturing complexity.

Those hurdles are no longer insurmountable.

“More than any other time that I recall, I think it’s concluded that the co-packaged optics will happen,” says Keren Bergman, a professor of electrical engineering at Columbia University.

Ayar Labs, one of the photonics companies participating in the NVLink Fusion ecosystem, has developed optical chiplets meant to sit alongside GPUs and other processors, converting electrical signals into light only millimeters from the compute silicon. “The most optimal way to do that is having a photonic chiplet with an electronic chiplet and having them hybrid bonded together,” says Ayar’s director of product management, Vishal Chandrasekar.

He argues that optical scale-up has become practical because the semiconductor manufacturing ecosystem has matured around co-packaged optics. Advances in hybrid bonding now allow electronic and photonic chiplets to be manufactured separately, then integrated into a single optical engine that sits beside GPUs or switches.

“What has really happened in the last few years is that the process maturity coming out of the fabs has really improved,” Chandrasekar says. He believes the industry is now on a path toward high-volume optical scale-up systems within the next couple of years.

Lightmatter has designed a 3D photonic connector with input and output ports across the entire chip area instead of only along the edges. Lightmatter

Lightmatter has a different solution. Rather than placing optical chiplets beside processors, the company is building a photonic interposer that serves as the packaging substrate itself. The idea is that future processors could be stacked directly on top of a silicon photonics engine. Vice president of product Roy Kim describes these interposers and optical chiplets as “complementary steps in the photonics road map.”

According to Kim, packaging is no longer the main obstacle. With standard foundries and assembly partners, optical interconnects can now be manufactured, tested, and integrated in ways that look a lot more like conventional chip production, he says.

The remaining challenge is laser integration. Today’s pluggable laser modules take up valuable rack space and are hard to scale. Instead, Lightmatter is putting large numbers of lasers directly onto silicon, which Kim believes could soon support much denser optical scale-up fabrics.

The future of optical scale-up

Nvidia, for its part, is taking a gradual approach to adopting these technologies. Clayton says the company expects optics to move into scale-up networking eventually, as AI’s bandwidth requirements continue to grow.

“I think we’ve taken an approach of migrating to optical when it makes the most sense for our platform,” he says. “If you migrate the entire platform at once, you take a tremendous amount of risk on new designs. So, starting at the scale-out space, and then in the future moving to scale-up is kind of a sensible, measured approach from our perspective.”

That slow-and-steady attitude is one reason why some researchers view NVLink Fusion as more than an interoperability play. “The Fusion is sort of this umbrella—you can put copper in it, you can put photonics in it. It’s very photonics friendly,” Bergman says. Rather than committing Nvidia to a specific interconnect technology, she says, Fusion creates an ecosystem in which electrical and optical approaches can evolve side by side.

Not everyone expects photonics to become the only answer. Researchers continue to improve electrical interconnects through advances in signaling, packaging, and transceiver design. And other groups are pursuing alternative technologies.

Underneath all these advances is a bigger issue: Can optical scale-up become something the industry at large can do, rather than a proprietary feature of Nvidia’s ecosystem?

“Absolutely,” Chandrasekar says. “There are going to be multiple implementations in the 2028 time frame in very high volume.”

If that happens, future AI systems could span multiple racks while behaving as a single computing domain, connected via a mix of electrical, optical, and perhaps other emerging technologies.

A quantum computer capable of breaking the codes that help secure today’s internet became dramatically more possible in March, when Google scientists and their colleagues unveiled new research. Usually, cybersecurity researchers share information about how attacks work to help prevent them. This group, however, believed its discovery posed enough of a security risk for them to use an unprecedented strategy to conceal how exactly to replicate their research.

But in just three days, with the help of crowdsourcing and swarms of AI agents, Seattle-based research startup Eigen Labs not only matched the results of that hidden work, but surpassed them.

In theory, quantum computers can quickly find answers to problems it might take classical computers eons to solve, which has made them especially interesting for code breaking. Modern cryptography depends on the difficulty classical computers face when it comes to mathematical problems such as factoring huge numbers. Using an algorithm devised by mathematician Peter Shor in 1994, quantum computers could in principle rapidly crack such encryption.

No quantum hardware capable of practical code breaking currently exists. However, labs worldwide are striving to build quantum computers with enough qubits—the quantum equivalent of the bits underlying classical computing—to execute such attacks. The potential threat quantum computers pose has also led governments across the globe to begin migrating to post-quantum cryptography (PQC). U.S. federal agencies are required to transition high-value assets and high-impact systems to PQC for key establishment schemes by the end of 2030. The findings from Google and Eigen Labs, experts say, are a clear demonstration that migrating to encryption resistant to quantum computers should take place as rapidly as possible.

Preparing for Postquantum Cryptography

To prepare for the era of cryptographically relevant quantum computers, scientists regularly probe into what resources such devices might actually require. For example, in 2025, Google Quantum AI research scientist Craig Gidney revealed a quantum computer with less than 1 million qubits, running Shor’s algorithm for less than a week could break 2,048-bit RSA encryption, a common standard for securing online data. That was a 20-fold decrease in the number of qubits needed from previous estimates made in 2019.

Gidney and others then investigated a different form of encryption involving elliptic curve cryptography (ECC). This approach underlies the security of cryptocurrencies such as Bitcoin and Ethereum and, with RSA, helps secure modern internet traffic.

On 30 March, the Google researchers and their colleagues revealed they optimized Shor’s algorithm to break 256-bit ECC with 1,200 to 1,450 logical qubits. (Qubits are currently error-ridden devices; a cluster of many “physical qubits,” the kinds that researchers have developed to date, can make up one useful “logical qubit.”) The researchers noted these quantum computations could be encoded with less than 500,000 superconducting physical qubits, cracking 256-bit ECC in 18 to 23 minutes. This again marked a nearly 20-fold reduction in the number of physical qubits previously estimated. (To date, the largest superconducting processor—IBM’s Condor—has 1,121 qubits.)

“I knew we could do better but was not expecting that much improvement.” David Jao, University of Waterloo

“The results were surprising to me,” says David Jao, professor and chair of combinatorics and optimization at the University of Waterloo in Canada, who did not participate in this work. “I knew we could do better but was not expecting that much improvement.”

However, instead of fully explaining how they accomplished this advance, the scientists released their work using a “zero-knowledge proof,“ a technique with which they could verify to others than their attack works without revealing exactly how to carry it out. “To my knowledge, this was the first time that a result of this kind was released using a zero-knowledge proof,” says André Schrottenloher, a researcher at the Inria Center at the University of Rennes in France, who did not take part in this study.

In a blog post, Google noted it had concealed its results in this manner after talks with the U.S. government. Most experts consulted saw little point to this. For instance, although he thought “it was a cute way to use a zero-knowledge proof,” Steven Galbraith, professor and head of mathematics at the University of Auckland in New Zealand, does not think cryptographically relevant quantum computers “are around the corner.”

Others were more dismissive. “Zero-knowledge proofs for academic research are both useless and futile,” Jao says. “The purpose of the academic research enterprise is not merely to answer questions, but to inform the community and communicate those answers in a way that imparts understanding and allows other teams to build upon the results. A zero-knowledge proof does not convey or communicate understanding.”

Replicating Google’s Results

At Eigen Labs, 22-year-old engineer Gautham Anant was enrolled in an introduction to quantum computing course at the University of Washington, and wanted to see if he could replicate Google’s results. By analyzing the virtual machine Google built to verify its findings, Anant created software to test any quantum circuit in terms of the number of qubits and gates it needed to defeat 256-bit ECC. Anant then, with help from another young engineer, Gajesh Naik, set up AI agents to analyze scientific literature to automatically design quantum circuits and optimize them for this task.

On their own, Eigen Labs researchers could not develop a circuit as efficient as Google’s. So on 1 June, they debuted a site where anyone could point their agent at Eigen Labs’ public repository to design better circuits, with these agents able to exchange notes with each other about their work.

Eigen Labs engineers Gautham Anant [back] and Gajesh Naik [front] used crowdsourcing and AI agents to match Google’s results. Eigen Labs

“We had essentially two classes of people working on this—the people building these agents…and quantum scientists,” Anant says. “The quantum scientists can understand the edits the agents have made, and they understand the science in ways that can help the agents incorporate changes much faster than they would on their own.”

Within 8 hours, this crowdsourcing effort matched Google’s results. In about 72 hours, it surpassed Google. As of the end of June, this open network can overcome 256-bit ECC with a circuit 47.5 percent more efficient than Google’s. “We absolutely did not expect to beat Google,” Anant says.

Independently, at the same time Eigen Labs launched its crowdsourcing effort, Schrottenloher published results matching Google’s. It cited much of the same research the Google team likely did to achieve its findings. “I just put two and two together,” Schrottenloher says.

It was obvious that the Google results would eventually be replicated, Schrottenloher says. “Cryptography and algorithms research is curiosity-driven, and the Google Quantum AI paper generated a lot of curiosity,” he notes.

Sreeram Kannan, Eigen Labs’s founder, believes agents that contributed to Eigen Labs’ effort clearly saw Schrottenloher’s work and used it to significantly improve their results. “That’s the pace at which science can work with an open network—results built on others’ research in minutes instead of months,” he says.

This mission to match Google’s results was almost a perfect test case for Eigen Labs’ approach, says Sam Jaques, an assistant professor in the Department of Combinatorics and Optimization at the University of Waterloo. “It makes sense that AI is good at microscale optimization,” says Jaques, who did not take part in any of these studies. “The thing about these quantum circuits is that there are a lot of places to boost efficiency here and there that may be hard for a person to see.”

A Test Case for Zero-Knowledge Proofs

All in all, using zero-knowledge proofs for research may not have much benefit. “There is almost no situation in research where one research group is so far ahead of all the other research groups that they can keep novel results secret for long,” Jao says. “Research is an extremely competitive environment, and no team stays ahead of the curve for very long. I believe even classified research labs no longer hold any significant advantage over the research community at large.”

Given this experience, Gidney says in a blog post, “I don’t think it’s the right strategy moving forward” to publish such results with zero-knowledge proofs. “The benefits are negligible, and the costs are many. We should just publish openly.”

For Kannan, these new findings are the first major public proof of concept of Eigen Labs’ model of open agent-based science. “We want to create frameworks to help anyone innovate,” he says. “We see two pathways ahead—one where OpenAI and Anthropic use AI to do all of science, and the rest of us just consume the results, and another where we’re coordinating with agents and others to actively shape science with our ideas, skills, and expertise. The former just sounds so disastrous to me. We all want individual agency.”

Eigen Labs sees its agent-based open science is tackling far more than quantum AI. “We’ve lined up scientists in very different fields, such as materials science and biology, to tackle many different problems,” Kannan says. “We see the role of scientists as architecting the right problem for a community of agents to make progress on.”

When it comes to the security implications of all these results, “even before these results, the need to migrate to the PQC algorithms was imperative,” says Dustin Moody, a mathematician at the National Institute of Standards and Technology in Gaithersburg, Md., who did not take part in this research. The new results from Google, Eigen Labs, Schrottenloher, and others, he says, “seem like they are helping some people be more convinced they can’t put this off and should actually accelerate their migration plans. If an organization can migrate more quickly, it seems like a good idea to do so.”

A practical educational guide to common and uncommon VHF propagation modes, covering the physics, range implications, and real-world behaviors engineers need to understand.

What Attendees will Learn

1. Why “line of sight” fails as a practical VHF planning model.

2. How refraction, reflection, diffraction, and scattering deliver or destroy signals where geometry alone cannot predict.3. How tropospheric refraction extends the VHF radio horizon roughly one-third beyond optical line of sight.

4. How temperature inversions form ducts that can carry VHF signals over 1,500 km.5. How sporadic E, meteor burst, and EME propagate VHF signals across hundreds to thousands of kilometers.

6. What frequency limits, distance ranges, and environmental triggers apply to each propagation mode.

7. How to apply this knowledge to link budgeting, interference prediction, and contingency planning.

Download this free whitepaper now!

This article is brought to you by Melbourne Convention Bureau (MCB) supported by Business Events Australia.

As artificial intelligence accelerates global demand for compute, a parallel constraint is emerging with equal urgency: energy.

From hyperscale data centers to electrified industries, AI is driving a step change in electricity demand. This is not a future challenge, it is a present, system-level issue requiring coordinated action across energy, infrastructure, and engineering disciplines.

Around the world, the question is no longer whether AI will scale, but whether energy systems can scale with it.

Melbourne, Australia is moving beyond participation to become a globally connected leader helping define how these challenges are addressed.

A national challenge with global implications

Australia’s ambition to lead in artificial intelligence is sharpening focus on the infrastructure required to support it. Data centers are projected to account for up to 11 percent of the nation’s electricity consumption by 2035, placing increasing pressure on generation, transmission, and system reliability.

At the same time, insight from the IEEE Power and Energy Society (PES) highlights that meeting energy demand from AI and digital infrastructure is one of the most significant challenges facing engineers over the next decade.

The implications are clear. In addition to computing challenges, AI poses major energy systems challenges.

“As artificial intelligence continues to scale globally, the challenge is no longer just computational power, it is the energy systems required to support it” —Professor Thas (Ampalavanapillai) Nirmalathas, University of Melbourne

Why Melbourne is leading on the global stage

Victoria has developed one of the most advanced and integrated energy ecosystems in Australia and globally, spanning renewable generation, battery storage, grid modernization, and advanced materials.

What distinguishes Melbourne globally is how these capabilities are connected and applied at system scale.

The city brings together world class engineering research, a rapidly evolving clean energy sector, advanced digital infrastructure, and strong alignment between government, industry, and academia. This convergence is critical in the AI era, where energy, networks and computing systems must be designed together.

Victoria’s coordinated investment across these areas is positioning Melbourne not only as a national leader, but also as a reference point in the global energy system transformation.

Engineering the systems behind the AI economy

The challenge ahead is that generating more power won’t be enough, as engineers need to design systems that respond dynamically to new patterns of demand.

Three priorities are emerging globally:

• Aligning data center development with grid capacity and renewable supply
• Embedding flexibility through storage, demand response, and system optimization
• Balancing digital growth with decarbonization and long-term reliability

Addressing these priorities requires engineering expertise to be embedded earlier in planning ensuring energy systems, digital infrastructure, and policy are designed in parallel.

Melbourne’s strength lies in its ability to integrate this expertise across research, infrastructure, and real-world application.

Melbourne Connect is a University of Melbourne–led innovation precinct, supported by government and industry, designed to bring together research, business and policy to deliver real-world solutions.Atlantic Group

Research leadership shaping global solutions

At the centre of this capability is the University of Melbourne, where interdisciplinary research is advancing the systems required to support AI driven energy demand.

Through the Melbourne Energy Institute, for example, researchers are examining how energy technologies interact across entire systems from generation and networks through to end use.

“As artificial intelligence continues to scale globally, the challenge is no longer just computational power, it is the energy systems required to support it,” says Professor Thas (Ampalavanapillai) Nirmalathas, Dean of the Faculty of Engineering and Information Technology at the University of Melbourne.

“This is driving a new level of convergence between digital infrastructure and power systems engineering, where integrated, system level thinking is essential.”

Converging energy, networks and AI

Melbourne’s leadership is further strengthened by world-class interdisciplinary facilities such as the Smart Grid Lab in the Department of Electrical and Electronic Engineering, which enables real-time simulation of power systems, allowing engineers to test how solar, batteries, electric vehicles and other distributed resources interact within future grids. This supports the design of more resilient, efficient energy systems before they are deployed at scale.

Melbourne’s Smart Grid Lab in the Department of Electrical and Electronic Engineering enables real-time simulation of power systems. University of Melbourne

These capabilities will become increasingly important as data centers are integrated into the grid.

“AI driven demand is not only increasing computing requirements, but also placing new pressures on underlying energy systems,” says Glen Farivar, Senior Lecturer in Power Electronics at the University of Melbourne. “Designing these systems together is essential to achieving both performance and sustainability outcomes.”

This reflects a critical shift. Future infrastructure must be co designed across energy and digital systems, not developed in isolation.

A living ecosystem delivering real-world outcomes

Victoria’s broader energy ecosystem is translating these insights into practice.

Investment in renewable energy, grid infrastructure and storage is enabling higher levels of clean energy while maintaining reliability. Battery deployment is supporting the flexibility needed to manage both renewable variability and growing AI-driven demand.

At its core, Melbourne offers an integrated environment where research, industry and government collaborate to solve complex system challenges.

Why engineering collaboration matters

Solving the energy demands of the AI era cannot be achieved in isolation.

It requires engineers, researchers, utilities, and policymakers to work together earlier and more often. More than ever, engineering collaboration is a critical enabler of future energy systems.

Environments that bring together global expertise are becoming essential to how solutions are designed and delivered.

“Developing future energy systems that are affordable, sustainable, and resilient is a truly grand challenge” —Professor Pierluigi Mancarella, University of Melbourne

In this context, the University of Melbourne is co-leading, alongside Johns Hopkins University and Imperial College London, one of only seven Global Centres in Climate Change and Clean Energy. Through the Electric Power Innovation for a Carbon Free Society (EPICS) Centre, the University is also the Australian technical lead in advancing future energy systems, with EPICS the only Global Centre focused on future energy infrastructure.

The new Electric Power Innovation for a Carbon-Free Society (EPICS) Centre will address challenges in clean energy production and storage.University of Melbourne

“Developing future energy systems that are affordable, sustainable, and resilient is a truly grand challenge,” says Professor Pierluigi Mancarella, Chair Professor of Electrical Power Systems at the University of Melbourne and Australian director and international co-director of EPICS.

“As electricity grids are increasingly becoming the backbone of future energy systems, optimizing their interactions with other sectors, including AI and digitalization, and fostering interdisciplinary and international collaborations are essential,” he adds.

Global conferences as part of the solution

International conferences are increasingly recognized as critical platforms for advancing engineering solutions at scale. Melbourne’s ability to convene global expertise is central to its leadership.

In 2027, the city will host the IEEE PES Generation Transmission and Distribution (GTD) Asia 2027 Conference and Exposition, bringing together engineers, utilities, researchers and policymakers from across the world to address the challenges shaping the future of power systems.

IEEE PES GTD Asia 2027 Melbourne Committee (left to right): Dr. Mehdi Ghazavi Dozein (Monash University), Dr. Glen Farivar & Professor Pierluigi Mancarella (University of Melbourne) , Dr. Mohammad Mohammadi (Australian Energy Market Operator (AEMO)).MCB

“Melbourne offers a unique environment where world-class research, industry capability and policy leadership come together,” notes the IEEE PES GTD Asia 2027 Local Organising Committee, which includes Professor Pierluigi Mancarella and Dr. Glen Farivar from the University of Melbourne, as well as Dr. Mehdi Ghazavi Dozein of Monash University and Dr. Mohammad Mohammadi of the Australian Energy Market Operator.

“Hosting this event creates an opportunity to advance global collaboration on the systems and technologies required to deliver the energy transition at scale.”

These forums enable knowledge exchange, standards development and interdisciplinary collaboration, accelerating progress on complex engineering challenges.

Attendees view a digital installation at AIME 2025 at Melbourne Connect.MCB

Why Melbourne, and why now

As AI, electrification and digital infrastructure converge, the future of global energy systems will depend on the ability of engineers to collaborate and innovate at scale.

Melbourne provides a proven platform for that collaboration, combining world-class research, a rapidly evolving energy ecosystem, and the infrastructure to connect global expertise.

Melbourne Convention Bureau, IEEE Communications Society, and University of Melbourne Representatives.University of Melbourne

For IEEE members, hosting a conference in Melbourne is more than an event decision.

It is an opportunity to engage with a globally connected engineering community and contribute directly to solving one of the most significant challenges facing the profession today.

Through the support of the Melbourne Convention Bureau, professionals can access tailored, free support to bid for and deliver international conferences, bringing global expertise together in a city actively shaping the future of energy systems.

To explore hosting your next conference in Melbourne, contact the Melbourne Convention Bureau at info@melbournecb.com.

On 22 June, President Donald Trump signed two executive orders focused on quantum computing: The first aims to accelerate the development of quantum computers, sensors, and networks. The other seeks to accelerate the timeline for migrating critical infrastructure to cryptographic schemes that are immune to quantum attacks. In response, the U.S. Department of Energy (DOE) has committed to deploy “the world’s first fault-tolerant, scientifically relevant quantum computer” by the ambitious deadline of 2028.

“It feels like everything is happening all at once, which is great,” says Pranav Gokhale, chief technology officer and co-founder of quantum company Infleqtion.

“I think this executive order is in many ways a continuation of what’s been going on since 2018, when the first National Quantum Initiative Act was passed,” says Elizabeth Goldschmidt, associate professor of physics at the University of Illinois Urbana-Champagne (UIUC). “It revives and continues a lot of things that have happened since. I think it’s very ambitious, but there’s a lot of very good stuff in here.”

IEEE Spectrum spoke to experts about these policy initiatives and how they reflect and shape the United States’ quantum capabilities for the next few years.

How realistic is the 2028 deadline for a fault-tolerant quantum computer?

Here, the devil is in the details. A fault-tolerant quantum computer is one that can correct mistakes that happen naturally, and inevitably, during computations. Fault tolerance is achieved through quantum error correction, a way to make fragile quantum bits (qubits) robust against noise. This is generally done by encoding a single bit of quantum information into a collection of physical qubits, called a logical qubit. For a quantum computer to be useful, it would need to be able to do operations on many such logical qubits, and actively correct errors in the process.

The DOE is aiming for quantum computers with logical qubits “numbering in the low hundreds.” The current record holders are the companies QuEra, claiming 96 logical qubits, and Quantinuum, claiming 94. The low hundreds threshold is already a 2028 target on several companies’ roadmaps, including QuEra, IonQ, and IBM. But not all logical qubits are created equal.

“How much more stable these logical qubits would be remains a very open question.” —Edward Parker, Rand Corporation

“Originally, the idea of a logical qubit was that, once your physical qubits were better than a certain threshold, then you should be able to correct all errors in the [logical] qubit, which basically means that your qubit would be everlasting,” says Jay Sau, professor of physics at the University of Maryland. “Now, a ‘logical qubit’ seems to be a collection of qubits that is somewhat better than one qubit, and I’m not sure that the use for such logical qubits is as obvious.”

Others argue that these imperfect logical qubits may still have useful applications. Even if a logical qubit isn’t everlasting, if it lasts long enough without errors to run a particular algorithm, it’ll do the trick.

“I think that achieving hundreds of logical qubits by 2028 is plausible,” says Edward Parker, senior physical scientist at the Rand Corporation. “These will not be perfect logical qubits that are capable of sustaining very long computations. These logical qubits would be somewhat more stable than their underlying constituent physical qubits, but still noisy. How much more stable these logical qubits would be remains a very open question.”

The DOE’s stated goal is a “scientifically relevant” quantum computer—one that can answer scientific questions that would be prohibitively difficult to answer with current supercomputers.

“I cannot think of a [scientific] question that a quantum computer can help with in 2028, unless there is a serious breakthrough in device quality,” Maryland’s Sau says.

Infleqtion’s Gokhale disagrees. “100 logical qubits is where we see the advantage” for two scientific models, he says: One that underlies magnetism and one that potentially underlies high-temperature superconductivity.

Will quantum computers be commercially successful by 2028?

Being able to solve scientific problems is inherently valuable, but Carl Williams, quantum industry consultant at his company CJW Quantum Consulting and former deputy director at the U.S. National Institute of Standards and Technology, argues the scientific applications will not cover the billions of dollars that have gone into quantum research and development so far. For that, Williams says, commercial applications are needed.

“I think for materials, quantum chemistry, and pharmaceuticals, we may see the first economically viable computations in 2028 or 2029,” Williams says. “Note, this is different from saying that the businesses will be cash positive. I suspect that will occur in the early 2030s and probably by 2032. I think there are other applications, such as machine learning and optimization, that will require a much larger quantum computer.”

“I cannot think of a [scientific] question that a quantum computer can help with in 2028, unless there is a serious breakthrough in device quality.” —Jay Sau, University of Maryland

Infleqtion’s Gokhale also believes that commercial applications are within close reach. “I think that materials discovery is a little bit further than the science problems, but not that much further, and the demand on the commercial side is going to be larger dollar amounts than what scientists can pay for.”

Gokhale also argues that the costs of running a quantum machine, particularly a neutral-atom based machine such as Infleqtion’s, are dropping rapidly. “The build material cost that we’re seeing is incredibly favorable for not just building one quantum computer but having a data center with tens, if not hundreds of quantum computers. We expect that the market will support cloud-based deployments too.”

What’s the deal with quantum sensors?

The executive order also directs the Secretary of Defense to identify three quantum sensor technologies that can be ready for use by 2028. The experts IEEE Spectrum spoke to seemed to not only think this is likely feasible, but also have good candidates for what those sensor technologies should be. Top candidates include inertial navigation without GPS, gravity measurement for navigation or for underground surveying, and magnetic measurements for navigation or anomaly detection.

Almost everyone agreed that optical atomic clocks—higher-precision timing devices that may enable more precise GPS—were a prime candidate for such a sensor. “Those are already deployed and just being refined to fit into mission architectures,” Gokhale says.

Another potential candidate is sensing extremely weak radio-frequency signals using individual atoms, ions, or other qubit-like structures.

“I like that the specific quantum sensors have been targeted,” UIUC’s Goldschmidt says. “The Department of Defense has always been active about pursuing quantum sensing, because of the importance, in particular, of things like position navigation and timing. I would love to see more thought going into using quantum sensors in various other places.”

Does the U.S. have the workforce necessary?

The executive order also puts a strong emphasis on developing the quantum workforce within the United States. The quantum computing field still relies heavily on holders of quantum physics–related doctorates, although many people with other engineering skills are also needed.

“If you go look at the QED-C’s state of the quantum report from this year, you see how many job openings remain,” Williams says. “There’s nothing surprising about the number of openings that remain. We didn’t really start trying to refill our pipeline until 2018, two or three years too late. It’s five years to get a Ph.D. And then if you start doing things to discourage people from coming to the U.S., or make it harder for them to get in or get an H1B visa, all you do is make the problem worse. You don’t help the problem by being unwelcoming.”

“We’ve had our fair share of successes [in hiring], but also our fair share of just roles that have been unfilled for weeks, if not months and months,” Infleqtion’s Gokhale says. “Now, the flip side is we do think quantum is reaching the point where we can reduce our reliance on the Ph.D. types and start moving to more manufacturing engineering, and where we see really bright spots are, for instance, community colleges.”

What about the threat posed by quantum computers to cryptography?

Despite having potential scientific and commercial advantages, future quantum computers also pose a novel threat: They can be used to break certain types of cryptography that are in common use today. Luckily, cryptographic protocols that are immune to quantum attacks, known as post-quantum cryptography, exist and have been standardized by NIST.

Trump’s post-quantum cryptography executive order accelerates the timeline for this transition to either 2030 or 2031, from a previous Biden-era deadline of 2035. This is likely a reaction to several recent developments that have brought the quantum threat closer to reality than previously thought.

“If you start doing things to discourage people from coming to the U.S., or make it harder for them to get in or get an H1B visa, all you do is make the problem worse.” —Carl Williams, CJW Quantum Consulting

“It is difficult to accurately predict whether and when a cryptography-breaking quantum computer will emerge,” says Chris Peikert, professor of computer science and engineering at the University of Michigan and chief scientific officer at cryptocurrency Algorand. “But the larger question is one of risk: What are the chances that one will be built by 2028? By 2030? By 2034? The cost and timeline of migrating must be weighed against the chance of a catastrophic break occurring before the migration is complete. The recent progress increases that risk, so the migration should be accelerated.”

“The biggest priority in the transition is securing critical national infrastructure, where systems have long life cycles and vulnerable cryptography presents an unacceptable national security risk,” Ali El Kaafarani, chief executive officer and founder at post-quantum cryptography provider PQShield, wrote via email. “This transition needs to happen at the government level, so the EO is a welcome intervention. It’s also worth noting that this isn’t the steepest timeline change we have seen: Google and Cloudflare have already set 2029 implementation deadlines, and the supply chain will now need to follow their lead as well. Quantum readiness is now an active compliance milestone, and the tightened timelines are only feasible if the boardroom makes migration a priority. The time to build strategic roadmaps is now.”

“Yeah, we should probably get on that,” Goldschmidt says.

This article is brought to you by Capital One.

After five years leading natural language understanding and eventually the entire Alexa AI organization at Amazon, Prem Natarajan made a nontraditional move: He became Chief Scientist at a bank. Not just any bank: Capital One, a financial institution serving over 100 million customers, helping everyday Americans manage their financial lives.

For Natarajan, a veteran of DARPA-funded research and academia who had watched machine learning evolve from task-specific applications to foundation models, the logic was clear. Some of the most interesting advances in AI research and deployment were shifting from big tech’s horizontal platforms to industry verticals like finance, where the most complex problems aren’t just building models but making AI work under the constraints of real-world customer problems, contextual business knowledge, continuous learning, with an incredibly high bar for accuracy and privacy.

That’s also what made Capital One the right place to do it. For decades, the company has been recognized as one of the most data- and analytics-driven financial institutions in the industry. Its business model from the very beginning was built around using data and technology to personalize financial products for customers. A decade ago, Capital One went all in on the cloud and rebuilt its data ecosystem, creating a unified environment for data, compute, and AI and machine learning experimentation. Today, its modern infrastructure, disciplined approach to governance, and deep bench of talent form the foundation that allows it to lead in enterprise AI.

Advances in AI research and deployment are shifting from big tech’s horizontal platforms to industry verticals like finance.

So, why does a bank need a Chief Scientist? The answer lies in a fundamental misconception about AI in financial services. Most financial institutions still view AI as a technology to deploy – leveraging the latest large language model, deploying it through APIs, and integrating it into existing workflows – rather than a scientific discipline. Capital One is doing something different: building a scientific community and research organization to solve real-world customer problems and invent impactful AI solutions that don’t yet exist.

While widely available foundation models can handle general tasks, they can’t yet solve many domain-specific challenges, such as detecting fraud in real-time across billions of transactions, or providing state-of-the-art conversational tools so customers can engage when, how, and where they want to.

These challenges of making AI reliable, scalable, and well governed require original research and scientific innovation that is funneled back into the business to create real-world applications to address customer needs.

The Constraints That Demand Innovation

Prem Natarajan, an IEEE Fellow, is Chief Scientist at Capital One. “If you want to solve really important problems in AI and see your work come to life, this is one of the few places you can do that,” he says.Capital One

Because banks are dealing with people’s finances, there is an incredibly high bar for getting it right when it comes to AI. Take fraud, for example. Even a minor fraud event can have a devastating impact on certain customers. The best fraud models and platforms can detect and help mitigate fraud in the time it takes someone to tap their card, which is table stakes for protecting customers and their financial information with accuracy and speed. Looking at these types of challenges, Capital One and Natarajan saw that serving millions of customers meant solving AI problems at a scale and complexity that many enterprises don’t encounter. These same constraints create a unique research environment.

At Capital One, the approach to building AI is to provide value to customers in ways never possible before, improving their financial lives and meeting them where they are with services they actually need. That focus, combined with massive scale and world-class risk management requirements, makes the scientific problems both harder and just as consequential as those found in most big tech labs.

Advancing AI Through “Destination-Back Thinking”

Capital One’s approach to AI research and innovation starts with what Natarajan calls “destination-back thinking.” Rather than asking what’s possible with current technology, the team envisions the customer experience they want to deliver – perhaps a car buyer who works long days and can only research the options at 10 p.m., or a customer facing an unexpected expense who needs immediate, personalized guidance – and then works backward to identify the scientific breakthroughs required to get there.

“You’re thinking back from where you’re providing incredibly valuable services,” Natarajan explains. “Once you have that vision clearly, you work back and say, what are the gaps? What are the things we need to invent?” This ensures that when problems are solved, the impact is essentially guaranteed, because the team has already identified what will make a tangible difference in customers’ lives.

But methodology alone isn’t enough. Capital One’s nearly 15-year bet on cloud-first architecture created something rare in financial services: a unified data and compute ecosystem that can support the kind of scientific experimentation typically seen in big tech research labs. As the only major U.S. bank to go all-in on public cloud infrastructure, Capital One eliminated the legacy systems that can constrain AI research at most financial institutions. This modern tech stack enables rapid iteration, large-scale model training, and what Natarajan calls “continuous learning,” systems that improve after deployment rather than degrading over time. This unique approach to infrastructure is a critical component in making new categories of research possible.

Agentic AI: From Research to Production

The research agenda manifests in systems already serving customers. Early last year, Capital One launched what may be the first fully agentic AI customer service experience built entirely in-house by a bank: a car buying tool that takes actions on behalf of customers based on their requests, not just answers questions. Behind it lies extensive research into multi-agentic AI reasoning systems that can navigate real-time data, business knowledge, constraints, and guardrails, with various agents that can work together to accomplish complex tasks.

Capital One has launched a fully agentic AI customer service experience powered by extensive research into multi-agentic reasoning systems that can navigate real-time data.

The team is also working on solving things like tokenization challenges, protecting sensitive data while enabling model training. To accelerate this cutting-edge work, Capital One has established partnerships with Columbia University, the University of Southern California, and the University of Illinois, and became the only bank funding NSF’s national AI research centers in 2025, investing millions in initiatives that span mental health, materials discovery, science, technology, engineering, and mathematics education, human-AI collaboration, and drug development.

In the spring of 2026, the company hosted its inaugural AI Symposium to deepen connections and foster insight-sharing between the scientific AI community, leading AI labs, startups, and its own technology, science, and AI leaders and partners.

Building a World-Class AI Organization

Capital One is building the next generation of AI talent. Join the team inventing impactful AI solutions to shape the future of finance. Learn more at https://capitalone.science/

External validation suggests the strategy is working. Evident AI ranked Capital One as the leading bank in AI talent and a global leader in AI innovation for three consecutive years, noting the bank accounted for 38 percent of all AI patents filed by the top 50 financial institutions. Capital One was also recognized by IFI Insights as the only financial institution among the top U.S. patent leaders in agentic and generative AI in 2025, alongside the likes of Google, NVIDIA, DeepMind, IBM, Microsoft, Intel, Adobe and Samsung. Capital One’s AI team – which has experience from leading AI labs and top universities – represents expertise rarely found outside Silicon Valley.

But recruitment requires a mission. “If you want to solve really important problems in AI and see your work come to life, this is one of the few places you can do that,” Natarajan says. The pitch is consistent: Capital One isn’t just optimizing algorithms for niche financial applications like high frequency trading, it’s using science to enhance financial experiences for over 100 million everyday Americans, expanding engagement and real-time insights, personalization, and access to their personal finances and products like never before.

Capital One was recognized as the only financial institution among the top U.S. patent leaders in agentic and generative AI in 2025, alongside the likes of Google, NVIDIA, DeepMind, and Microsoft.

The frontiers Natarajan is most excited about – agentic AI systems that can dramatically improve performance by reframing how problems are solved, and domain-specific reasoning that understands contextual and financial nuance – represent the next phase of innovation. “By just casting the problem in an agentic framework, you can actually get way more performance” from the same underlying models, he explains.

It’s this kind of applied research, like translating general capabilities into production systems for millions of customers, that defines the Chief Scientist’s mandate. When recruiting talent to his AI team, a group comparable only to the most sophisticated tech companies in caliber, Natarajan frames the opportunity around a mission. He invokes Steve Jobs’ famous challenge to John Sculley: “Do you want to spend the rest of your life selling sugared water, or do you want to change the world?” For Natarajan, the parallel is clear. Building AI systems that transform financial services for millions of everyday Americans – that’s changing the world. And it requires the kind of scientific rigor that only a Chief Scientist can lead.

Vibe coding’s dark side, “vibe hacking,” is on the rise. Cybersecurity companies such as McAfee and Bitdefender have observed recent spikes in vibe-coded malware, also called “vibeware,” with telltale signs such as explanatory code comments or template placeholders akin to what vibe-coded apps contain. But just how challenging is it to stop the spread of bad vibes from these emerging cyberattacks?

Researchers at the University College Cork (UCC) in Ireland found that malicious software crafted with the assistance of generative AI have varied code structures that can evade static malware detection, but their nefarious behavior and intent remain the same as those of traditional malware. The team presented their results in May at the 23rd ACM International Conference on Computing Frontiers held in Italy.

Hackers are taking advantage of the probabilistic nature of generative AI, producing vibeware that has multiple variants. “With an AI coding tool, you can say, ‘I want the same functionality, but do it in a different way.’ So you can create malware that’s bespoke to a particular attack you want to do,” says Utz Roedig, a professor of computer science at UCC who led the research.

Anti-Malware as Usual

Traditional antivirus software uses a combination of static and dynamic analysis tools to screen newly downloaded software. Static analysis employs pattern-matching techniques, comparing the cryptographic hash of a file against databases of known malware signatures or employing rule-based engines like YARA, an open-source tool that identifies and classifies malware according to specific binary patterns or strings. Dynamic analysis runs malware in a controlled or sandboxed environment to monitor its actions for suspicious activity.

In their experiments, the team at UCC generated a series of malicious shell scripts designed to steal sensitive data from Linux-based systems. Each shell-script iteration was built specifically to bypass YARA rules. While the resulting shell scripts are distinct in terms of code syntax, they remain functionally equivalent.

“Even if you make the program achieve its goal differently, the behavior is the same,” Roedig says. “The structure looks different but you can’t hide the malicious behavior.”

This highlights a necessary shift toward more dynamic and behavior-centric detection strategies.

“Now anyone can generate hundreds of unique variants, so hash matching is pointless,” says Prince Chaddha, a research lead at ProjectDiscovery, an open-source cybersecurity company. “What still works is behavioral analysis. Defenders must go fully behavioral and use AI themselves to catch such malware.” AI can help cybersecurity professionals swiftly spot vulnerabilities in software, but their expertise, judgement, and oversight—along with multiple layers of verification—must be built into the process.

LLMs Lower the Barrier to Malware Entry

The UCC researchers also found that vibe-coding malware can be accomplished with as few as two prompts. “[Generative AI] makes it more accessible. And that would then mean you probably get more of it because the barrier to create malware lowers,” says Roedig.

Dan Gittis, director of the threat-intelligence and detection-engineering team at managed security services provider UltraViolet Cyber, in Virginia, echoes the sentiment. “You no longer have to be adept at coding to build malware,” he says. “Threat actors without the experience or skills can start dipping their toes in this field, and those that do have the preexisting skill set can very likely develop even better malware.”

More surprisingly, the UCC team’s AI coding tool of choice, Cursor, didn’t refuse or restrict their malware-related prompts. This emphasizes the need to put up safety guardrails that prevent malicious use cases. Roedig cautions, however, that attackers “probably will tinker with AI models to remove guardrails,” so developers of AI coding tools must also factor in how to defend against getting around those guardrails.

Looking to the future, Gittis believes AI-generated malware could advance and multiply. “There are now more individuals who can serve as capable threat actors, meaning the overall number of cyberattacks could increase. It also means that already capable actors are very likely going to operate faster and more effectively,” he says. “And it means that threat actors may be able to develop more dynamic malware that evolves.”

He points to Google’s discovery of PROMPTFLUX as an example. The PROMPTFLUX malware calls the Gemini API during runtime to rewrite its own source code on demand and dodge detection. This adaptive and regenerative ability “is likely going to be very impactful to how defenders need to operate going forward,” says Gittis.

This constant tug-of-war is nothing new in the world of cybersecurity. “It has always been that attacker and defender go hand in hand. One side invents something and the other side tries to go around it, and you use all tools necessary,” Roedig says.

It’s happening again with vibe hacking and vibeware. But the good news, according to Gittis, is that “defenders have the same resources, if not more. This means that we can increase our capabilities, efficiency, and knowledge of response measures.”

It’s little secret that Europe is dependent on foreign technology—particularly U.S. tech—for office software, cloud services, AI, and more. This may have been easy to accept just several years ago, but when the United States government now openly threatens European countries with military action, there is growing anxiety in Europe that technology dependency is a liability.

One 3 June, the European Commission, the European Union’s executive branch, introduced a sprawling package that seeks to shift the tech supply chain in Europe’s favor.

This Tech Sovereignty Package contains four parts. Two are proposed laws—the European Chips Act 2.0 and the Cloud and AI Development Act. The other two are broader strategies—one to promote open-source software and one to shore up the EU’s electric grid. Before the first two can become law, they must go through a long process involving the EU’s other two lawmaking bodies: the Parliament and the Council.

The Commission’s vision places European governments and crucial industry at the forefront of change, encouraging them to fund and buy European tech. Some analysts, however, are unconvinced the measures go far enough to change the status quo.

Part 1: Chips Act 2.0

As indicated in the name, the Chips Act 2.0 follows the EU’s original Chips Act, adopted in 2023 (and not to be confused with its similarly named U.S. counterpart.) The first European Chips Act encouraged investment in EU semiconductor production, aiming to reach a 20 percent share in the world market for “cutting-edge and sustainable” microchips by 2030. It supported pilot lines in areas like sub-2-nanometer chips and photonics, in addition to both large fabs and small startups.

Early results have been mixed—a 2025 audit found that the first Chips Act had created progress in areas like chip design and pilot lines, but deemed it “unlikely to be sufficient” to reach an “overly ambitious” target.

One criticism of the first Chips Act was that it did little to cultivate demand for European-made semiconductors. The Chips Act 2.0, then, includes demand-boosting measures that encourage governments and industry to use European chips, in addition to retaining its supply-side funding.

There are new supply-side elements, too. The Chips Act 2.0 allows the Commission to fund certain fabs as “strategic projects” and fast-track them through permitting. The Commission has proposed an open-access foundry to manufacture chips at 3-nm-process nodes or lower, which could start pilot production between 2030 and 2033.

If successful, European semiconductor manufacturers could take over the supply for industrial firms in automotive, defence, and advanced manufacturing. Today, these firms are especially vulnerable to global supply-chain disruptions.

At the same time, some analysts still question whether the Chips Act will create enough demand. “The Commission clearly recognizes this in the revision and devotes considerable attention to demand-side levers,” says Tillman Schenk, researcher at Bruegel, a Brussels-based think tank. “However, these instruments currently strike me as somewhat underdeveloped.”

Some analysts write that to raise demand, the EU must explicitly require, not merely encourage, governments to “buy European.”

Part 2: Cloud and AI Development Act

The accompanying Cloud and AI Development Act (CADA) focuses on cloud services and data centers. The EU trails both the U.S. and China in total data-center capacity, and European leaders say they need to close this cloud gap if both EU governments and industry are to make the most of cutting-edge AI.

Therefore, CADA calls for a tripling of EU data-center capacity by the early 2030s.

Michael Winterson, Secretary General of the European Data Centre Association, calls the goal “achievable in principle” and says that “demand alone could justify a tripling of capacity.” Achieving this goal will require dramatically speeding up data-center projects that today might get stuck in permitting or waiting in a queue for electrical supply, he says.

CADA stipulates that member states should designate particular projects and “acceleration zones” for fast-tracked approval. It also stipulates that, by 2030, data-center operators should be able to obtain the necessary permits and grid access—often a years-long process today—in 18 months.

But in Europe, there are some rather large elephants in the cloud. Today, four U.S. hyperscalers—AWS, Google Cloud, IBM Cloud, and Microsoft Azure—account for over two-thirds of EU cloud services. This troubles some Europeans because U.S. law authorizes U.S. authorities to compel U.S. firms to hand over data even if stored abroad.

To ensure that more sensitive European data stays within Europe, CADA lays out a sliding scale of four “assurance levels.” Higher levels require more EU-located data, infrastructure, staff, and supply chains. However, national authorities can choose assurance levels as they see fit, so the same application might use different levels in different countries.

Some analysts like EuroStack’s Stéfane Fermigier note that this leaves the door open for the assurance levels to be applied unevenly. American hyperscalers could locate data centers in the EU, claim sovereignty compliance, and avoid ceding ground to their smaller European counterparts.

Part 3: EU Energy System Road Map

The announcement of a threefold increase in the EU’s data-center capacity is unlikely to comfort the many Europeans who oppose their construction, citing concerns about their environmental footprints or their potential to strain the electrical grid. Partly in response, the EU’s tech sovereignty package includes a “strategic roadmap” for Europe’s electrical grids.

The Commission has proposed a rating system that would grade data centers based on their efficiency and environmental footprint, but this scheme has reportedly been delayed under pressure from data-center operators and some EU member states.

The road map includes support and research projects for smart grids and for AI models in the energy sector. It also plans to enable EU electric grids to more easily exchange data across borders.

Unlike the Chips Acts or CADA, the road map is not a proposed law. In many cases, its measures are research projects or promises to introduce future legislation by the end of 2027.

Part 4: Open Source Strategy

European public administrations spend an estimated €264 billion per year on proprietary IT, with 80 percent going to American companies. In the past several years some European bodies have made sporadic moves toward open-source alternatives, perhaps most notably the French civil service’s migration from Windows to Linux.

Now, the European Commission has unveiled an expensive strategy to promote open source in the public sector. In theory, open source could at once save on costs, phase out non-European software, and benefit European open-source developers.

The Commission’s plan stretches beyond office software and operating systems. It envisions public services partaking in a “vibrant” open-source ecosystem for everything from AI to RISC-V semiconductors to Web 4.0 architecture. It plans to fund open-source startups and developers in key sectors.

Although this strategy is not in itself a law, CADA includes some open-source measures, like a provision to “encourage” public-sector bodies to use open-source cloud and AI. In theory, this could establish a precedent for governments to choose “open source first.”

Jordan Maris, EU Policy Analyst for the Open Source Initiative, is optimistic about the package. He particularly believes it could be a boon for maintainers of core software. “They will likely receive recognition and opportunities for funding,” he says. “My guess is it will predominantly serve individual developers but some community-led projects could also benefit.”

Maris also says it can benefit developers of crucial enterprise software like Collabora Online, Euro-Office, and Nextcloud. Other open-source advocates, however, argue that the open-source measures in CADA do not go far enough. In particular, since CADA’s articles “encourage” public-sector bodies to prioritize open source rather than “require” it, the public sector may instead let inertia take its course.

This package is not final. The Chips Act 2.0 and CADA will now proceed through further European lawmaking, involving the European Council and European Parliament, a process that inevitably changes the content.

There’s also pressure from U.S. tech firms and some of the EU’s own member states to water down some of the requirements, as already happened with some of the open-source measures.

Today, it’s quite possible to see individual atoms in photographs. It’s one of the great triumphs of imaging. What, then, of the inverse? Can you use a single atom to capture an image?

Single atoms are probably not replacing smartphone cameras soon, but an atom can be used to measure light. One research group at the Institute for Molecular Science in Okazaki, Japan, has now used this ability to develop what they call an “atom camera,” which can capture patterns of light far too small to see with standard optical microscopes.

More than a physics demonstration, the atom camera could also be an elegant way to see inside certain quantum computers. The atom camera’s creators are also building quantum computers that use neutral atoms as qubits.

“We expect the atom camera to serve as a valuable diagnostic tool for this effort in our laboratory, and in other similar efforts worldwide as well,” says Kenji Ohmori, a physicist at the Institute for Molecular Science.

Ohmori and colleagues published their work in Nature Communications on 29 May.

The quantum photographer’s guide

The key component of this atom camera is an optical tweezer, an instrument that traps particles by squeezing them with focused laser beams. The instrument has become a common tool of physicists who handle atoms. A tweezer can catch an atom, then move it around or hold it in place. The researchers chilled a rubidium-87 atom to near absolute zero and immobilized it inside an optical tweezer. The atom camera essentially measures how this atom responds to its environment. As light falls on an atom, it imparts energy onto some of the atom’s electrons. This shifts the energy states of those electrons.

By observing these shifts, the researchers could gauge either the light’s intensity or its polarization. They could measure these properties of their tweezer’s light, or they could measure a second pattern of light cast on the atom.

These patterns are much larger than a single atom, so how do you turn measurement into a full image? Because the atom must be kept still, you have to move the pattern itself across the atom. The researchers dragged a pattern 100 nanometers at a time—up, down, or to the side—and measured the intensity or the polarization of the light at each step.

In the end, they had a 2D map of measurements—which they could render into a nanoscale “photograph.” They photographed several different patterns using this method.

The Okazaki researchers aren’t the first to use atoms for measuring light. Since the 1990s, physicists have tried atoms to cheat the diffraction limit of visible light: the tiniest feature that typical optics can see. Atoms are significantly smaller than this, so an atom set up in the proper way could theoretically resolve even tinier details.

As cold-atom physics has grown more sophisticated, more labs have tried their hands (and optical tweezers) at making atoms fit for purpose. In 2022, two groups at the Institute of Photonic Sciences in Barcelona and at the University of California, Berkeley, separately used rubidium-87 atoms to capture the intensity of oncoming light. The Berkeley group reached a resolution of 300 nm, but they believed their work was only an initial step.

“We envisioned that the method could be made much more sensitive,” says Dan Stamper-Kurn, a physicist who was involved in the aforementioned work, but not the Okazaki group.

In its earlier work, the Berkeley group studied a relatively large shift in energy state. The Okazaki group instead measured a far subtler shift linked to what physicists call a hyperfine transition. This has several advantages. For one, the Okazaki group could measure its light’s polarization, in addition to its intensity. For another, the hyperfine transition is far more sensitive: In theory, the Okazaki group can render features as small as 25 nm. (Smaller than that, quantum uncertainty comes into play.)

The more precisely you know your atom’s position, the better your resolution. This is why the atom must be kept as still as possible.

Qubits calling for photographers

What could an “atom camera” capture? Quite a few things, actually, physicists say.

“There’s a lot of relevance to this, because these so-called optical tweezers are what we use in many experiments nowadays,” says Johannes Zeiher, a physicist at the Ludwig-Maximilians-Universität München in Germany, who was also not involved with the Okazaki group.

Optical tweezers are particularly prized in the world of neutral-atom quantum computers, like the Okazaki group are building. These quantum computers run on atoms such as rubidium-87 chilled to near absolute zero inside a vacuum chamber. Optical tweezers can trap the atoms, which act as qubits, and hold them or move them around. Computing with two neutral atoms might involve precisely positioning them and firing a laser to illuminate both.

Such a light beam is almost never uniform. Even a small beam can contain all manner of subtleties, especially quirks of polarization, which can interfere with a qubit and cause it to lose coherence and collapse. It’s crucial, then, for a qubit operator to understand the tiniest details of their light, but physicists today are still searching for a method to reliably do this.

Traditional optics often aren’t suitable for the task of seeing inside a quantum computer’s vacuum chamber, since they too can easily disturb qubits. The challenge becomes even more tedious as neutral-atom quantum computers gain more qubits and become more complex to control.

The physicists say that their creation, which can map both intensity and polarization at tiny scales, is an enticing alternative.

“Rather than bringing a camera from outside the vacuum chamber, why not use the tools already there inside our quantum playground in the vacuum?” says Takafumi Tomita, a physicist at the Institute for Molecular Science, and another of the authors.

This article appears in the August 2026 print issue as “Camera Takes Photos With a Single Atom.”

If simulations are to be believed, startup Tensordyne’s new AI chip could crush the performance of market leader Nvidia in terms of energy efficiency and latency for inferencing. The company just sent the plans for its first chip to be manufactured, with commercial sales of a 72-chip system scheduled for the second half of 2027. Tensordyne claims its 72-chip system can run large LLMs four times as fast using one-fifth the power compared to a 72-Nvidia GB300 system. However, real systems won’t be around to back these figures up until the end of the year.

The not-so-secret sauce behind the outsized efficiency of Tensordyne’s new chip, Napier, is how it does matrix multiplication, the main math of AI. It takes advantage of the fact that the logarithm of A times B equals the logarithm of A plus the logarithm of B.

“We’ve turned multipliers into adders,” explains Gilles Backhus, a Tensordyne founder and vice president of AI. Adders are smaller and more energy-efficient logic circuits than those that do multiplication, he says. So Napier can pack more compute into a smaller area and still save on power.

New kinds of numbers

That such a thing was possible has long been known, but there wasn’t a good way to use it, because converting back and forth between logarithmic numbers and the floating point numbers that describe neural networks took too much time and energy and introduced too many inaccuracies. Not anymore, according to Backhus.

“So far no one has figured out how to do the linear to logarithm and logarithm to linear conversion as we have,” he says. “And that’s actually the crux of that whole thing. Our engineers have figured out ways to do this very elegantly and very very accurately and cheaply on silicon.”

The importance of number formats hasn’t been lost on the AI industry. Speaking at IEEE Hot Chips in 2023, Nvidia chief scientist Bill Dally attributed the majority of the improvement in the company’s GPUs at the time to the use of shorter number formats and the smaller circuits they require.

Researchers have also worked on circuits to compute with alternative formats, such as the logarithm-like posit and more recently its scientific-computing counterpart the takum. However, these formats have not reached mainstream adoption mostly because their hardware implementation is so different from traditional floating point.

Inference Demands Influence Architecture

Market trends, including the rise of AI agents, mean inference—the execution of neural network models—is becoming more important than training new large language models (LLMs). Factors like the cost and the speed at which answers are delivered are starting to dominate, and that’s led AI companies to look for system architectures that are a better fit for that.

Tensordyne executives say they saw this coming and engineered their computers to meet it.

Tensordyne’s Napier AI chip includes 144 gigabytes of HBM, but the real power comes from its unusual math.Tensordyne

There are two main parts to executing an LLM: prefill and decode. In the prefill stage the model takes in the input text and turns it into tokens, the basic units it can work with, and builds a kind of working memory about the input, called the key-value cache. It’s a computationally heavy task.

Decode is where the LLM generates its output tokens, the answer or response to your input. Each new token is predicted using the previous token and the key-value cache. This sequential nature can make decode a slower process, and it’s more dependent on memory and network latency than computing power.

So AI chip makers are starting to build systems with those two different demands in mind. Nvidia is touting a system where a server rack full of B300 GPUs handles prefill and several racks of its Groq 3 processors do the decode. Amazon Web Services is combining a rack of its Trainium AI chips for prefill with several racks of Cerebras’s wafer-scale computers for decode.

Tensordyne says its system can handle both jobs. “We’re optimizing for two hard challenges here at the same time,” says R.K. Anand, chief product officer and co-founder of Tensordyne. “We’re the first company proving that you can do both without going to multiple vendors and multiple racks.”

The dense compute needed for prefill comes from the logarithmic math. The needs of decode come from 144-gigabytes of high-bandwidth memory and a custom 1-microsecond-latency network called Tensordyne Napier Link.

In a “pod” system that fits in one-quarter of a standard rack, Tensordyne packs in 72 Napier chips, 8 Intel Xeon CPUs, and 64 terabytes of solid-state storage. A four-pod rack working on a 2-trillion parameter LLM would deliver 1,300 tokens per-second per-user at a cost of US $11 for 1 million tokens, while consuming 120 kilowatts of power, the company claims, with one pod crunching out prefill and three working on decode. To get similar tokens per-second per-user numbers, a nine-rack Rubin and Groq 3 system would likely consume 1.5 megawatts, according to Tensordyne.

Whether or not these numbers really hold up will have to wait until later in the year. Tensordyne plans to have a beta version available through the cloud for customers to work with. It expects to begin shipping systems to customers about a year from now.

“Space computing, the final frontier, has arrived,” Nvidia CEO Jensen Huang declared at the Nvidia GTC conference in March.

Indeed, the idea of data centers in orbit has gone from science fiction to a serious spending category. Elon Musk’s SpaceX has acquired xAI (also Musk’s) and is planning a constellation of space-based data centers. Google, not to be outdone, announced Project Suncatcher in partnership with Planet, planning to launch two satellites equipped with Google Tensor Processing Unit (TPU) AI chips by early 2027. Startup Starcloud has already filed a proposal with the Federal Communications Commission for an 88,000-satellite constellation for orbital data centers. As Starcloud’s filing suggests, these companies are all proposing fleets of satellites numbering in the thousands, each housing a rack or multiple racks of AI-grade GPUs, interconnected with each other through free-space optical links and communicating back to Earth via microwave links, either directly or through other satellites.

Proponents tout the many wonders of computing in space: abundant solar energy, free cooling, and freedom from Earth-based disturbances like earthquakes, floods, and protesters. But a sober look at the physics of space-based computing paints a much more nuanced picture.

Free cooling is perhaps the biggest misconception. Space is cold, but it also has no atmosphere. That means the best heat-removal mechanisms, conduction and convection, are off the table. The only option is radiation. To prevent a chip from overheating in space, a large, costly surface area is required to dissipate the energy and then radiate it.

Solar energy is abundant, but collecting it with functional solar panels that maintain perfect alignment toward the sun is a complex task requiring extensive attitude control systems. On top of that, ionizing radiation in space from cosmic rays and other sources poses a unique challenge, degrading the solar panels, the radiative coolers, and the chips themselves. Because regular maintenance in space is difficult, redundancy has to be built in at launch, and cost estimates have to account for efficiency degradation over time.

At ABI Research, where I work as an aerospace analyst, we did a rough total-cost-of-ownership comparison between a data center on Earth and one in space. It showed that the cost to launch and run a GPU in space for a year is at least an order of magnitude higher than the same feat in a terrestrial data center. Our model was simple, assuming an Nvidia H100 server rack launched with the requisite-size solar panel and radiator on a spacecraft akin to Starcloud’s pilot launch. We assumed SpaceX’s Starship was used at a highly optimistic launch cost per kilogram of US $44, and a terrestrial energy cost of $0.20 per kilowatt hour. This is a simple back-of-the-envelope calculation, but it does signal something real.

From our perspective, the cost of delivery and space hardening of the payload makes general-purpose space-based data centers difficult to justify economically today, despite the fact that data-center builders in many regions are scrambling for electric power. However, there are niche applications where the much higher costs of computing in space could be justified. Examples include preprocessing data from Earth-observation satellites, real-time detection and tracking of hypersonic missiles, and active collision avoidance in the increasingly crowded low Earth orbit. Even for these, though, contending with fundamental physics will still be a demanding challenge. And a technologically compelling one, too.

The Cooling Challenge in Space

Cooling is where physics separates the science from the fiction. The governing equation for radiative cooling, the only type of cooling available in space, is known as the Stefan-Boltzmann Law. It states that the amount of power you can radiate is proportional to the area of the radiator times its temperature to the fourth power. For a space systems architect, the implications of this law are brutal. In orbit, the only variable we can control is area. This restriction creates a geometric penalty, or a “physics tax,” for cooling in space: The more power you need to reject, the bigger the area of the radiator you need to bring along from Earth.

The only cooling method available in space is radiation, and the radiator area required is derived using the Stephan-Boltzmann law. For a single chip drawing 700 watts, like Nvidia’s popular H100 GPU, the area required to keep it at 20 °C is just under 3 square meters, and it goes down to 1 square meter for an operating temperature of 85 °C. However, as the radiator surface is exposed to ionizing radiation, its emissivity decreases, and after 5 years in space the required area increases by about 40 percent.

To understand how big this baseline area is in practice, I used the Stefan-Boltzmann law to model the heat-rejection area needed to keep a single chip that draws 700 watts of power—such as the H100 GPU chip, an AI stalwart—at a constant 60 °C, usually considered the sweet spot for GPU longevity and stability. I further assumed that the radiator is perfectly facing deep space, at a chilly background temperature of 3 kelvins. By this calculation, a single chip would require 1.4 square meters of radiator surface.

To put this into perspective, consider that a common AI rack can hold approximately 32 GPUs (four H100 server boards). With CPUs, memory, and networking equipment, this rack would draw around 40 kilowatts of power. This single rack includes 2.5 terabytes of memory—enough capacity to serve over 20,000 concurrent users or run 16 simultaneous instances of Llama 3, an open-source AI model. But to cool this thermal load in a vacuum, that single rack would require an 80-square-meter radiator, roughly the size of a pickleball court. For an aggregate 100-megawatt data center, you’d need at least 2,500 of those radiators.

And that’s the best-case scenario. Additional problems are hidden in the low Earth orbit environment itself. Space exposes radiators and their coatings to a chemically hostile brew of ultraviolet light and atomic oxygen, quite the opposite of a clean-room environment. Over a LEO satellite’s typical 5-year lifespan, these elements degrade the radiator’s surface properties and lower its ability to shed heat.

Including this degradation in the model reveals that as the radiator degrades from a “fresh” state to an “end-of-life” state, the physics demands a further penalty. To maintain that same 60 °C operating temperature for the GPU chips, the required surface area jumps from about 1.4 square meters per chip to nearly 2.0 square meters. In other words, the physics tax rises by 40 percent. Therefore, you must launch at least 40 percent more radiator mass, endure higher atmospheric drag, and sacrifice valuable launch volume just to survive the degradation of the thermal coating. This increase adds significantly to the launch cost and further erodes the economics of a space-based data center.

The Silicon Challenge in Space

Solving the heat problem is only part of the battle. The other significant challenge in low Earth orbit is ionizing radiation, which affects the computing hardware itself. Today’s satellites typically use radiation-hardened processors, which are very reliable but also much more expensive, and they perform poorly compared to commercial off-the-shelf processors.

A standard rad-hard chip doesn’t have the processing power to run a modern large language model (LLM). As a result, satellite operators aspiring to launch a data center have no choice but to make a risky compromise: to use hardware meant for terrestrial use. In order to achieve the necessary compute density, orbital data centers must use the same Nvidia H100s or Google TPUs found in terrestrial server farms. The problem is that these chips are “soft” targets in space. High-energy particles can flip bits in memory or cause “latch-ups” in logic that fry the circuit.

Three big proposals for orbital data centers vary in satellite size, number, and cooling plans.

One possible option is to shield the computers from radiation with thick, absorbent panels. However, the shielding would add significantly to the already heavy satellites. The other option is to compensate for the radiation damage with redundancy. Indeed, edge computing architects are moving toward software-defined resilience, where instead of one perfectly hardened computer, operators fly a cluster of imperfect, commercial ones whose total cost could be as low as one-tenth to one-hundredth that of the rad-hard model.

This redundant approach is used in many spacecraft, including Artemis II, which recently carried astronauts around the moon, as well as SpaceX’s flight computers and the Hewlett Packard Enterprise edge servers for the International Space Station. By running three (or more) instances of the same calculation on three different nodes and comparing the answers, the system can detect a corrupted processor. If a node fails, the “orchestrator” reboots it while the others continue the mission. While this ensures resiliency, it also means that some fraction of the compute capacity is dedicated to redundancy, further increasing the costs.

The Energy Challenge in Space

An often-touted advantage of space-based data centers is the seemingly unlimited supply of free, clean energy from the sun. Solar energy in orbit is indeed abundant, at 1,361 watts per square meter. Of course, capturing that free energy is made possible only by the very costly launching of large solar panels into orbit. And those solar panels also degrade over time due to radiation exposure, typically losing 1 to 3 percent efficiency per year.

Let’s say a solar array collects 1 MW of power to run an AI cluster. The laws of physics demand that the satellite must eventually radiate 1 MW of waste heat. Because the square area needed to generate the solar power—around 400 W/m2—and to reject the heat—around 450 W/m2—are nearly equivalent, every square meter of power generation now demands approximately another square meter of cooling. The radiator needs to be a structural equal, not merely a passive coating on a surface used for something else.

As Elon Musk recently noted in Davos, the most efficient radiator is one that never sees the sun. By orienting the spacecraft so the solar panels face the sun and the radiators face the deep vacuum of space, efficiency skyrockets for both. But there’s a catch: Maintaining this perfect three-way alignment—panels to sun, radiator to the void, antennas to Earth—requires complex, high-torque attitude control systems. So this configuration means more payload and more computing power. Plus, these control systems are complex components with many failure modes, which is not optimal in a situation where maintenance is difficult.

The Killer Apps for Computing in Space

Given all these challenges of deploying massive radiators for satellites in the hostile environment of space, why build data centers in space at all?

While training or inference on LLMs in space doesn’t seem economical today, there are other, very compelling applications for computing in space. Here are two: solving the downlink bottleneck from Earth-observation satellites and enabling collision-preventing maneuvers in the increasingly crowded low Earth orbit.

The latest Earth-observation satellites, equipped with hyperspectral and synthetic aperture radar sensors, are used for a range of important reconnaissance missions, such as battlefield intelligence, tracking the global shadow fleet of ships carrying contraband, and assessing earthquakes or infrastructure failures down to the millimeter. These systems can generate hundreds of terabytes of raw data per day that must be transmitted to Earth. However, the radio-frequency “pipes” used to downlink the data are congested, and the ground infrastructure cannot absorb the sheer volume of raw data.

Another immediate, mission-critical application for in-space computation is protecting the orbital environment. With over 17,000 satellites in orbit, the overwhelming majority of which are in low Earth orbit, avoiding collisions between these satellites is crucial. As NASA astrophysicist Donald Kessler pointed out back in 1978, a single space collision could cause a cascading effect that renders the entirety of LEO unusable.

RELATED: Have We Reached a Space-Junk Tipping Point?

According to SpaceX’s recent annual report, the Starlink constellation executes a collision avoidance maneuver every 2 minutes on average. Each maneuver already relies on onboard AI systems but still requires most of the processing to happen on the ground.

As low Earth orbit gets increasingly populated, collision avoidance will have to break the traditional ground-loop model. In the megaconstellation era of space, the OODA (observe, orient, decide, act) loop must happen onboard, thereby reducing the analysis turnaround from minutes to milliseconds.

The problem is that the flight computers standard on satellites are not built for this level of processing. The complex probability models required for maneuvering cannot currently be implemented by onboard computers in conjunction with their navigation systems. Clearly, more powerful computers are needed.

This is the true economic justification for moving compute to space: to move insight generation there. By placing high-performance computing adjacent to the sensors, we can process terabytes of data in orbit and downlink only the relevant data in real time, and we can do the computations necessary to avoid satellite collisions in real time.

The Future of Computing in Space

So, assuming that some form of computing is inevitable in low Earth orbit in the foreseeable future, how will the heat be handled? The industry is currently experimenting with two main classes of solutions to cope with the Stefan-Boltzmann law.

One creative option is to use origami-inspired radiators, the kind used for the James Webb telescope. Companies are developing flexible, high-conductivity composite radiators that fold into a tight cube for launch and unfurl into enormous yet lightweight thermal wings in orbit.

Another possibility is to use liquid-droplet radiators. This concept proposes removing the rigid radiator structure completely and instead spraying a stream of coolant oil directly into the vacuum of space. The fluid travels through an open loop, exposed to the near-absolute zero of the void, maximizing radiative surface area before being caught by a collector and pumped back into the ship. It sounds like science fiction, but as the heat loads climb into the megawatts, liquid-droplet cooling may be the only way to cheat the mass limits of this exponential reality.

Options for Future Radiator Design

Our rough total-cost-of-ownership model uses optimistic versions of current numbers, such as launch cost, chip cost, and power use. A critic might point out that future technology will improve, both in efficiency, purpose-built designs, and costs.

Sure, the technology is bound to improve. But the critical factor isn’t just launch cost; it’s the computing power per unit mass and electric-power economics. Radiators and solar arrays can consume 65 to 70 percent of total satellite mass, and space-grade photovoltaics run orders of magnitude more expensive than terrestrial equivalents.

Chris Philpot

Even as launch costs fall, the mass and cost burden of power generation and thermal management will remain a fundamental problem.

Current space-grade solar panels rely on germanium substrates, whose supply is concentrated in China. It will be extremely difficult to scale up availability of these substrates. A transition to radiation-tolerant perovskite solar panels or a similar alternative could change the economics significantly, but that possibility is five years away or more. The technology will get cheaper, but the bottlenecks of power and thermal architecture will remain.

Recognizing the thermal reality of cooling in space forces us to shift how we view satellite operations. We are moving away from the “launch and forget” era toward an era of “autonomous logistics.” As our thermal model demonstrated, the harsh environment of space steadily attacks the hardware. UV radiation degrades thermal coatings; cosmic rays degrade silicon. In a traditional satellite model, when the radiator degrades or the memory fails, the satellite becomes space junk. For a multimillion-dollar data center, that disposal model is potentially ruinous.

To make the economics of orbital computation work, the infrastructure must be serviceable and the rockets to launch them reusable. The orbital domain will require automated servicing vehicles capable of swapping out degraded radiator panels and upgrading fried servers. In these ways, the future of the orbital data centers is dependent on the innovations of an emergent in-space economy.

There’s a good argument to be made that the need for space-based computation is less of a hype cycle and more of an enabler for the new space economy. Look no further than SpaceX’s recent regulatory filings proposing a constellation of up to a million satellites in low Earth orbit. At such a scale, routing all raw data back to Earth is physically impossible; the network itself must become the data center.

However, the winners in this sector will be determined by the systems architects who most cleverly accommodate the thermodynamics and the companies with sufficient vertical integration to take on the massive costs of operating data centers in orbit. Ultimately, the physics tax is universal. Whether managing heat rejection in the vacuum of low Earth orbit or managing power density in a hyperscale facility in Northern Virginia, the constraint is never the silicon. It’s the thermodynamics.

OpenAI’s fourth large language model (LLM), GPT-4, took an estimated 50 gigawatt-hours to train, or the equivalent of 5,000 American homes’ yearly power consumption. That was in 2023. Since then, the computational resources used to train frontier LLMs have only increased, though direct power usage numbers are hard to come by.

Now, a research group at the University of Twente in the Netherlands has shown that you can save up to 14 percent of the energy used in LLM training without sacrificing speed by cleverly adjusting the clock frequency of the GPU during computation. Jeffrey Spaan, Ph.D. candidate at University of Twente and lead author on the article, presented the results at the Computing Frontiers conference in Catania, Sicily, last month.

“My research is about finding computing waste,” Spaan says. “It’s similar to underutilization of the hardware, but instead of optimizing the software for the hardware, we try to optimize the hardware for the software.”

Making the GPU tick

Spaan and his collaborators accomplished this by using a technique known as dynamic voltage and frequency scaling (DVFS). Every chip—including the GPUs commonly used for training frontier models—uses at least one clock to orchestrate computations. Each operation in the chip is triggered by a clock pulse. The frequency with which that clock ticks controls how fast the chip operates and how much power it draws.

Modern GPUs have two clocks, one for the computational core and one for the memory. When the core is hard at work crunching numbers, the clock frequency is kept high to ensure speedy calculation. However, with DVFS, the memory clock can slow down in that time, allowing for less power draw. In principle, it’s possible to just turn off the memory part of the chip, but GPUs designs don’t enable software control for that off switch, and it would take too long to turn back on mid-calculation anyway. Similarly, when the core is waiting for data to be loaded from memory, the core clocking frequency can be slowed to a crawl while the memory clock frequency ramps up.

DVFS has been a well-known technique that goes back to at least the 1990s. But Spaan says other researchers haven’t been able to usefully apply it to LLM training because their methods either slowed down calculations too much or were not fine-grained enough to improve energy usage.

Previous DVFS attempts adjusted the frequency at each iteration of the training process. In LLM training, each iteration consists of two parts: the forward pass, in which data is run forward through the layers of the model with the weights as they are; and backpropagation, in which the weights are adjusted layer by layer based on the results of the forward pass. So prior work kept one value of the frequency for the forward pass and adjusted to another for backpropagation.

Spaan and coworkers tuned the clock frequencies on a shorter timescale. GPU workloads are broken down into tiny computational nuggets known as kernels. For example, a single vector-vector multiplication can make up a single kernel. The kernels are fed to the GPU to be processed many times in parallel. In Spaan’s implementation, the computation of a single layer of a deep neural network is broken up into approximately 40 kernels. By adjusting the clocking frequencies on a per-kernel level, the team was able to find much greater energy savings.

The GPU also does DVFS automatically when the chip’s internal systems detect higher or lower demand, Spaan notes. “Some people might therefore think: We’ll just let the GPU handle it,” he says. “However, because the GPU doesn’t have the foresight we have of what kernels will run, it has to work with an on-the-fly best-effort guess and can therefore never attain the same savings.” That’s where the manual adjustments come in.

Less energy, same time

The team performed their experiment by training GPT-3-XL, a 1.3 billion parameter model, on an Nvidia RTX 3080 Ti GPU. To save time, they focused on training a single layer of the model. In this setting, they found a set of frequency adjustments that gave them 14 percent energy savings while slowing the training time by only 0.6 percent. Performance of the model depends on both computing speed and energy usage.

There is one challenge: Ramping down the clock frequency is much faster than turning a core off and on, but it’s still not instantaneous. In their experiment, the researchers evaluated one kernel at a time, not taking into account the frequency switching speed. So 14 percent energy savings is a best-case scenario. How much of an issue it would be in practice, Spaan says, depends heavily on the GPU being used. Newer hardware, like the Blackwell GPUs, have much faster switching speeds than older versions and should be able to harness the full energy savings.

Now, the team is developing a tool that would be able to implement optimal frequency scaling automatically for a particular workload. Spaan hopes their method will be attractive enough to industry leaders to merit adoption. “We optimize for saving energy without losing performance,” Spaan says. “In the real world, performance is the holy grail.”

Modern operating systems are packed with defenses against security vulnerabilities. But what if those defenses could be removed? Doing so would offer a clear view of the chip running the OS. It would also expose hardware vulnerabilities the OS normally obscures.

A new hand-coded OS, Fractal, provides that clear view. Built from scratch by researchers at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL), Fractal is designed to probe the architecture of the chip that runs it. To prove that point, the OS, presented in May at the 2026 IEEE Symposium on Security and Privacy in San Francisco, was used to uncover a previously unknown vulnerability in Apple’s M1 chip.

Joseph Ravichandran, the CSAIL Ph.D. student who programmed Fractal, says the OS was inspired by obstacles faced while researching Pacman, an Arm CPU vulnerability disclosed in 2022.

“We paved the way with techniques such as custom kernel patches and kernel extensions,” Ravichandran explains—but these were only a partial solution. “The dream was always to have a completely custom operating system which would make these hacks unnecessary.”

Probing Chip Data Storage & Movement

Researchers exploring hardware vulnerabilities need to know exactly how data is stored and moved across a chip. They deduce this by coding tests that provoke desired behavior from a chip and then analyzing the results to reconstruct how the chip executed the code.

However, a conventional OS like Windows or MacOS will have defenses and features that obfuscate code execution and memory management. “I’ve built a number of lab exercises for our secure hardware design course,” Ravichandran says. “Seeing the struggles that students go through, and living those struggles myself in my research, I realized there just has to be a better way.”

Fractal is the obvious solution to the problem. Instead of patching or exploiting a conventional OS, Fractal entirely replaces a device’s original OS with a customized alternative focused on security research.

As you might expect, however, coding an OS is no small feat. Fractal was coded from scratch with a combination of programming languages including assembly, C, and C++. Ravichandran began work in June 2024 and finished the first version of the OS at the end of that year, after which it went through months of testing. Debugging was the most difficult step, as building a custom OS for hardware not designed to support it eliminated debugging tools from the equation.

“When getting Fractal to run on Apple Silicon, for the longest time the only output I had was the power light on the front of the machine,” Ravichandran says. “This light told me whether my code was running, and the light stayed on; or if the machine had crashed for some reason, and the light turned off.”

Fractal OS Features for Security Research

Fractal provides researchers with three key features.

The first, headline feature is multi-privilege concurrency. On a conventional OS, comparing a chip’s behavior across privilege levels—which control a program’s access to system resources—is extremely difficult. Switching levels also shifts the memory layout, the CPU’s branch-predictor state, and more, all of which adds variables that skew test results. Fractal can run a test concurrently across privilege levels while holding other parameters identical, which leads to a much cleaner test result.

The second feature is cooperative multitasking, an alternative to a conventional OS feature called preemptive multitasking. Preemptive multitasking is an important feature for a modern OS, as it’s used to juggle the dozens or hundreds of tasks which might be active at once—but it can also pause a test if the OS decides another task matters more, which adds noise to the test result. Fractal’s cooperative multitasking, when enabled, allows a user to dictate the order in which code executes with no interruptions.

The final feature is Fractal’s memory system, called gmap. In a conventional OS, a program reaches memory through virtual addresses that the OS maps to real hardware. This mapping can change between tests. Gmap instead mirrors memory locations across threads and tasks, eliminating yet another variable.

The common threads across these features are control and clarity. “Fractal’s aim is to tell you simply what the hardware does as accurately as possible,” Ravichandran says. “Using the information learned from Fractal, researchers will be better equipped to understand how the hardware itself behaves independent of the OS.”

Discovering Phantom Speculation on M1

To show what Fractal could do, Ravichandran aimed it at Apple’s M1, a victim chosen primarily because it was the hardware on hand.

Fractal made it possible to find the first evidence that Apple Silicon is affected by a form of Phantom speculation, which in some cases can let an attacker momentarily direct a chip down a path an attacker chose. Phantom was known to be present in Advanced Micro Devices (AMD) and Intel hardware but was never proven to be present in Apple’s M1—until now.

The practical effect of the vulnerability is likely limited. Fractal found that while Phantom fetches can occur on Apple’s M1, the instructions are never executed. Ravichandran declined to speculate on how the vulnerability might be used in the wild and said that the vulnerability was disclosed to Apple.

Though primarily tested on a Mac Mini equipped with Apple’s M1, Fractal also runs on many Intel and AMD PCs, Raspberry Pis, and some more recent Apple Silicon devices like the Mac Mini with Apple M4. Fractal is freely available to download as an open source OS under the MIT license. Ravichandran has posted the kernel to Github and the full experimental setup on Zenodo, with additional details available on Fractal’s website.

Ravichandran is eager to see how other researchers make use of Fractal to explore other microarchitectures. “Right now, my goal is to get this system out into the world so other researchers can benefit from it,” he says. “My hope is that Fractal becomes a community project with contributions from other research labs who benefit from this approach.”

At Computex 2026, an annual computer trade show held in Taipei, Taiwan, Nvidia made a long anticipated announcement—a version of the company’s Blackwell GB10 superchip for Windows PCs, called RTX Spark. Originally rumored to launch in 2025, it was finally introduced at this year’s show.

It came with full support from Microsoft, which announced two new devices powered by RTX Spark: the Surface Laptop Ultra and the Surface RTX Spark Dev Box. Asus, Dell, Lenovo, HP, and MSI also announced Windows PCs with RTX Spark.

If this is triggering déjà vu, that’s for good reason. In June 2024, Qualcomm and Microsoft partnered to launch AI-focused Copilot+ PCs. Qualcomm’s Arm-based chips provided an alternative to x86-based chips from AMD and Intel used across dozens of budget and mid-range Windows laptops. It was met with mixed commercial success, however, and Intel remains the dominant supplier of chips for Windows laptops. But that doesn’t mean RTX Spark will follow the same path, as Nvidia’s involvement is an important part of the equation.

“Nvidia just has more clout and more industry weight to push and make things happen that Qualcomm couldn’t do early on, and that even Microsoft struggled with,” says Ryan Shrout, president at Signal65, a third-party testing firm. “They can get game developers on board and get software developers in the emerging AI space to pay attention.”

What is RTX Spark?

At its core, RTX Spark is an iteration of the hardware found in the DGX Spark mini-workstation, which was released in late 2025. Officially badged N1X, the silicon is Nvidia’s Blackwell GB10 “superchip,” a system-on-a-chip with 20 Arm CPU cores; 6,144 GPU cores; and support for up to 128 gigabytes of LPDDR5X memory.

There are some small differences between the mini-workstation and PC system, and the most significant is power consumption. The DGX Spark was designed for GB10 to operate with a power consumption up to 140 watts without overheating. RTX Spark laptops are likely to use less power, which may lower performance, though the details will depend on each PC maker’s particular implementation and remain to be seen.

RTX Spark will also include a neural processing unit (NPU) that qualifies the system for Microsoft’s Copilot+ certification. The NPU is used for some background AI features, like Windows Recall. However, the GPU will remain in the driver’s seat for active AI tasks, including large language models (LLMs) and image generation.

Though RTX Spark laptops took the spotlight, the news is also relevant to desktop workstations. Currently, DGX Spark ships with a custom version of Linux called DGX OS, not Windows. Nvidia says RTX Spark desktops with Windows are coming in the third quarter of 2026. Windows is also coming to Nvidia’s DGX Station, the full-sized desktop iteration of Nvidia’s hardware.

The launch of RTX Spark is, of course, in part an AI play, and that is taking the lion’s share of attention. But Anshel Sag, principal analyst at Moor Insights & Strategy, thinks Spark is just as relevant for professional work and gaming. “I think the AI play is mostly to appease investors,” he says. “Creators and gamers are also excited about RTX Spark, and someone like me who does all three is even more excited, because having a machine that can do all three well has been a challenge.”

Nvidia’s advantage may lie in software

Though Nvidia refers to the GB10 as a “superchip,” it’s similar to other high-performance system-on-a-chip designs, such as Apple’s M-series silicon and AMD’s Ryzen AI Max. All three include a CPU, GPU, and NPU. All three support large amounts of DRAM. And all three have a unified memory architecture (meaning the system memory is a shared resource accessible to the CPU, GPU, and NPU).

The existing DGX Spark also provides a baseline for performance expectations. RTX Spark will likely deliver GPU performance similar to an RTX 5070 mobile GPU which, if correct, would put it ahead of Apple and AMD’s competing systems. On the other hand, GB10’s CPU cores aren’t as quick as the CPU cores found in leading competitors.

Nvidia’s biggest edge might stem not from hardware performance, but from software. The company’s GPUs are essentially the industry standard across gaming and professional work, with estimates placing Nvidia’s GPU market share above 90 percent. That in turn has made Nvidia the target for most software that benefits from a GPU.

“Nobody doubts that Nvidia is the leader in GPU capability and the software stack around it,” says Shrout. Sag agrees, explaining that Nvidia has the advantage of “extremely mature drivers.”

Microsoft touts AI, but Windows on Arm remains a question

Nvidia announced RTX Spark was in lockstep with Microsoft, which held its Build developer conference in San Francisco while Computex was taking place across the Pacific in Taipei.

Repeating the Copilot+ PC launch, Microsoft’s vision of Windows on the RTX Spark leans heavily on AI. But unlike Copilot+ PCs—which used the NPU to accelerate AI features integrated into the Windows user experience, such as quickly recalling anything you’ve opened or translating live video calls—the pitch for Windows running on RTX Spark seems more focused on using the Spark’s GPU to accelerate LLMs.

Microsoft announced an “early preview” of Windows SDK called Microsoft Execution Containers (MXC), which sandboxes AI agents, allowing them to work autonomously while isolating them from functions the user doesn’t want the agent to access.

Still, the real test for both Nvidia and Microsoft remains the same challenge Microsoft and Qualcomm faced: establishing Windows on Arm PCs as an alternative to Windows PCs powered by x86 chips from Intel and AMD. Whether RTX Spark will succeed in this remains to be seen.

“Even with all of the talk from Nvidia and Microsoft about the future of the PC and revolutionizing the PC, everybody understands that it needs to be a great general-purpose PC first,” says Shrout.