Data Centers in Space Don’t Work. Quantum AI Data Centers in Space Are an Absurdity.

I have wanted to write about data centers in space since a startup called Lumen Orbit raised its seed round on the strength of a white paper and a rendering. I thought the idea was nonsense then, and I said so privately. I did not say so publicly, because orbital thermodynamics is not my field and I did not want to be one more voice piling onto a startup for the sport of it. That restraint lasted until July, when an investor I sometimes help with technical due diligence called and asked me about quantum AI data centers in space. The quantum half is my field. So here we are.

He wanted to talk through a hypothetical, or what he called a hypothetical, though I suspected he was evaluating an active pitch. The scenario: a startup proposing to build quantum AI data centers in orbital space. Superconducting quantum computers and GPU clusters on satellites, powered by solar panels, cooled by the vacuum of space, selling quantum computing and quantum AI as a service, including quantum-enhanced model training, quantum optimization, and quantum simulation workloads. He walked me through the concept in broad strokes, without naming a company or sharing a deck, and asked whether the physics worked.

It does not. I told him why, and he told me to write about it. He had given me no details, so there was nothing to keep confidential. This is also, inevitably, the article I have been not writing for two years, because before you can explain why quantum AI data centers in space are nonsense, you have to explain why classical data centers in space are, at best, a multi-decade engineering aspiration that the current wave of venture capital is treating as a near-term business plan.

Three layers of impossibility stack here. Each one, by itself, is sufficient to kill the pitch. Stacked together, they represent what may be the highest concentration of unsolved engineering problems per dollar of venture funding in the history of technology investment.

Data centers in space do not work

The pitch for putting AI compute in orbit starts with a real observation: terrestrial data centers are running into power constraints. AI training runs are consuming gigawatts. Permitting new facilities takes years. Communities are pushing back. Senator Bernie Sanders and Representative Alexandria Ocasio-Cortez announced the Artificial Intelligence Data Center Moratorium Act in March 2026, proposing to pause construction or expansion of covered AI data centers, defined to include facilities above 20 MW, until Congress enacted specified safeguards. More than a hundred local communities and roughly a dozen US states have pursued their own restrictions.

The orbital data center pitch says: skip all of that. Launch your compute into a dawn-dusk sun-synchronous orbit, harvest 24/7 solar energy with no atmospheric losses, and radiate your waste heat into the vacuum of space. No permitting, no grid connection, no water consumption, no angry neighbors. Investors have put hundreds of millions in venture funding behind that promise before anyone solved the thermodynamics. To understand why the physics kills it, it helps to know how we got here.

How orbital data centers became a billion-dollar idea

The concept was commercialized by a startup called Lumen Orbit, founded in January 2024 and later renamed Starcloud. In September 2024, Starcloud published a white paper titled “Why We Should Train AI in Space,” laying out the case for gigawatt-scale orbital data centers powered by solar panels in dawn-dusk sun-synchronous orbits. The paper proposed a 5 GW facility, eight times more powerful than the largest operating terrestrial data center, assembled from 40-megawatt compute containers docked to a central spine, with 4 km × 4 km solar arrays and radiators that would dissipate waste heat into the vacuum of deep space. (A later filing with the Federal Communications Commission (FCC) replaced the single structure with up to 88,000 satellites delivering 20 GW. The white paper is still the document that raised the money, so it comes first.)

The white paper attracted serious capital. Starcloud raised roughly $34 million in seed funding, including In-Q-Tel (the CIA’s strategic investment arm) and scout funds from Andreessen Horowitz and Sequoia, launched a single satellite carrying one Nvidia H100 in November 2025, and in March 2026 closed a $170 million Series A at a $1.1 billion valuation, the fastest Y Combinator company in history to reach unicorn status. By August 2026, a $250 million extension brought the valuation to $2.3 billion, with Nvidia and Cisco Investments joining the cap table. Total disclosed funding reached approximately $450 million.

The money attracted competition. Google announced Project Suncatcher, a research program to orbit clusters of satellites carrying Google’s Tensor Processing Unit (TPU) AI chips, linked by optical connections, with a two-satellite test mission planned for early 2027 in partnership with the satellite imaging company Planet. SpaceX filed with the FCC on 30 January 2026 for up to one million orbital data center satellites; days later, it announced the acquisition of xAI, Elon Musk’s AI company, consolidating the compute demand and the launch capacity under one roof. Blue Origin filed “Project Sunrise” for 51,600 satellites. Relativity Space, acquired by former Google CEO Eric Schmidt, pivoted toward launching compute infrastructure into orbit.

Those filings cover more than a million satellites across four companies, and no demonstrated engineering supports any of them.

Thermodynamics is the constraint, not silicon

Andrew Cavalier of ABI Research published the definitive technical analysis in IEEE Spectrum in June 2026, and the central finding is the one that every pitch deck in this space glosses over: in a vacuum, the only way to remove heat is radiation. Conduction and convection, the two mechanisms that cool every data center on Earth using air, water, or refrigerant, do not work without an atmosphere. There is no air to blow across a heat sink. There is no river to pump through a cooling tower. There is only the Stefan-Boltzmann law.

That law says the power you can radiate from a surface is proportional to the radiator area times its absolute temperature raised to the fourth power. For a space systems architect, the implication is direct: every watt of compute you deploy in orbit requires a corresponding area of radiator that you must also launch from Earth.

A single Nvidia H100 GPU draws 700 watts. To keep that chip at 60 °C, the operating temperature that balances performance and longevity, Cavalier calculated that you need 1.4 square meters of radiator surface facing deep space. Scale that to a standard AI rack holding 32 H100s, which draws around 40 kilowatts once CPUs, memory, and networking are included, and you need an 80-square-meter radiator, roughly the size of a pickleball court for one rack. A 100-megawatt data center needs roughly 2,500 of those courts, or about 200,000 square meters of radiator.

Starcloud did not propose a 100-megawatt data center. Starcloud proposed a 5 GW data center, fifty times larger. At the same thermal performance, 5 GW of compute requires roughly 10 km² of radiator, about three times the area of Central Park. That is for radiators alone, before accounting for the solar panel area needed to generate the power in the first place. Starcloud’s own figures put that at 16 million square meters. The combined surface area of radiators and solar panels exceeds 26 square kilometers, nearly half the area of Manhattan. And before accounting for degradation.

Those calculations assume fresh, undegraded hardware. Over a satellite’s typical five-year life in low Earth orbit, the radiator surfaces degrade. Ultraviolet light, atomic oxygen erosion, cosmic ray damage, and contamination attack both the emissive coatings and the underlying thermal-optical properties. Cavalier’s degradation model in the IEEE Spectrum analysis, accounting for the full suite of environmental effects beyond the emissivity shift from 0.92 to 0.90, shows the required radiator area increasing by roughly 40 percent over the satellite’s life. That means launching an additional 4 square kilometers of radiator, roughly the area of Central Park plus the Reservoir, that produces no compute on day one and exists solely to compensate for the cumulative degradation. The total radiator area with degradation margin: approximately 14 square kilometers. Add the 16 square kilometers of solar panels and the combined structure approaches the area of a small American city, larger than Hoboken, comparable to Key West.

