Google is scheduled to send its first Project Suncatcher AI hardware into orbit today, October 1, aboard SpaceX’s Transporter-18 rideshare mission. The launch window opens at 11:18 a.m. PT from Vandenberg Space Force Base. Google’s immediate question is practical: can its TPUs survive a rocket launch, radiation, vacuum, and the much harder problem of dumping heat when there is no air to carry it away?
On the same flight, Indian startup TakeMe2Space is launching a smaller system with a clearer near-term job. Its MOI-1A satellite will use Nvidia Orin NX processors to run customer AI models against data in orbit, sending analysis back to Earth instead of the full underlying dataset.
Those projects represent two versions of orbital AI. One asks whether something resembling an AI data center can move into orbit. The other puts compute next to data that is already generated there.
The second version already has a strong reason to exist. The first still has a long engineering bill attached.
Key takeaways
The strongest near-term workload for orbital AI is processing data generated in space. Earth-observation satellites can filter clouds, compress images, detect fires or other events, and send down results instead of mountains of raw data.
Spacecraft autonomy is another natural fit. Navigation, targeting, fault detection, and other decisions can happen locally instead of waiting for Earth.
General-purpose AI inference for people on Earth has a much weaker case. The inputs start on Earth, the users are on Earth, and sending everything through orbit adds networking complexity.
Large AI training jobs are particularly difficult. Modern training clusters depend on extremely fast communication between accelerators. Google’s own research says orbital links would need to improve dramatically.
Abundant sunlight solves only one part of the data-center problem. Heat rejection, radiation, launch mass, reliability, replacement, networking, and maintenance all come along for the ride.
Google Project Suncatcher is testing hardware, not a real data center
Project Suncatcher becomes more useful to think about once the “data center in space” label is set aside.
Google’s immediate mission is an engineering test. The prototype is designed to measure how TPUs handle launch stress, radiation, and thermal extremes in orbit. Google is also testing cooling hardware built around heat pipes and radiators. Future designs could carry dozens of TPUs per satellite and connect multiple satellites with high-bandwidth laser links.
That is valuable work even if a giant orbital AI cluster never becomes economical.
Spacecraft have traditionally used conservative computing hardware for a reason. Electronics must survive radiation, tight power budgets, temperature swings, and an environment where replacing a failed component is nothing like swapping a server in a rack. A technician cannot walk down an aisle, pull a bad accelerator, and install another one before lunch.
Google has already pushed its Trillium TPUs through proton-beam radiation testing. The company’s researchers found that the chips survived a total ionizing dose equivalent to a five-year mission without permanent failures, while still showing radiation-induced error modes that need mitigation.
That makes this first flight less glamorous than the data-center pitch and more useful. Put modern AI hardware into the actual environment, run it, and find out which assumptions break.
More on custom AI silicon:
The best reason to compute in space is that the data starts there
A simple rule cuts through most orbital-computing pitches: if enormous amounts of data originate in space and only a small result needs to reach Earth, process the data in space.
Earth observation is close to the ideal case.
A satellite camera can collect more imagery than operators want to transmit during limited ground-station contacts. Some of those images may be useless before anyone on Earth sees them. Optical sensors can capture clouds instead of the ground. Other instruments may spend long stretches observing nothing unusual.
Sending every raw image to Earth pays the communications cost first and asks whether the data was useful later.
Onboard AI can reverse that order.
The European Space Agency’s Φsat-2 already shows how. Its onboard apps can detect cloud-covered images, compress imagery, generate street maps, and identify or classify targets before data is sent to Earth. Cloud filtering is especially easy to understand. If a picture contains nothing but cloud cover, the satellite can avoid spending scarce downlink capacity on an image nobody needs.
NASA has tested a related idea with Dynamic Targeting. In a flight test, an Earth-observation satellite analyzed imagery onboard and decided where to point an instrument in less than 90 seconds without human involvement. That changes the satellite from a camera with a radio link into a system that can decide what is worth observing next.
TakeMe2Space is trying to sell the same basic advantage as a service. Customers upload AI models, the satellite runs them against data during a pass, and the system returns analysis instead of the full raw dataset. The value proposition is not mysterious. Downlink is limited and costs money. Local compute can reduce how much data has to cross that bottleneck.
This is orbital AI without an orbital hyperscale data center.
The satellite becomes an edge-computing device. The data source, processor, and first decision all sit on the same machine.
That is a much easier proposition to defend.
Spacecraft autonomy is the other obvious workload
The next strong use case is the spacecraft itself.
Satellites and deep-space probes routinely face situations where asking a terrestrial server what to do is slow, expensive, unavailable, or some combination of all three. Communication delays become more severe as a mission travels farther from Earth, but even in low-Earth orbit, constant dependence on ground control limits how quickly a spacecraft can react.
NASA explicitly includes advanced autonomy, AI and machine learning, image and signal processing, data-flow management, object detection, and classification among the workloads driving its next generation of high-performance spaceflight computing.
The logic is the same as onboard Earth-observation inference. The information needed to make the decision already exists on the spacecraft.
A navigation camera should not need to beam every frame to Earth, wait for a remote server to recognize what it sees, and then wait again for steering instructions to come back. Fault detection has the same property. So do observation planning, robotic control, targeting, and some collision-response tasks.
Compute belongs near the sensor when the response is local and time-sensitive.
There is also a reliability benefit. A spacecraft that can keep operating when its ground link is interrupted has fewer reasons to turn a communications problem into an operational failure.
That is edge computing in the most literal possible sense.
AI data centers in space get harder when the data starts on Earth
Now reverse the traffic.
Suppose the goal is ordinary Gemini inference for users on Earth.
The prompt starts on Earth. It has to reach the satellite. The satellite performs inference. The answer then has to return to Earth. Any supporting data, context, retrieval results, tool calls, or database traffic may also need to cross the same path.
The compute has been moved away from the user and away from most of the data feeding it.
Low-Earth orbit is close enough for useful communications, but an orbital computer still depends on ground stations, satellite relays, or both. A terrestrial data center plugged into dense fiber infrastructure starts with a large home-field advantage.
Interactive applications are especially unforgiving. Chatbots, coding agents, voice systems, cloud desktops, gaming, transactional databases, and many enterprise applications care about consistent latency and continuous network availability. A workload that constantly talks to Earth gives up much of the advantage that made onboard satellite processing compelling in the first place.
The U.S. Government Accountability Office reached a similar practical split in its 2026 review of space data centers. It found that smaller systems processing data generated in space may be closer to maturity than large orbital facilities built to train AI models.
That is a useful way to think about the next several years.
Orbital compute already has jobs. Orbital AWS still needs to justify the commute.
Large AI training runs into a much worse networking problem
Power gets most of the attention in AI data centers in space. Networking may be the nastier constraint.
A modern AI accelerator rarely works alone during a large training run. Hundreds or thousands of chips exchange intermediate data continuously. The network stops being supporting infrastructure and becomes part of the computer.
Google’s Project Suncatcher paper is unusually clear about the gap. Commercial optical inter-satellite links generally operate at roughly 1 to 100 Gbps, while the orbital ML system Google studies could require aggregate bandwidth on the order of 10 Tbps per link. The researchers demonstrated 800 Gbps in one direction over a short free-space path on a bench.
That is promising lab work. It is not the same thing as operating a tightly synchronized cluster in orbit.
Google’s proposed answer is to bring the satellites much closer together than ordinary communications satellites. One illustrative design uses 81 satellites inside a cluster with a 1-kilometer radius, with nearby spacecraft separated by roughly 100 to 200 meters at points in the orbit.
Now the data center is also a precision formation-flying system.
The networking problem resembles the one in terrestrial distributed AI. As Popular AI’s guide to local AI clusters explains, distributing independent inference jobs across multiple machines is comparatively easy. Splitting one tightly coupled model or training job across machines puts far more pressure on the network because accelerators need to exchange intermediate results repeatedly.
In orbit, the same constraint remains. The cables become optical links and every server rides on a spacecraft moving around Earth.
For independent batch jobs, that may be manageable. For a training run that expects thousands of accelerators to behave like one tightly coupled machine, every weak link becomes part of the critical path.
More on distributed AI networking:
Cooling is the orbital data-center problem people get backward
“Space is cold” sounds like excellent news for a data center until heat transfer enters the conversation.
A server on Earth can dump heat into air or liquid, move that heat through pipes or cooling loops, and reject it somewhere else. A spacecraft sits in a near-vacuum. There is effectively no surrounding air available for convection.
The heat still has to leave.
In orbit, that means moving waste heat away from the chips and eventually radiating it into space. Larger computing loads require larger thermal systems. Google is testing heat pipes and radiators because the accelerator cannot simply sit in the cold and cool itself.
This gets expensive in mass and surface area. Radiators have to exist physically. They must survive launch. They cannot block solar arrays or interfere with the rest of the spacecraft. A denser compute payload creates more heat in the same place, which makes heat transport harder before the energy even reaches a radiator.
The GAO identifies the same scaling problem. Large orbital data centers would need large power systems and cooling hardware, while cooling at that scale remains unproven.
There is no free cosmic air conditioner.
Every watt that reaches the processors eventually becomes heat that the spacecraft has to get rid of.
More on AI power and cooling:
Solar power is a real advantage, but it does not erase the rest
Orbit does offer something terrestrial data centers cannot copy directly.
In a suitable orbit, Google estimates that a solar panel can receive up to eight times as much energy over a year as an equivalent panel at mid-latitudes on Earth. A dawn-dusk sun-synchronous orbit can also provide near-continuous sunlight.
That creates a genuinely interesting long-term equation.
Instead of collecting solar power in space and trying to transmit electricity to Earth, put an energy-hungry computation workload next to the solar panels and transmit the resulting information. Information is easier to move than gigawatts of electricity.
The idea gets more attractive when the output is much smaller than the input. A model might process terabytes of locally stored or locally generated data and return megabytes of useful results. Scientific analysis of orbital sensor data fits that pattern. So does some batch inference.
Uploading terabytes from Earth, processing them in orbit, and downloading terabytes back again does not.
The power source cannot be judged separately from networking, cooling, launch mass, radiation tolerance, and replacement. Cheap energy is useful only if the rest of the machine can use it at a competitive total cost.
Maintenance is brutally different in orbit
A terrestrial data center assumes hardware will fail.
Drives die. Power supplies fail. Memory throws errors. Networking equipment breaks. Accelerators get replaced by faster ones. Operators design around failure, but they also have the luxury of sending people into the building.
Orbital infrastructure needs another answer.
Google’s research identifies on-orbit reliability and repair as unresolved problems. The paper points out that failed TPUs can be replaced manually on Earth, while that approach is obviously impractical for a satellite cluster.
Radiation adds another failure mode. Launch adds another cost to every replacement. A failed accelerator cannot simply be returned under warranty and swapped during the next maintenance window.
That favors architectures that degrade gracefully.
A constellation of independent inference nodes can lose capacity without losing the whole service. A tightly synchronized machine has less room for casual failure because each missing node or broken link can interfere with work happening elsewhere.
Redundancy helps, but redundant hardware also has mass. Mass has to be launched. Every orbital reliability solution eventually finds its way back to the launch manifest.
Smaller edge-computing systems again have the friendlier problem because they can perform useful work without pretending hundreds of satellites are one computer.
What is actually worth running in orbit?
For the foreseeable future, the strongest orbital AI workloads fall into three broad groups.
First is space-generated sensor data. Satellites can filter imagery, compress it, detect interesting events, classify objects, extract features, combine observations, and decide what deserves limited downlink bandwidth. The communication savings are immediate because the raw data never needs to leave the spacecraft unless it is useful.
Second is spacecraft operation. Navigation, targeting, fault detection, planning, robotic control, collision avoidance, and other time-sensitive tasks benefit when the machine can act without asking Earth for every decision.
Third is asynchronous compute where inputs can be staged locally and outputs are comparatively small. Scientific analysis of orbital datasets could fit this model. Some batch AI inference may as well. The workload gets more attractive as its dependence on constant communication with Earth falls.
Large-model training sits much farther down the list.
So does ordinary consumer inference when the user, prompt, context, databases, and result all live on Earth. The best orbital workload is one that avoids moving large amounts of information across the Earth-space boundary in the first place.
More on large AI models:
What Google still has to prove
Project Suncatcher can move the argument forward because Google is testing physical assumptions in orbit instead of treating them as slide-deck details.
▪ Can high-performance AI silicon survive long enough under real radiation exposure?
▪ Can accelerators run at high utilization without thermal hardware becoming impractically large?
▪ Can optical links deliver data-center-class bandwidth between moving spacecraft, and can they do it reliably enough for tightly coupled ML jobs?
▪ Can dense satellite formations stay stable and safe while maintaining the distances needed for high-bandwidth links?
▪ Can operators tolerate failed hardware, route around it, and replace capacity at an acceptable cost?
And can launch economics improve enough that the solar-power advantage pays for everything space makes harder?
Google’s economic analysis explores a scenario in which launch prices to low Earth orbit fall below about $200 per kilogram by the mid-2030s. Under that assumption, the researchers estimate that launch cost amortized over a spacecraft’s life could become roughly comparable, on a per-kilowatt basis, to terrestrial data-center energy costs.
The estimate depends on that future launch-price assumption. It does not describe today’s economics.
The gap between those two statements contains the entire engineering problem.
Where AI data centers in space actually make sense
Google’s October 1 Project Suncatcher mission is worth watching, but the most convincing AI computer on the Transporter-18 flight may be the less spectacular one.
TakeMe2Space wants to process satellite data where that data is created. The processor sits near the sensor, cuts the amount of information that has to be transmitted, and returns a smaller result to Earth. The economic reason is visible immediately.
Google is testing whether much larger amounts of general machine-learning compute can eventually move into orbit too. That idea depends on high-bandwidth optical networking, reliable heat rejection, radiation-tolerant hardware, dense formation flying, graceful failure handling, and much cheaper launch.
The power advantage is real. So are the penalties.
A useful rule survives all of the engineering detail: compute in space when space is where the data, sensors, machines, or decisions already are. Keep the workload on Earth when the main reason to launch it is that the solar panels work better upstairs.
Related articles:
Explore more from Popular AI:
Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast