There is something almost comic about putting Apollo 11 beside a USB charger. One carried human beings across a quarter of a million miles and helped land them on the Moon. The other sits behind a desk collecting dust until somebody’s phone reaches 12 per cent.

Yet the comparison is not invented. The Apollo Guidance Computer, or AGC, had roughly 4 kilobytes of erasable working memory and ran from a clock around 1 megahertz. Some of the digital controllers built into modern USB-C chargers operate at tens of megahertz. A phone has more memory and processing machinery than the Apollo designers could have plausibly put aboard a spacecraft.

The headline numbers are true enough to be fascinating, but not complete enough to stand alone. The 4 KB was not the AGC’s total storage. Clock speed is not the same as computing power. Apollo 11 carried more than one computer. Once those qualifications are added, the story becomes less like a joke about primitive hardware and more like a lesson in what engineering is really for.

The Block II AGC used for the crewed lunar missions contained 2,048 words of erasable magnetic-core memory. Each memory word occupied 16 bits, so treating a word as two bytes gives 4,096 bytes, or about 4 KB.

Even that translation needs care. An AGC word carried 14 data bits, a sign bit and a parity bit. Modern memory figures normally count every bit in a byte as available storage. The conversion to 4 KB is therefore a useful physical comparison, not a claim that Apollo programmers had an ordinary modern 4 KB workspace.

The erasable memory held values that changed while the computer worked: intermediate results, counters, registers, navigation data and the temporary state of running jobs. In modern language, it was broadly analogous to RAM.

Programs and constants mostly lived elsewhere. The flight model had 36,864 words of fixed core-rope memory, about 72 KB if we count each 16-bit word as two bytes. NASA historian James E. Tomayko’s history of computers in spaceflight explains how this dense read-only memory encoded information through wires threaded through or around magnetic cores. A wire’s route represented a one or a zero.

That made “loading the software” a startlingly literal manufacturing job. Once a rope memory module left the factory, changing its contents was nothing like installing an update today. The fixed memory was expanded repeatedly during development, eventually reaching 18 times the earliest estimate, because the computer kept being asked to do more.

The AGC’s basic clock was about 1 MHz, but an instruction required multiple clock pulses. The architecture had a single adder, a small group of important registers and none of the performance tricks found in a modern processor. It did not finish one full instruction on every tick.

This is the first reason clock comparisons can mislead. Frequency measures how often a timing signal cycles, not how much useful work a machine completes. A modern chip may issue several operations in one cycle, reorder instructions, predict branches and pull data from several layers of cache. It may also spread work across multiple CPU cores and hand specialised jobs to graphics, image, signal-processing or neural hardware.

The AGC was closer to tens of thousands of basic instructions per second than a million. That sounds tiny until we ask what it was actually expected to do. It did not render video, decode social feeds or keep a general-purpose operating system responsive. It repeatedly read instruments, updated estimates of position and velocity, solved guidance equations, issued control commands and accepted concise inputs from trained astronauts. For those tasks, predictability mattered more than headline throughput.

Apollo 11 did not leave Earth under the control of a single beige box. There was an AGC in the Command Module Columbia and another in the Lunar Module Eagle. The Saturn V had its own Launch Vehicle Digital Computer in the rocket’s instrument unit. Radio links, ground computers, radar, optics, inertial sensors and analogue electronics all belonged to the wider system.

The Lunar Module’s AGC was nevertheless central to the descent. It tracked Eagle’s changing state, ran guidance and control programs, commanded the descent engine and exchanged information with Neil Armstrong and Buzz Aldrin through the Display and Keyboard, or DSKY. Instead of icons and menus, astronauts entered numerical “verb” and “noun” codes. The display could present a few signed numbers and status lights.

That interface was not crude in the sense of being careless. It was stripped to the information and actions the mission required. The computer, DSKY, crew and controllers were parts of one operating procedure. NASA’s Apollo 11 mission archive makes clear how many systems and people had to work together before two astronauts could step onto the surface.