The radiator problem compounds at the scale Starcloud proposed. Brian McManus of the YouTube channel Real Engineering, in a collaboration with IEEE Spectrum, ran the Stefan-Boltzmann calculation against Starcloud’s white paper figures for a 5 GW facility and found that the radiator alone would need to be four kilometers tall and 840 meters wide. The heat from the compute cluster must travel to those radiators through pipes filled with coolant fluid. McManus calculated that this would require circulating roughly 69,000 kilograms of glycol per second through the structure. That mass flow rate equals 134 Space Shuttle main engine turbopumps running simultaneously, or draining an Olympic swimming pool every 40 seconds.

What Starcloud’s white paper does not address

Every section of the white paper that reaches a hard physics constraint pivots to a claim that a solution is “in development” or “possible” and moves on without substantiating it.

On thermal management, the single hardest engineering problem for any orbital data center, the paper states that “a workable design is possible without heat pumps.” It does not specify how waste heat from a centralized compute cluster reaches radiators that must cover square kilometers of surface area. It does not account for the coolant system: a mass flow rate of 69,000 kg/s requires extensive parallel plumbing, high-capacity pumps, valves, heat exchangers, and a substantial coolant inventory. The paper does not estimate the mass of that infrastructure. Whatever it is, it adds to a launch mass the paper already understates by an order of magnitude. It does not address the pumps, the piping, the valves, the seals, or the structural reinforcement needed to manage thousands of tonnes of pressurized fluid in a structure that must also maintain precise orbital attitude. It does not address what happens when – not if – a seal fails or a micrometeorite punctures a coolant line.

On attitude control, the problem of keeping a structure kilometers wide pointed at the sun while fluid mass sloshes through it, the paper says that “these systems are also in development at Starcloud.” Attitude control for the International Space Station (ISS), which has roughly 1/6,000th of the proposed surface area and no significant fluid mass flow, requires four 300 kg control moment gyroscopes plus thruster backup. The moment-of-inertia scaling for a 4 km × 4 km structure with hundreds of thousands of tonnes of moving fluid has no engineering precedent. The paper does not estimate the control moment requirements, the gyroscope mass, or the fuel budget for thruster-based corrections.

On radiation effects, the paper states that “logic devices have been shown to be resilient to radiation, especially when used in AI training applications,” citing a single 2020 IEEE paper. It then claims that larger containers’ lower surface-area-to-volume ratio reduces per-unit protection needs. Radiation attenuation depends on particle energy spectra, material composition, and secondary emission. Container geometry changes none of them. Google’s own Suncatcher paper, published a year later, was substantially more cautious, finding that while their TPUs survived proton-beam testing for inference workloads, the effect on training remained unresolved.

On launch costs, the paper quotes $30 per kilogram to low Earth orbit (LEO), a figure that McManus and multiple independent analysts have flagged as unsupported. Voyager Technologies disclosed a $90 million commitment for a launch on SpaceX’s Starship, the heavy-lift vehicle every orbital data center proposal depends on, implying roughly $600–900 per kilogram depending on payload utilization. That remains the only publicly documented commercial Starship price point. At $30/kg, Starcloud’s cost model shows orbital compute beating terrestrial. At $900/kg, it does not come close. The paper’s entire economic case requires a launch cost that no vehicle has achieved and no operator has offered.

On mass budgets, the paper quotes solar panel mass at a power density of 1,000 watts per kilogram. SpaceX’s own projections for TERAFAB, its planned chip fab for space-hardened processors, assume 100 W/kg. The most advanced laboratory-stage thin-film panels that have never flown achieve roughly 300 W/kg. Starcloud’s figure is four times higher than the optimistic end of a technology curve that has not yet produced a flight-qualified product. McManus recalculated with realistic panel densities and found the solar array alone would mass closer to 50,000 tonnes, ten times Starcloud’s figure. The radiator, using current-generation panels at 10 kg per square meter, adds another 33,600 tonnes. McManus estimated that when pumps, coolant inventory, radiation shielding, fuel, inertia wheels, structural supports, and the compute hardware are included, the station exceeds 113 million kilograms, more than a Nimitz-class aircraft carrier. For a comparison the space industry will recognize: Jonathan McDowell’s annual census puts the total mass of everything in Earth orbit at the end of 2025 at 16,185 tonnes. Every active satellite, every dead one, every spent rocket stage, the ISS, all of Starlink. Starcloud’s single facility would weigh seven times that. And 2025 was a record year for launch, with 3,193 tonnes of payload reaching orbit worldwide. At that rate, with every rocket on Earth devoted to nothing else, lifting the station would take 35 years. And that is McManus’s mass, before the radiator margin and the debris shielding I add below, which take it past 65 years. The white paper says one Starship could do it in two to three months.

McManus summarized the pattern: “It really seems like anyone with some renders and a whitepaper written by someone being gassed up by an overly agreeable AI can get VC funding these days.”

Andrew Côté, an engineering physicist who published a separate technical analysis, raised a problem that neither the white paper nor most critics address: mechanical resonance. In vacuum there is no air to damp vibrations, so any mechanical disturbance (a thruster pulse, a docking impact, a pump cycling, uneven solar heating) dumps energy into the structure’s resonant modes, where it accumulates. “Basically, in space everything is a high quality-factor mechanical resonator,” Côté wrote. (Quality factor, or Q, measures how long a resonator rings after being struck.) For a wafer-thin structure kilometers across, the lowest bending modes have frequencies below 0.1 Hz, exactly where the pumps circulating coolant produce the most noise. Côté’s question about the resulting operational constraint, using ODC for orbital data center, answers itself: “Is every single mechanical operation under extreme scrutiny for the risk of introducing runaway mechanical oscillations into your ODC megastructure that might tear it apart because of runaway resonance? Yes.”

His closing line on the permitting argument is the most concise rebuttal of the whole orbital pitch I have read: “What’s easier, changing laws to permit more data centers, or building a 16 square kilometer solar array in space? Exactly.”

The 2026 design is not the 2024 design

Starcloud has moved away from the white paper. The 4 km × 4 km structure with a central spine is gone from the company’s roadmap. Starcloud-2, announced for October 2026 and by August slipped to rideshare flights in 2027, is an 8 kW satellite carrying several GPUs and what the company calls the largest deployable radiator flown on a private spacecraft. Starcloud-1 flew with two GPUs, an H100 and an A6000, and the second failed during launch. Starcloud-3, funded by the Series A, is a 200 kW node of about three tonnes: solar panels, chips, and optical terminals, sized so that fifty fit in the Starlink dispenser on a single Starship. It depends on Starlink’s laser network for data transit. The FCC filing asks for 88,000 of them, 20 GW in aggregate, and Johnston places that constellation in the second half of the 2030s. It is the architecture Google’s Suncatcher proposed and the one McCalip’s calculator prices: a constellation of small satellites. Google’s engineers cite the white paper as their example of the monolithic alternative and give three reasons for not building one: such structures “would have to be assembled in space by humans or robots; collision avoidance would be more cumbersome; and structural requirements would add mass and complexity.”

The heat still has to move. Five gigawatts divided by glycol’s heat capacity and a 25-degree loop rise is about 69,000 kg/s whether one structure moves it or 25,000 do. Each node’s loop is two meters long instead of two kilometers, though, and pumping power, pipe mass, and coolant inventory all scale with flow times distance, so the pumps, pipes, and glycol come to roughly a thousandth of the megastructure’s. McCalip, Google, and now Starcloud all arrived at the same architecture for that reason, and it is a real fix. The node also has no bending modes below 0.1 Hz to feed. Its attitude control is a solved problem at Starlink scale. And it can be built to demise on reentry, so nothing has to be taken apart in orbit.

Radiator area, solar area, launch mass, and debris exposure scale with power, and 5 GW is still 5 GW. The Stefan-Boltzmann law sets radiator area per watt, not per structure: 5 GW still needs 10 km² of it and 16 km² of solar, in the same debris field, spread over 25,000 targets instead of one. The mass does not shrink either. Starcloud builds attitude control, propulsion, power conditioning, optical terminals, and a frame 25,000 times over, at 500 kg to a tonne apiece, and 5,000 of those per gigawatt weigh about what the megastructure spent on plumbing. Per gigawatt, the mass is a wash. Three tonnes for 200 kW is 15 tonnes per megawatt. Google’s paper takes the Starlink v2 mini as its best-in-class proxy for mass per kilowatt: 575 kg for an estimated 28 kW, about 20 tonnes per megawatt, for a communications satellite with no GPU payload. Starcloud’s node carries 285 GPUs and hundreds of square meters of radiator and claims to weigh less per kilowatt than a Starlink. That requires the 1,000 W/kg panels the white paper assumed and radiators lighter than any that have flown. At the panel and radiator densities above, the node weighs 6 to 11 tonnes, two to four times Starcloud’s figure. For 5 GW, the same power as the white paper’s structure, that is 25,000 nodes: 75,000 tonnes at Starcloud’s own three tonnes each, 23 years of 2025’s global launch, or 150,000 to 275,000 tonnes at 6 to 11, 47 to 86 years, the same range as the megastructure. The full 88,000-node filing needs 1,760 fully loaded Starship flights even at Starcloud’s own mass.

Collision avoidance scales with the number of maneuvering objects, and 88,000 three-tonne satellites with deployed radiators is nine times Starlink’s fleet, at roughly ten times the cross-section apiece, in the same sun-synchronous band. There is no servicing fleet in this design, because nobody sends a robot to swap a GPU inside a 200 kW node; the operator replaces the node. Google’s paper says the same in its own words: replacing failed chips is “obviously impracticable in space” and “the simplest solution is redundant provisioning.” At 9 percent GPU failure a year, every node is a fifth dead within two years, which is also when its chips are obsolete, so the operator relaunches the whole constellation every two to three years. That is 30,000 to 40,000 reentries a year. Starlink retired 688 satellites in 2025.

Training and inference are different workloads, and the new design can do only one of them. To train a frontier model, tens of thousands of GPUs work on the same problem and share their results with each other after every step, which is every second or two. The exchange is terabytes per step and it has to finish in microseconds. So a training cluster is one building: NVLink at 900 GB/s per GPU inside each server, InfiniBand at 400 Gb/s between servers, nothing more than a few hundred meters from anything else. Starcloud’s own authors designed around the same limit and put every container “within a few hundred meters of each other.”

Starcloud-3 nodes talk to each other through Starlink laser terminals, at around 100 gigabits per second, over a mesh built for internet traffic. The 285 GPUs inside one node have about a thousand times that bandwidth between them on the ground. Google’s engineers measured the same gap for Suncatcher. Commercial inter-satellite links run 1 to 100 gigabits per second, training needs on the order of 10 terabits, and their bench test reached 1.6. Their answer was to fly the satellites within a kilometer of each other, in clusters of 81. Google also points to work on training methods that need less traffic between nodes, and describes it as an open research program. Light also takes 330 microseconds to cross 100 kilometers, and a training step cannot wait that long.

Eighty-eight thousand nodes on a laser mesh can run inference, where the whole model fits on one node and each request is independent. They can run edge processing for other satellites, where each data stream is its own job. That is Starcloud’s business today. Its first commercial workload was Capella’s radar data, and by August TechCrunch was describing the company as building satellites that “perform AI inference in orbit.” It is a real business and a small one. Euroconsult put the whole commercial Earth-observation market, data and services together, at $4.6 billion in 2021 and forecast $7.9 billion for 2031. The white paper was titled “Why We Should Train AI in Space.” The design that can be built does not train. The valuation was set for the one that would.

The cost models that proponents publish are incomplete

Several independent analysts have tried to build honest cost models for orbital data centers, and their published numbers already look bad. Even those unfavorable numbers understate the real cost: none of the published models fully accounts for the thermodynamic infrastructure that orbital operation requires.

ABI Research’s total-cost-of-ownership (TCO) model, using generous assumptions (Starship at $44 per kilogram to LEO, terrestrial energy at $0.20 per kilowatt-hour), found that running a GPU in space for a year costs at least an order of magnitude more than the same GPU on the ground, as published in Cavalier’s IEEE Spectrum analysis. Andrew McCalip, an engineer at Varda Space Industries, built an open calculator that anyone can audit. His model puts a 1 GW orbital data center at $42–51 billion over five years, versus roughly $16 billion terrestrial, a 3x penalty on capital costs alone. IEEE Spectrum’s own headline on McCalip’s work asked the question directly: “How Stupid Would It Be to Put Data Centers in Space?”

But here is what those models omit or undercount. McCalip’s calculator does not model the full pumping infrastructure for kilometer-scale radiators. ABI Research’s back-of-envelope model assumed “an Nvidia H100 server rack launched with the requisite-size solar panel and radiator on a spacecraft akin to Starcloud’s pilot launch”: a single-rack satellite, not a multi-gigawatt facility with the thermal plumbing, rigid-body dynamics, and attitude control that a kilometer-scale station requires. Neither model accounts for the mass of the coolant system. At 69,000 kg/s, the pumping infrastructure, parallel plumbing, and coolant inventory required for a 5 GW station add substantially to the launch mass beyond the compute payload.

