On 1 October 2026 a satellite the size of a refrigerator left Vandenberg on SpaceX’s Transporter-18 rideshare. Inside were four of Google’s Trillium TPUs, the same AI accelerators that fill its data centres on Earth, running on about a kilowatt of solar power. Google confirmed contact the same day. On 14 October a Chinese company launched eight more computing satellites built to test training AI models in orbit (Xinhua).
AI in space has stopped being a slide. It is hardware in orbit, with test plans and failure budgets.
The headlines are about data centres in the sky. The more useful story is closer in. Orbit is the purest edge there is: fixed power, a fixed thermal budget, no repair visit, a link that comes and goes, and radiation that quietly changes bits. Everything that makes space hard is a harsher version of what every remote site on Earth already faces.
What did Google launch on 1 October 2026?
Google launched the first prototype of Project Suncatcher, a test of whether its standard TPU chips can run AI workloads in orbit. As of 19 October 2026, Google has confirmed the satellite is operating as expected. We could find no in-orbit results published yet.
The facts, from the sources that reported them:
- Hardware. Four Trillium TPUs, “roughly one server’s worth of compute”, on a satellite built by Planet (Payload, Google).
- Power. About one kilowatt of continuous power, enough for a microwave or a hair dryer (TechCrunch, Ars Technica).
- Duty cycle. The TPUs run in bursts of about 15 minutes, then shut down so the radiators can catch up (Ars Technica).
- Purpose. In the weeks after launch, Google said, it will gather data on how the TPUs handle “the physical stress of spaceflight and the radiation and thermal extremes of space” (Google).
Suncatcher is not alone. In-orbit AI has been building for two years.
| Date | Mission | Compute | What it showed |
|---|---|---|---|
| 2025 | Space Llama, International Space Station | Quantised Llama 3.2 model | A language model can assist a crew in orbit (cited in the NAVI-Orbital paper) |
| Nov 2025 | Starcloud spacecraft | One NVIDIA H100 | A data centre GPU can serve a Google model from orbit (NPR) |
| 16 Apr 2026 | NAVI-Orbital, NASA JPL software on Loft Orbital’s YAM-9 satellite | Gemma 3 4B at 4-bit, on a satellite-class edge processor | A vision-language model can describe live Earth imagery entirely on board (arXiv) |
| 1 Oct 2026 | Project Suncatcher prototype | Four Trillium TPUs, about 1 kW | Under test: radiation, heat and launch stress on standard data centre chips (Google) |
| 14 Oct 2026 | ADAspace “star compute” group 02, eight satellites | High-performance computing payloads with liquid cooling loops at the 10,000 watt level | Under test: cooling, laser links and in-orbit training of foundation models (Xinhua) |
What is Project Suncatcher?
Project Suncatcher is Google’s research moonshot to find out whether fleets of solar-powered satellites carrying TPUs, linked by lasers, could one day work as a data centre in orbit. The bet is about energy. The Sun is the largest power source in the solar system, and panels in the right orbit see almost continuous sunlight.
The peer-reviewed design, published in Joule on 1 October, illustrates the idea with an 81-satellite cluster flying within a 1 kilometre radius. The satellites fly that close so the laser links between them are fast enough for the cluster to process in parallel.
The catch is launch. Google’s learning-curve analysis suggests launch to low Earth orbit may reach about US$200 per kilogram by the mid-2030s (Joule). On Google’s numbers, as TechCrunch reports them, getting there means Starship flying about 1,800 times over ten years, or 180 a year, carrying 200 tonnes each time. TechCrunch notes Starship has never flown more than five times in a year (TechCrunch).
Google is candid about this. Travis Beals, who leads the project, told NPR: “I don’t see this being something where it’s cheaper to do this in the next five years. I think it will take longer than that” (NPR).
Are data centres in space realistic?
Orbital data centres are a 2030s question. Orbital inference is a 2026 fact. Those are different businesses, and most commentary blurs them.
A data centre in orbit has to beat the ground on cost per unit of compute. That depends on launch prices, radiator mass and how many chips you can keep alive for five years with no technician. Beals told NPR the radiators are among the heaviest parts of the current satellite. Brandon Lucia of Carnegie Mellon University told NPR that maintenance in orbit has its “cost and complexity amplified by a factor of 10, maybe a factor of 100” (NPR).
Inference on a satellite does not need to beat the ground on cost. It needs to beat the downlink. That is a much easier race, and it is already being won.
Why run AI in orbit instead of on the ground?
Because the link to the ground is the scarcest resource a satellite has. A spacecraft collects data all the time but can only send it during short passes over a ground station. Most of what it collects is never looked at.
The NAVI-Orbital team at NASA’s Jet Propulsion Laboratory put a number on this. Their system classifies each image on board and writes a plain-English description. Each result takes 700 to 1,060 bytes. The live images it described were 9 to 14 megabytes each, so the summary is about four orders of magnitude smaller than the frame (arXiv). Operators read the summaries and ask for full images only when a scene matters.
That is the whole case for orbital inference in one sentence. Send meaning, not pixels.
The same logic applies at the dish. A ground station that triages data where it lands sends decisions to analysts, not raw passes. Either way, the model runs next to the data because the network cannot carry the data to the model.
How does radiation affect AI chips?
Radiation harms chips in two ways: slowly, through accumulated dose that degrades the device, and instantly, when a single particle flips a bit and silently changes a result. The first can kill a chip. The second can make it wrong without anyone noticing.
Google’s preprint gives the clearest public numbers yet for a modern AI accelerator (arXiv, June 2026):
- The target. A shielded satellite in sun-synchronous low Earth orbit takes about 150 rad(Si) a year, or about 750 rad(Si) over five years.
- Dose damage. The chip’s high bandwidth memory showed irregularities after 2 krad(Si). Compute and end-to-end machine learning tests kept working up to 15 krad(Si), the highest dose tested, with no hard failures.
- Silent errors. Core logic and on-chip memory showed silent data corruption during transformer workloads at about one event per 17 rad. Google translates that to roughly one per 3 million inferences, at one inference per second.
- Crashes. The host server saw a crash or reboot about once per 450 rad(Si) for the CPU and once per 400 rad(Si) for system memory.
Google has since re-run its beam tests. TechCrunch reports the first setup gave the chips more shielding than they would have in orbit, and the redo produced slightly more errors in logic. Beals put the inference error rate at “like one in a million” (TechCrunch).
One in a million sounds small. Do the arithmetic on the preprint’s figures. About 150 rad a year at one silent event per 17 rad is roughly nine silent errors a year for each device like the one Google tested. If each of a satellite’s four chips behaved the same way, that is about 35 a year. A constellation of a hundred such satellites would see thousands, each one an answer that looked fine. Add the CPU and memory crash figures together and a host reboots roughly once every year and a half at the same dose.
None of this is unique to space. Google’s own paper notes that silent data corruption “may occur in any operating environment” (arXiv). Orbit just turns the rate up until you cannot ignore it.
Radiation rarely crashes a model. It makes it quietly, confidently wrong.
Why is orbit the hardest edge?
Every constraint that makes AI hard at a remote site on Earth exists in orbit, with no fallback. On the ground you can send a technician, add a generator or run a cable. In orbit you get what you launched.
| Constraint | In orbit (sourced) | At a remote site on Earth | What it demands of the AI stack |
|---|---|---|---|
| Power | About 1 kW on the Suncatcher prototype | A generator, a solar array or a constrained feed | Serve within a power budget, not at peak |
| Heat | TPUs run about 15 minutes, then cool | Sealed enclosures, hot sheds, no chiller | Pause and resume work cleanly on a duty cycle |
| Repair | Cost and complexity “amplified by a factor of 10, maybe a factor of 100” | A technician is days or a flight away | Recover from resets without a person |
| Link | Contact only during ground station passes | Satellite, radio or cellular backhaul that drops | Decide locally, sync when the link returns |
| Silent errors | About one event per 17 rad in Google’s beam tests | Lower rates, but silent data corruption occurs anywhere | Detect a wrong answer, not just a crash |
| Change | NAVI-Orbital froze its software before flight, because any model change meant repeating the whole validation chain | Updates over thin links, often by hand | Ship model changes as small, signed, reversible packages |
Sources: Ars Technica, NPR, Google preprint and NAVI-Orbital.
The last row is the one most people miss. The NAVI-Orbital team wanted containers, but at integration time none gave reliable GPU access, so they flew a bare-metal environment. The paper says that “any subsequent model changes would have required repeating the entire validation chain”, so newer models were deferred from the flight build (arXiv). The model that launched was the model they were stuck with.
This is the same lesson we drew from 2026’s cloud outages in The cloud has a blast radius: what matters is whether the system keeps producing correct, accountable output when everything around it fails. Orbit is that test with no second chance.
Space is not a new place for AI. It is the edge with the excuses removed.
What does AI need to keep working between passes?
AI in orbit has to run a complete loop on its own: sense, infer, check and record, with the ground only visible for minutes at a time. The pass is for sending results down and taking approved changes up. Everything else happens alone.
Five design rules follow from the public record.
- Fit the model to the memory you launched. NAVI-Orbital ran a 4 billion parameter model at 4-bit precision, which needs at least 8 GB of GPU memory (arXiv). Memory, not compute, usually sets the ceiling. Our vLLM out-of-memory guide walks through the budget.
- Serve on a duty cycle. If the power and thermal budget allows 15 minutes of compute, the serving layer must checkpoint, pause and resume without losing work or corrupting state.
- Check answers, not just uptime. Silent corruption returns a plausible result. Catch it with error-correcting memory, repeated or cross-checked inference on high-stakes outputs, and validation gates on every result. NAVI-Orbital’s regex gate and retry loop is a simple example.
- Persist state so a reset is a pause. NAVI-Orbital writes its orchestration state to disk between steps so it can recover on its own, which its authors call “defensive engineering” (arXiv).
- Keep a record of what ran. For every result: which model and version, on what input, with what output and when. Operators need it to trust the summaries. Insurers and regulators need it after anything goes wrong. On a spacecraft it may be the only evidence there is.
What should operators ask before AI goes on the bus or at the dish?
Ask questions that can be answered by test, not by slide. These six work for a satellite, a ground station or any site on Earth that loses its link.
- What happens when the power budget runs out mid-inference? Does the job resume, restart or fail silently?
- How are silent errors detected? Ask for the mechanism and the measured rate on the target hardware, from public or independent tests.
- What survives a reset? After a reboot, does the system know what it was doing and what it already sent?
- How is a model changed after launch? How large is an update, how is it signed, and can it be rolled back without the ground?
- Where is the record of what ran, and who can read it? It should survive the loss of the link and be readable by the operator, not just the supplier.
- Has it run through a real outage? Cut the link and the power on purpose, on the ground, before orbit does it for you.
Where Sector88 fits
Sector88 is one system to deploy, run and govern AI at every site, connected or completely cut off. Models are tiered across VRAM and system RAM so larger models fit constrained machines. It keeps serving when the network is gone or untrusted, and it keeps a durable record of what ran. Our forward-deployed engineers take it from first benchmark to hardened production on real workloads. See how this applies from the spacecraft to the ground segment on our new space page.
The orbital data centre may take a decade. The orbital edge is open now, and it rewards whoever builds for the bad day.