There is another revealing fact. The Smithsonian’s history of the AGC and early integrated circuits notes that no Command Module or Lunar Module AGC suffered a hardware failure during a mission. Raw capability was scarce; trustworthiness was not optional.

An old, simple charger could largely be understood as power-conversion circuitry. A modern high-power USB-C charger has a conversation to conduct. It may have to detect that a cable has been connected, work out its orientation, negotiate a safe voltage and current using the USB Power Delivery protocol, monitor temperature and current, and shut down when it detects a fault.

Infineon’s EZ-PD CCG3PA controller is sold specifically for power adapters, mobile chargers and similar products. Inside it is a 32-bit Arm Cortex-M0 processor, 64 KB of flash and 8 KB of SRAM. The manufacturer’s data sheet specifies a CPU clock up to 48 MHz. On the simplest numerical comparison, that little controller has twice Apollo’s erasable memory and a clock running roughly 48 times as fast.

Texas Instruments describes the same hidden complexity in its standalone USB Power Delivery controller: the chip detects the cable, communicates over the connector’s configuration channel, negotiates power and then enables the appropriate electrical path. The charger does not need lunar guidance, but it does need a tiny, specialised computer.

One distinction is worth guarding. A charger’s power-switching frequency is not necessarily the clock speed of its embedded processor. Both are measured in hertz, but they describe different events. The meaningful comparison here is between the Apollo clock and the digital controller’s clock, not every high-frequency signal inside the charger.

Qualcomm lists a maximum CPU frequency of 4.47 GHz for one Snapdragon 8 Elite variant. Compared only with the AGC’s approximate 1 MHz clock, that is a factor of about 4,470, not millions.

Clock is merely the opening line. A phone contains several powerful 64-bit CPU cores, large caches, a highly parallel graphics processor, dedicated image processors and an AI accelerator. It has gigabytes of working memory. Eight gigabytes alone is more than two million times the capacity of 4 KB. On suitable workloads, modern components perform billions or trillions of operations per second, while the AGC worked on the scale of tens of thousands of basic instructions per second.

That makes “millions of times more computational capability” a fair description of the general gulf, especially when memory, parallel arithmetic and specialised workloads are considered. It is not a universal benchmark result. The multiplier changes radically depending on whether we measure integer instructions, floating-point maths, image processing, storage, response time or energy per operation. There is no honest conversion table saying one phone operation equals a fixed number of AGC operations.

Nor does the phone’s overwhelming benchmark victory make it a better Apollo computer. A consumer handset is not qualified for launch vibration, vacuum, radiation or the thermal extremes of spaceflight. Its enormous software stack runs background services and has timing behaviour that engineers would not accept inside a tightly controlled guidance loop. Capability and suitability are different questions.

The best demonstration arrived while Eagle was descending. The computer displayed 1201 and 1202 program alarms after receiving more work than it could complete on schedule. Its executive restarted, preserved critical state, resumed high-priority guidance and control jobs, and declined some less important work. Mission controllers recognised that the landing functions were surviving and told the crew to continue.

That incident is sometimes reduced to “Apollo’s tiny computer nearly crashed.” NASA’s Lunar Surface Journal account of the program alarms shows something more interesting: limited hardware had been given a recovery system that understood priorities. Our earlier closer look at the 1201 and 1202 alarms explores that episode in greater detail.

This is why the comparison with a charger or smartphone should not end with amazement at how weak the AGC appears. Computing hardware has become almost absurdly abundant. The harder achievement is deciding exactly which work must happen, when it must happen, what can be dropped under pressure and how people will know whether the system remains safe.

The miracle was not that Apollo engineers somehow performed modern computing with almost no computer. They did not need modern computing. They identified the smaller, harder set of things that a lunar mission absolutely required, then made that narrow machine dependable enough to trust with a landing.