Neither model accounts for the 2–4 year refresh cycle of AI accelerators, or for the failure rate under load. Côté ran the numbers. He counts roughly 1.4 million H100-class GPUs in a 1 GW facility, and under sustained AI training loads, operators like Meta see roughly 9 percent of them fail per year. That is 350–400 failed GPUs per day. On Earth, a technician swaps the card in under an hour. In orbit, the dead unit stays dead until a servicing mission reaches it, and the facility’s compute capacity degrades by 10 percent after 13 months and 20 percent after 26 months from hardware failures alone. The orbital data center is a depreciating asset that cannot be repaired.

And several categories of cost do not appear in any published model at all.

Deorbiting

Every structure launched into low Earth orbit must eventually come down, responsibly or as uncontrolled debris. Starcloud’s white paper proposes that old compute containers “may be re-entered in the payload bay of the launcher or are designed to be fully demisable (completely burn up) upon re-entry.” The first option means sending an empty Starship to orbit, docking with a container, and returning it, at roughly the same launch cost as putting it there in the first place. The second option, controlled atmospheric burnup, has been demonstrated for small satellites weighing a few hundred kilograms. Starcloud’s facility masses over 100,000 tonnes and spans kilometers. A structure of that size cannot be deorbited as a single unit; it would need to be disassembled into pieces small enough to burn up completely, or small enough to fit in a return vehicle. The solar panels and radiators, thin gossamer structures designed to maximize surface area, would shred and fragment under aerodynamic forces long before reaching temperatures sufficient for complete burnup. The fragments would spread across hundreds of kilometers of ground track. No entity has attempted controlled deorbiting of an object even 1 percent of this mass. Deorbiting a 5 GW facility would require a decades-long disassembly and disposal program costing billions, funded and executed even if the business fails.

Micrometeorite damage

Orbital debris and micrometeoroids travel at 9–10 km/s for debris and up to 20 km/s for interplanetary micrometeoroids, roughly 10–25 times the speed of a rifle bullet. At these velocities, a particle the size of a grain of sand carries enough kinetic energy to puncture aluminum shielding. A paint flake 0.3 mm across, traveling at 10 km/s, punched a hole through a Space Shuttle radiator panel and would have ruptured the Freon-22 coolant tube behind it if not for a protective doubler strip that NASA added specifically because earlier impact assessments showed the coolant system was vulnerable.

Orbital spacecraft have suffered serious coolant leaks after suspected micrometeoroid strikes. In December 2022, a hole less than one millimeter across appeared in the radiator of the Soyuz MS-22 crew vehicle docked to the ISS. NASA broadcast it as it happened: a shower of frozen coolant spraying from the spacecraft. The entire coolant loop drained within 18 hours. Roscosmos, the Russian space agency, declared the vehicle unsafe to return its three-person crew and launched a replacement Soyuz two months later, at the cost of an entire mission. In October 2023, the backup radiator on the ISS’s Russian Nauka module lost 72 liters of coolant from a similar strike. Earlier radiator punctures on the ISS were patched by astronauts on spacewalks. The ISS has roughly 2,500 square meters of solar panel area and a few hundred square meters of exposed radiator.

A 5 GW orbital data center would present approximately 30 million square meters of exposed surface: 16 million square meters of solar panels plus 14 million square meters of radiator with degradation margin. That is roughly 12,000 times the ISS solar panel area.

Geoffrey Marcy, the astronomer whose team discovered most of the first hundred known exoplanets, published a peer-reviewed analysis of orbital data centers in Monthly Notices of the Royal Astronomical Society in May 2026, and it gives the number to scale from. The ISS has recorded more than 1,400 impacts in 25 years, roughly one a week. Most left pits and craters. A handful punctured coolant systems. At 12,000 times that weekly rate, the arithmetic gives well over a thousand impacts per day, and several serious ones.

That arithmetic is rough. A planar structure flying edge-on presents less than its full area to oncoming debris, which cuts the rate. Two facts push it back up. The ISS orbits at 400 km; the proposed data centers would orbit at 600 to 1,000 km, the most congested debris band in low Earth orbit. And the ISS protects its pressure hull with layered debris shielding; a radiator cannot be armored without destroying the thermal performance it exists to provide. A tenth of that thousand, allowing for orientation, is still more than a hundred strikes a day on a structure whose radiators carry pressurized coolant and whose repair crew does not exist.

The consequences of a coolant line puncture at these flow rates are not analogous to a slow leak. A breach in a high-pressure, high-flow coolant pipe produces a rapid decompression event. The escaping glycol would boil, atomize, and freeze in vacuum, producing a plume of droplets and ice particles that coats nearby solar panels and optical surfaces, potentially degrading the facility’s power generation and communications in a cascading failure. Isolating a damaged section requires autonomous valve closure in milliseconds, by valves that must themselves survive the debris environment.

Protecting against these impacts is possible in principle. The ISS uses stuffed Whipple shields (an aluminum bumper, Nextel ceramic fabric, Kevlar, and a rear pressure wall) weighing approximately 9–10 kg per square meter for pressure-hull protection. Applying that shielding standard across the entire exposed thermal and power system is an illustrative upper bound. No one has published a shielding design for an orbital data center. Adding protective layers to a radiator can interfere with its thermal performance, and solar panels cannot be armored uniformly without blocking sunlight. At 9 kg/m² across 30 million square meters, the shielding mass reaches 270,000 tonnes, roughly three times the mass of all the compute, solar panels, and radiators combined in Starcloud’s optimistic estimate. Even shielding only the pressurized coolant surfaces would add tens of thousands of tonnes. No proponent’s model includes any version of this mass.

Even with shielding, coolant loss would be continuous. Whipple shields prevent penetration of the pressure hull by the most common debris sizes, but sub-threshold fragments still get through. Particles too small to penetrate the shield can still create pinhole leaks in coolant lines, producing a slow but steady loss of working fluid. Over a five-year operating life, cumulative coolant loss would require regular resupply missions, each one a Starship launch carrying replacement fluid at $900+ per kilogram. The coolant itself is a consumable, and its resupply adds a recurring operating expense that no published model accounts for.

Starcloud’s white paper acknowledges that “small debris collisions with solar arrays are generally passive over time,” citing ISS experience. This is true for solar cells, which are solid-state devices that lose a few square centimeters of generating area per impact. It is not true for radiator panels circulating thousands of tonnes of pressurized coolant. The distinction between a passive structure (solar panel) and an active fluid system (radiator) under micrometeorite bombardment is the distinction between a cracked window and a ruptured pipeline.

The servicing fleet

Every one of the failures above needs someone to fix it. On the ISS, that someone is an astronaut on a spacewalk. The Soyuz MS-22 leak was inspected by the station’s Canadarm2 robotic arm and then by crew. Radiator strikes on the ISS have been patched by hand. An orbital data center has no crew, so every proponent’s answer is the same word: robots.

Cavalier’s IEEE Spectrum analysis states the requirement plainly. The orbital domain “will require automated servicing vehicles capable of swapping out degraded radiator panels and upgrading fried servers.” No such vehicle exists. Nothing in orbit today can autonomously locate a punctured coolant line on a structure kilometers wide, isolate it, replace the section, and recharge the loop. Nothing can pull a failed GPU from a sealed container and seat a replacement. The proposals assume robots that nobody has designed.

Assume they can be built. Now account for them. The servicing fleet launches at the same price per kilogram as everything else. Its power comes out of the facility’s own solar budget. Maneuvering around a kilometer-scale structure without colliding with it takes propellant, which needs resupply. Spare parts mean either a pre-positioned inventory in orbit or an on-demand launch per failure. The robots work in the same debris environment that damaged the thing they are repairing, so they get hit, fail, and need replacing themselves. And every docking, every arm movement, every thruster pulse from a servicing vehicle is a mechanical disturbance on a structure that Côté identified as a high-Q resonator with bending modes below 0.1 Hz.

Then scale it. In a 1 GW facility, 350 to 400 GPUs fail every day. If a servicing operation takes an hour and a robot can work around the clock, that is 15 to 17 robots doing nothing but GPU replacement, before a single radiator repair or coolant recharge. Côté ran the resupply economics: ferrying a pallet of 100 replacement GPUs to orbit on Starship runs roughly the price of building a new compute pod on the ground. Repair, replacement, and the original build all cost about the same.

No published cost model includes a servicing fleet: the robots, their power, their propellant, their spares, their launch, their own failure rate, or the compute capacity lost while waiting for one to arrive. The models price a data center that never breaks. The one that breaks 350 times a day is a different facility. When I price the fleet below, it comes to more than the terrestrial data center it would be maintaining.

Collision avoidance, imposed on everyone else

SpaceX reported to the FCC that its Starlink constellation performed 300,000 collision avoidance maneuvers in 2025. The maneuver count scales with the total objects in orbit and the congestion of the orbital regime. Every orbital data center constellation (Starcloud’s 88,000 satellites, SpaceX’s million, Blue Origin’s 51,600) would operate in the same sun-synchronous band between 500 and 1,000 km altitude. Google’s Suncatcher paper proposes clusters of 81 satellites flying in a bounded formation within roughly one kilometer of each other. A collision avoidance maneuver by one satellite in that formation cascades, and all 81 must adjust.

Marcy’s collision assessment in the same paper is blunt. More than a million debris objects between 1 and 10 cm already occupy low Earth orbit. Sun-synchronous satellites cross the poles, so their velocity is nearly perpendicular to debris in equatorial orbits, producing relative impact speeds near 10 km/s. A 1 kg fragment at that speed delivers roughly 50 million joules, about 17,000 times the energy of a 12-gauge shotgun blast. “Manoeuvring kilometre-scale data centres to avoid such impacts would be difficult,” Marcy writes, and a collision cascade “could render LEO unusable for hundreds of years.”

The cost of avoidance maneuvers falls not only on the data center operator but on every other satellite operator in the same orbital regime. Starlink, Amazon’s Kuiper, OneWeb, and every government satellite in sun-synchronous orbit would need to perform additional avoidance maneuvers to accommodate the data center constellations. Those costs are externalized, borne by others, and do not appear in any proponent’s TCO model.

Marcy’s paper also describes what an orbital data center would do to the night sky. A 4 km × 4 km solar array at 550 km altitude subtends 0.42 degrees of sky, nearly the angular diameter of the full Moon, and would shine at magnitude −5 to −7, several times brighter than Venus. In dawn-dusk sun-synchronous orbit, these structures stay in sunlight permanently and would cross the sky as resolved mechanical shapes for ninety minutes after every sunset and before every sunrise, occulting stars, planets, and the Moon itself for seconds at a time. Nobody has priced what it costs to take the night sky away from everyone on Earth who did not consent to the trade.

When you add the unmodeled thermal infrastructure, the structural mass, the coolant, the attitude control systems, the deorbiting program, the micrometeorite shielding, the servicing fleet, the collision avoidance burden, and the hardware refresh problem, the 3x and order-of-magnitude estimates are lower bounds. They measure the cost of putting a GPU in orbit and keeping it powered. They do not measure the cost of building and operating a commercially competitive data center in orbit, one that matches terrestrial uptime, latency, maintenance, and hardware refresh capabilities.

A terrestrial hyperscale operator swaps a failed drive in hours, upgrades GPU racks on a two-year cycle, scales capacity by adding building wings, and pays an electricity bill. An orbital operator must instead launch a replacement satellite, dock it to a structure kilometers wide, decommission and deorbit the failed unit, avoid collisions with thousands of nearby satellites during the operation, and do all of this autonomously because no human is present. Every one of those operations has a cost that scales with the mass, the orbital altitude, the constellation size, and the launch cadence. None of it appears in the published models.

No published cost model reaches the items above, so I priced them myself, with the sources already cited where they give a number and my estimates where they do not. The result is quick and dirty and for illustration only. Every line can be argued. The sum cannot be argued down to 3x. Figures are per gigawatt over five years and exclude the initial GPU purchase, which costs the same on the ground and in orbit; that is the basis McCalip’s $16 billion terrestrial figure uses.

The low case takes McManus’s radiator mass, shields only the coolant surfaces, prices launch at the Starship rate Voyager’s commitment implies, and assumes one catastrophic coolant-line strike a year. The high case takes Cavalier’s radiator area, shields everything to ISS standard, prices launch at Falcon 9, and assumes two. Both mixed cases give roughly 22x. For the distributed design Starcloud now proposes, replace the plumbing and resonance development lines with one for manufacturing 25,000 compute spacecraft; everything else in the table is per watt. Nothing in the table is exotic. The servicing fleet alone, the robots and their spares and their launches, costs $19 billion to $27 billion per gigawatt, more than the entire terrestrial data center it would be maintaining.

I left two costs out of the table because nobody can price them. One is age: a facility that takes a decade to build is running GPUs years older at switch-on than the terrestrial fleet it competes with, and refreshing them costs a launch each time. The other is launch capacity.

The table prices launch at today’s rate for a demand that is decades of today’s supply, which is the assumption Starcloud’s white paper makes too. The low case needs roughly 1,400 Starship flights to orbit. Starship has flown none. The high case needs 5,500. At 2025’s record global rate, every rocket on Earth lifting nothing else, the low case takes 65 years and the high case 174, and most of the GPUs launched in the first half of either build are dead or obsolete before the last radiator panel arrives. A single customer buying decades of the world’s launch capacity does not pay list price. Either the price rises until every other customer drops out, or someone builds a launch industry several times the size of the one that exists. Nobody has priced that either. The bottom of the table therefore assumes a launch industry that does not exist, and the top is the closer of the two.

The multiplier for a 1 GW facility that matches terrestrial uptime is between 10x and 50x at today’s prices, and higher for the two reasons above. McCalip got 3x by assuming no hardware ever fails. At 10x, one gigawatt in orbit costs $160 billion over five years; at 50x, $750 billion, for a facility that costs $16 billion on the ground. The 5 GW facility Starcloud proposes costs $0.8 to $3.7 trillion. The upper figure is an eighth of US GDP, for one data center. Nobody has proposed a launch price that closes a gap of that size within the investment horizon of any fund operating today.

Google’s own Project Suncatcher paper, the most technically rigorous analysis published by a proponent, concludes that cost parity requires launch prices to fall to approximately $200 per kilogram. The methods section makes the parity narrower than the headline. Google compares the launch cost of a satellite’s power system, amortized over five years, with a terrestrial data center’s electricity bill, and says it leaves out infrastructure, buildings, and chips. Parity at $200 a kilogram is parity on one line. The paper also says what reaching $200 takes: about 180 Starship launches a year sustained to 2035 and roughly 370,000 tonnes of cumulative demand, which the paper says is unlikely to appear without constellations like the one it proposes. So Google’s cheap launch depends on a customer that only exists once launch is cheap. The paper’s four results are the links, the formation flight, the radiation test, and the launch-cost curve; it lists thermal management and on-orbit repair as work for future milestones. Current costs on SpaceX’s Falcon 9 run $1,500–3,600 per kilogram. Starship has not yet demonstrated a published commercial price. Voyager Technologies’ disclosed Starship commitment implies roughly $600–900 per kilogram, still 3–4.5 times the parity threshold. Google’s own timeline puts cost parity in the mid-2030s. Elon Musk says two to three years. No independent analyst agrees with Musk. Nvidia CEO Jensen Huang has said the economics are “poor today,” and Nvidia, as the GPU supplier, would benefit more than any other company if orbital demand materialized. AWS CEO Matt Garman: “It is just not economical.”

What actually exists versus what is being funded

Starcloud-1, the one satellite the company has launched, carried a single Nvidia H100 into orbit. IEEE Spectrum’s computing editor Dina Genkina put it plainly: “Their radiator was too weak to let the chip run at full power.” The satellite demonstrated that a GPU can survive launch vibration and operate in microgravity. It did not demonstrate that a commercial data center can operate in orbit, any more than strapping a laptop to a weather balloon demonstrates that cloud computing works at altitude.

Google’s Suncatcher team describes its own project as a “moonshot,” and its lead researcher says the team has been trying to “prove it can’t work.” SpaceX’s million-satellite filing would cost, by the research firm MoffettNathanson’s estimate, more than the combined historical cost of every launch to orbit. Blue Origin’s CEO Dave Limp says orbital data centers will “happen for sure in our lifetime.” Blue Origin founder Jeff Bezos has estimated it could take up to 20 years.

The gap between these filings and physical reality is the gap between a zoning application and a finished building. The building requires construction techniques that have not been invented and materials that have not been manufactured at scale. The supply chain does not exist. And unlike the Wright brothers, who competed against nothing, an orbital data center competes against a terrestrial industry that cuts its cost per unit of compute every year. Every cost model cited above compares an orbital facility to the terrestrial data center of today. By the time the orbital one launches, that comparison will be several years stale, and the ground will have moved further away.

Now add quantum computing to this equation

Classical data centers in orbit face unsolved thermodynamic, economic, and engineering challenges that no proponent has demonstrated a path through. The pitch deck I was asked to evaluate proposed to compound those challenges by adding superconducting quantum computers to the satellite constellation.

A reader unfamiliar with quantum hardware might assume that a quantum computer is something like a specialized GPU, a chip you mount in a rack, connect to power and cooling, and operate remotely. That assumption is the foundation of the pitch. It is also wrong. I wrote the Building Quantum Computers series on this site and the book Quantum Systems Integration in part because the gap between vendor claims and actual system requirements has become a source of real financial risk for investors and procurement officers who take press releases at face value. A superconducting quantum computer is the most environmentally demanding computing architecture ever engineered, and every one of its requirements conflicts with orbital operation.

Millikelvin cryogenics do not belong in orbit

A superconducting quantum computer operates at 10–20 millikelvin. That is 135 to 270 times colder than the cosmic microwave background temperature of 2.7 kelvin. Space is cold, but it is not cold enough by two orders of magnitude. You still need a dilution refrigerator.

A dilution refrigerator is an industrial installation. A fully loaded cryostat from Bluefors, the Finnish manufacturer that supplies most of the industry, weighs approximately 750 kilograms in its LD or XLD configurations. Larger platforms, such as the Bluefors KIDE-class systems being deployed at national laboratories, can reach 7,000 kilograms. The system requires a vibration-isolated slab because the pulse-tube cryocooler generates mechanical oscillations at roughly 1 Hz that directly degrade qubit coherence. It requires electromagnetic shielding to prevent stray fields from shifting qubit frequencies. It requires a gas handling system for the helium mixture. And it requires helium-3.

The investor’s hypothetical was not about launching one quantum computer. It was about a data center: hundreds or thousands of superconducting quantum processors, each inside its own dilution refrigerator, each drawing its own cryogenic infrastructure, each requiring its own calibration and maintenance chain. At 750 kg per cryostat for current-generation systems, a facility with 500 quantum processors would require 375 tonnes of cryogenic hardware alone, before adding control electronics, wiring, shielding, or the classical compute infrastructure needed to operate the quantum machines. The helium-3 requirement scales linearly: each dilution refrigerator uses 20–40 liters of helium-3 mixture. Five hundred systems would consume 10,000–20,000 liters, up to two-thirds of the current annual global supply, from a source controlled by nuclear weapons programs.

Helium-3 is the working fluid in every dilution refrigerator. It is derived almost entirely from the radioactive decay of tritium in nuclear weapons stockpiles. Global supply runs at roughly 22,000–30,000 liters per year. Demand from quantum computing, advanced cryogenics, neutron detection, and fusion research is estimated at 40,000–60,000 liters per year and rising. Market prices range from $1,900 to $2,600 per liter, with purification costs exceeding $10,000 per liter. The supply is controlled by the US Department of Energy and, to a lesser extent, the Russian state nuclear corporation Rosatom.

Every one of those requirements conflicts with orbital operation. The cryostat must survive launch vibration, forces that are measured in the same g-range that qubit engineers spend years eliminating from their laboratory floors. It must operate in microgravity, which changes the behavior of the helium mixture in ways that have not been characterized for dilution refrigeration. It must cool down from 300 kelvin to 10 millikelvin, a process that takes 36 to 72 hours on Earth under controlled conditions, in an environment where a power interruption means a full warm-up cycle and a week-long recovery. And when the helium-3 mixture leaks, becomes contaminated, or cannot be recovered and purified (all routine failure modes that terrestrial laboratories handle with vendor support and spare parts), there is no resupply in orbit. On Earth, you call Bluefors. In orbit, the processor is offline until a servicing mission reaches it, and as I showed above, no such vehicle exists. In practice, the mission is over.

Calibration is not optional

Even if you solved the cryogenics, and nobody has proposed a credible path to doing so, you would face a second fundamental obstacle: superconducting qubits require continuous calibration.

Every qubit in a superconducting processor has a unique frequency that drifts over time due to two-level systems (TLS) defects in the substrate, cosmic ray impacts, and thermal fluctuations. The calibration cycle for a modern transmon processor (the dominant superconducting qubit design) runs daily. On some systems, it runs multiple times per day. Calibration involves measuring resonator frequencies, locating transitions, driving Rabi oscillations, extracting coherence times, and tuning every single- and two-qubit gate before benchmarking the full system. This is not something you automate and forget. Q-CTRL has built its entire business around automating this process, and even Q-CTRL’s systems require human oversight for edge cases.

In the systems I have helped build and integrate through my firm, Applied Quantum, calibration failures are the most common source of downtime. A signal-chain problem traced to a bill of materials that carried attenuation values from an earlier design revision can render a flawlessly installed wiring tree useless. Control electronics procurement can stall an entire program if the allocation of the radio-frequency chips that drive the qubits slips behind larger telecom or defense orders. Reference-clock distribution errors between multi-chassis control setups produce phase errors that look like qubit crosstalk to the calibration team, burning weeks of diagnostic effort.

Every step in the integration chain (mounting, wire-bonding, thermalized cabling, cooldown, calibration) requires hands-on access by trained personnel. The Q-PAC quantum computer installation at Elevate Quantum in Colorado, one of the fastest documented Western builds, required five months of hands-on integration work by an experienced team. The process included mounting the processor in a mu-metal magnetic shield at the mixing chamber stage, wire-bonding it to the sample holder, connecting it through carefully thermalized cabling at five temperature stages with specific attenuation at each stage, verifying continuity and attenuation at room temperature, cooling the system, and only then beginning the calibration process.

Every one of these steps assumes physical access by trained personnel. In orbit, you have none of it.

Radiation destroys qubits

Cosmic rays are a nuisance for classical GPUs in orbit. Google’s Suncatcher paper tested their TPUs in proton beams and found the bit-flip rate “likely acceptable for inference,” though they explicitly noted that the effect on training “requires further studying.” GPUs can tolerate some bit flips through error correction and redundancy. Hewlett Packard Enterprise configured its edge computers on the International Space Station to run three instances of every calculation on three separate nodes, tripling power draw and mass to detect corrupted processors.

Superconducting qubits cannot tolerate this approach. A single cosmic ray impact on a superconducting processor creates a shower of phonons that breaks Cooper pairs across the chip, generating quasiparticles that destroy coherence across multiple qubits simultaneously. The result is a correlated error event across multiple qubits that can crash an entire quantum error correction cycle. McEwen et al. at Google demonstrated this experimentally in 2022, showing that cosmic ray impacts produced catastrophic correlated error bursts across Google’s Sycamore processor, errors that overwhelmed error-correction assumptions by violating the locality that surface codes depend on. Vepsäläinen et al. at MIT showed independently that ionizing radiation contributes to elevated quasiparticle density and that underground shielding measurably improved qubit relaxation times. This is one of the most active areas of quantum hardware research, conducted on Earth, in shielded laboratories, with the luxury of iterative experimental design.

In low Earth orbit, the radiation environment is orders of magnitude worse than on the ground. The South Atlantic Anomaly alone, the region where Earth’s inner radiation belt dips closest to the surface, exposes satellites to trapped proton fluxes that would dominate the error budget of any superconducting processor. Shielding does not solve this. The mass required to protect a dilution refrigerator’s mixing chamber to the levels needed for qubit operation would consume the payload capacity of the launch vehicle.

Quantum AI itself is unproven

Orbital cryogenics, calibration, and radiation shielding are all unsolved. Even if they were solved, the pitch would still founder on a third problem: quantum advantage for mainstream AI and machine learning workloads has not been demonstrated.

The genuine results are narrow. The most cited positive result, Huang et al. in Science (2022), proved that quantum machines can learn from exponentially fewer experiments than classical machines when the task is to learn about a quantum system from experimental data. That is an advantage for quantum physics research; it says nothing about training large language models on text corpora.

Google Quantum AI, despite its name, has migrated its research focus from machine learning to quantum error correction and physics simulation. Its Willow chip, announced December 2024 with a companion paper in Nature, is a below-threshold error-correction milestone, a result I analyzed in detail on this site. It is not an AI product. Hartmut Neven, who founded Google Quantum AI in 2012, frames the AI connection aspirationally, but the near-term deliverable is below-threshold operation, and quantum-enhanced neural network training remains aspirational.

The community of researchers working on quantum machine learning has been admirably honest about this gap. Practical quantum advantage on real-world data (customer records, sensor streams, natural language text) remains a research aspiration without demonstrated engineering capability. Many of the “provable advantage” results in the literature use artificial tasks, constructed specifically to showcase quantum speedups, that do not map to commercial AI workloads.

I have written extensively about Quantum AI on this site. I believe the convergence of quantum computing and AI will eventually produce results that matter. I do not believe it will produce them in orbit.

The “quantum data center” that makes sense, and the one that does not

There is a version of “quantum data center” that is real and reasonable. BDx Data Centers in Singapore signed an agreement in July 2025 with Anyon Technologies to deploy a hybrid quantum-classical testbed at its Paya Lebar facility, a quantum processor co-located with GPUs and CPUs in a conventional data center. PsiQuantum is building utility-scale Quantum Compute Centers in Brisbane and Chicago, where the machine itself is building-scale infrastructure. These are data centers that host quantum computers alongside classical infrastructure, and the label “quantum data center” is a minor marketing stretch for a real engineering concept.

There is another version that is not real: the pure quantum data center, a facility that houses only quantum processors with no classical computing infrastructure. I know of at least two startups that have raised money on this concept. It ignores the fundamental architecture of quantum computation, where every quantum processor requires a substantial classical computing stack for control, error correction, and post-processing. A quantum computer without its classical support infrastructure is like an engine without a vehicle: technically interesting, practically useless.

Stacking impossibilities

None of the three challenges I have described violates the laws of physics in the way that perpetual motion does. A sufficiently motivated civilization with unlimited resources and no time constraints could, in principle, solve each one. An investor faces a different test: whether these problems can be solved simultaneously, at commercial scale, on a venture-capital timeline, by a startup that has launched one GPU on one satellite. The gap between the current state of engineering and the claimed capability is so vast that funding the buildout, as opposed to the research, is indistinguishable from burning capital.

Each layer has its own cost penalty, and the three multiply.

Classical orbital data centers, using the most generous published models, cost 3x to an order of magnitude more than terrestrial equivalents. Those models, as I have shown, omit the thermal plumbing, coolant inventory, attitude control, debris avoidance, deorbiting, and hardware refresh costs. These are order-of-magnitude placeholders. My rough model above gives 10x to 47x before the two costs it leaves out. Call the classical penalty one to two orders of magnitude.

Superconducting quantum computers add a second penalty. A dilution refrigerator weighs 750–7,000 kg, requires helium-3 from a supply chain controlled by nuclear weapons programs, demands vibration isolation that contradicts the dynamics of a satellite in orbit, and needs calibration by personnel who cannot reach the hardware. No one has published a cost model for millikelvin cryogenic operation in LEO because no one has attempted it. The shielding mass alone (sufficient to reduce the proton flux at the mixing chamber to levels where quasiparticle poisoning does not dominate the error budget) would consume a substantial fraction of a Starship payload for a single processor. For a data center of hundreds of processors, the shielding mass alone approaches the total mass budget of the facility. Call this an additional order-of-magnitude penalty as a placeholder.

Quantum AI adds a third penalty: no one has demonstrated quantum advantage for commercial AI workloads, so the capability the pitch sells does not yet exist. The leading research groups have shifted their focus to quantum error correction, which is a prerequisite for any future quantum AI capability. Fault-tolerant applications may require very large numbers of physical qubits, potentially millions for demanding algorithms, far beyond the largest processors operating today. The first quantum computer in space launched in June 2025: a photonic processor from the University of Vienna, operating as a physics experiment for satellite edge computing, with no AI data center capability. (This is a different category from quantum communication satellites like China’s Micius, which distribute entangled photons as a communications channel. They do not perform computation.)

Compound the penalties: one to two orders of magnitude for orbital compute, another order of magnitude for cryogenic quantum hardware in orbit, multiplied by a workload that does not yet exist. The product measures the distance between the pitch and the physics, and it does not belong in a financial model.

The pitch I was asked to evaluate proposed to close that distance on a venture-capital timeline. That is not an engineering program. It is a bet that someone will rewrite the economics of space launch, solve millikelvin cryogenics in microgravity, demonstrate quantum AI advantage on commercial workloads, and integrate all three, before the fund’s limited partners want their money back.

The hype-funding feedback loop

Q-FUD, the quantum panic industry, works by exaggerating threats to sell products. The orbital quantum AI pitch works by the inverse mechanism: exaggerating capabilities to attract capital. Q-FUD vendors and orbital AI startups both profit from the same audience weakness, the distance between what buyers and investors know about quantum computing and what the physics actually permits.

In the late 1990s, adding “.com” to a company name could double its stock price. In 2017, adding “blockchain” worked the same way. In 2026, the formula is “AI + space” or, if you want the full set, “quantum + AI + space.” Each buzzword adds a multiplier to the pitch deck valuation. None of them adds a watt of cooling capacity or a millikelvin of cryogenic temperature.

Starcloud’s $2.3 billion valuation was assigned to a company that has launched one satellite carrying one GPU that could not run at full power. To build its own 5 GW concept, by the rough model above, Starcloud would need $0.8 to $3.7 trillion. The company has raised $450 million, roughly 0.01 to 0.06 percent of what its white paper proposes to build. Global AI venture funding in Q1 2026 reached roughly $300 billion, with AI capturing approximately 80 percent of all venture capital. A measurable share of that $300 billion is funding pitch decks.

What I told the investor

I told him five things.

First, small in-orbit compute for satellite workloads is real and useful: preprocessing Earth-observation data before downlink, running collision-avoidance calculations onboard instead of on the ground. Cavalier’s IEEE Spectrum analysis endorses exactly these niches, and so do I. Hyperscale orbital data centers competing with terrestrial ones are a different proposition, and no credible analysis puts them on a timeline. Every proponent talks about launch cost because it is the one variable that is visibly falling. But the constraints that matter are thermal, maintenance, debris, resonance, and deorbit, and a lower launch price changes none of them. Cheaper launch only puts the same unsolved problems in orbit sooner. If someone asks me for a date, my answer is a few decades at the earliest and possibly not in our lifetimes. I would not rule out never.

Second, quantum AI data centers in space combine three unsolved problems (orbital compute, quantum hardware in orbit, and quantum AI advantage) in a way that multiplies the risk rather than distributing it.

Third, the only superconducting quantum computer that can operate without physical access by trained personnel does not exist. Building one is a prerequisite for putting quantum compute in orbit, and it is a problem that the entire quantum computing industry is years away from solving on the ground.

Fourth, if he wants exposure to quantum computing, the opportunities are terrestrial and they are real. The post-quantum cryptography (PQC) migration market, preparing classical infrastructure for the quantum threat, is a $30+ billion program with regulatory deadlines that are already set. Hybrid quantum-classical data centers are being built. Photonic quantum computers (PsiQuantum) are designed from the ground up for data-center-scale deployment. These are investable. Orbital quantum AI is not.

Fifth, the only thing missing from his hypothetical was blockchain.

Where this is actually heading

Dismissing quantum computing as a pipe dream is the quantum denialism position, and it is as wrong as the hype it opposes. I am not saying data centers will never operate in orbit; the second-order effects of industrializing orbital infrastructure could be enormous, as McCalip himself argues. And I am not saying quantum AI will never produce results; the theoretical case for quantum speedups in certain optimization and simulation tasks is genuine.

But timing separates engineering programs from capital destruction. The engineering challenges for a cryptographically relevant quantum computer on Earth are immense, and I am confident they will be resolved in the next 5–10 years. But stacking the unsolved problems of quantum AI and of orbital data centers on top of those moves the timeline from “challenging but plausible” to “multiple decades, if ever.”

The investor’s job is to distinguish between “this technology will eventually work” and “this technology will work on a timeline that generates returns for my fund.” For quantum AI data centers in space, the answer to the first question might be yes. The answer to the second question is no.

I will publish a separate analysis of the funding model that rewards buzzword density over technical feasibility. The immediate conclusion is narrower: when a pitch deck combines three frontier technologies, each individually unproven for the claimed application, into a single business plan, the correct response is not due diligence. It is physics.

From the author