Orbital Compute: Four Chips, Fifteen Minutes, and an Honest Price Tag
At 11:18 a.m. Pacific on 1 October 2026, a SpaceX Falcon 9 was scheduled to lift off from Vandenberg Space Force Base carrying 130 separate payloads bound for a shared sun-synchronous orbit, with a backup window the following day. One of those payloads is the size of a filing cabinet and, if Google's own published case for computing in space holds up, matters more than the other 129 combined.
It is called MVP, and it is the first hardware from Google's Project Suncatcher programme: four Trillium-generation Tensor Processing Units, built with the Earth-imaging company Planet, drawing roughly one kilowatt from onboard solar arrays. Google's senior director for the programme, Travis Beals, has told the New York Times the chips can compute for about fifteen minutes before a mandatory thermal shutdown. That figure does not appear in either of Google's own primary documents on the project, its blog post or its technical paper on arXiv. It traces to one interview, repeated across outlets that all cite the same conversation rather than independently confirming the number.
That gap, between what Google tests and what Google says, is the actual story this week. Not whether four chips can survive a rocket launch. Whether the survival test tells you anything about the much bigger claim sitting behind it.
Project Suncatcher is Google's research programme on whether data-centre-class AI accelerators can run usefully in orbit. MVP is explicitly not a data centre. Google's own blog post calls it "an experimental precursor" designed to validate specific subsystem and operational assumptions: can the chips survive launch vibration, can they tolerate the radiation environment of low Earth orbit, can the thermal system keep them within operating range long enough to do anything useful at all.
The choice of Planet as the build partner is itself a small signal worth reading correctly. Planet is an Earth-imaging company with its own long record of putting small satellites into orbit reliably and often; it is not a chip company and it is not a launch company. Google supplied the compute payload, Planet supplied the satellite bus and the operational experience of actually getting something built and flying, and SpaceX supplied the ride. That division of labour is the same vertical-integration pattern this series has tracked in Google's own case study since Space Mafia's original chapter on Suncatcher: one company increasingly setting the terms for chip design, satellite partnership, launch arrangement and long-term compute vision, with each partner supplying a piece but nobody outside Google positioned to check the whole picture against itself.
On two of those three questions, Google's own technical paper is unusually candid and unusually well documented. The radiation testing is the strongest primary material in the entire package. Conducted at the University of California, Davis's Crocker Nuclear Laboratory using a 76-inch cyclotron producing a 67 MeV proton beam, it found that high-bandwidth memory components began showing irregularities at a cumulative dose of 2 kilorad, almost three times the mission's minimum survival requirement of 750 rad. Every other system on the board functioned correctly up to the maximum tested dose of 15 kilorad. The paper estimates a shielded dose rate of roughly 150 rad per year in the target sun-synchronous orbit, around 750 rad over a five-year mission, and a silent data corruption rate of about one failure per three million inferences under expected conditions. That is engineering you can check: named facility, named beam energy, exact numbers.
The third question, sustained thermal performance, is the one Google's own documents do not answer. No radiator area, no mass figure, no duty-cycle number for MVP's own hardware appears anywhere in the blog post or the paper. The fifteen-minute figure comes from a single interview, not from the engineering record. Google's blog post names cooling as a central research challenge and describes heat pipes, radiators and thermal-vacuum-chamber testing, without ever putting a number against any of it.
The nearest thing to an independent thermal estimate comes from outside Google entirely. Andrew Cavalier of ABI Research, writing in IEEE Spectrum, calculated that a single 700-watt chip at 60 degrees Celsius needs roughly 1.4 square metres of radiator surface, rising by about 40 per cent over a five-year mission to nearly 2.0 square metres as the coating degrades under ultraviolet light and atomic oxygen exposure. Scaled to a 32-chip, 40-kilowatt server rack, that works out to roughly 80 square metres of radiator, about the size of a pickleball court. Cavalier's worked example uses a different company's chip, Nvidia's H100, not Google's TPU, and it is not a measurement of Suncatcher's own hardware. It matters precisely because it is independent: it is the only quantified answer anywhere in this week's material to the question Google's own documents leave open.
The number everyone is repeating, and the one Google actually wrote down
Behind the engineering test sits a much larger claim. Google's own paper lays out a long-term vision: an 81-satellite cluster arranged in a one-kilometre radius, which the paper argues could become economically comparable to a terrestrial data centre on a per-kilowatt basis, but only if the cost of reaching low Earth orbit falls to around $200 per kilogram or below by the mid-2030s.
A figure of roughly $7,000 per kilogram has been circulating this week as the current cost against which that target should be measured. Google's own paper does not use that number. It states its baseline plainly: "current launch price $3,600/kg, based on Falcon 9 (reusable configuration), since that is used for the Starlink constellation." Independent market pricing found this week clusters between roughly $3,000 and $3,245 per kilogram for a dedicated reusable Falcon 9 at full capacity, and around $6,000 per kilogram for a small rideshare slot like the one MVP flew on. None of those figures is $7,000, and none of several sources checked traces that number to a specific document.
The correction does not change the underlying point, which is that the clock has not moved. Whether you use Google's own $3,600 baseline, the lower end of the independent range at roughly $3,000, or the rideshare rate of $6,000, every one of them sits a long way from the $200 target: by Google's own figure, a gap of roughly eighteen times. A fifteen-minute compute burst, if it happens exactly as planned, proves the hardware can survive the trip. It says nothing about whether the trip will ever get cheap enough for the vision built on top of it to make sense.
This is the shape the series keeps finding in different forms. Three weeks ago this column read two FCC filings proposing more than 151,000 satellites against the complete absence of a published, measured on-orbit compute benchmark from either filer, and concluded that the industry's biggest scale claims exist as regulatory paperwork rather than flight data. This week the gap has moved down a level, from "has anyone flown anything" to "does what has flown, or is about to, actually support the scale being claimed for it." The series' own Three Clocks framework names this precisely: the Orbital clock is the one that moves when hardware gets built and tested, and it is moving. The Industry clock, the one tied to launch economics, is the one that determines whether any of it pays for itself, and on Google's own numbers, it has not moved at all this year.
None of this makes MVP a bad test. A four-chip prototype that validates radiation tolerance and launch survival is a legitimate, modest, well-documented step. The problem is not the test. It is the distance between what the test proves and what gets claimed on top of it, a distance Google's own paper is honest enough to state and vague press coverage keeps erasing.
The one concrete next step Google has actually committed to is smaller and nearer: a planned 2027 test linking two satellites by optical communication, a step toward proving the constellation can talk to itself before anyone commits to building 81 of them. That is the honest shape of a research programme: test survival first, test coordination between two satellites second, and only consider the economics of a much larger cluster once both of those earlier steps have produced real data rather than a projection. The 81-satellite cluster is a stated long-term vision, not a scheduled plan, and nothing in this week's material moves it from one category to the other. A reader who comes away from Suncatcher's launch week believing the full constellation is now in motion has read the coverage, not the paper.
What New Zealand's own launch cadence keeps saying about this
New Zealand supplies this story's structural counter-evidence again this week, the same role it has played across recent instalments of this series. Rocket Lab flew its 97th Electron mission from Māhia on 26 September, delivering the thirteenth StriX satellite for the Japanese company Synspective into a 559-kilometre orbit. It was Rocket Lab's eighteenth mission of 2026 company-wide. As with every other 2026 Māhia launch this column has tracked, the payload was synthetic-aperture-radar imaging, not orbital compute.
New Zealand is the launch site for a sector whose defining hardware, orbital AI compute, has not yet flown from it. That is not a criticism of Rocket Lab, whose cadence is genuinely the highest of any Western small-satellite launch site. It is a reminder that hosting the rockets and hosting the workload are two separate capabilities, and New Zealand currently has the first without the second. The Ground-Based Space Infrastructure regime, the licensing framework created under the Outer Space and High-altitude Activities Amendment Act 2025, continues to govern ground-segment authorisation in New Zealand; nothing in this week's findings changes how that regime applies, and it appears here only as background, not as commentary on whether it is working well.
For a New Zealand organisation weighing whether to build on, buy into, or simply watch the orbital compute sector, the distinction this article keeps drawing matters practically. A launch contract, a ground station lease, or a satellite-hosting arrangement is a different commitment from a claim about what the payload will eventually do once enough of it is in orbit. The first is something a lawyer and an engineer can scope and price today. The second is a bet on an industry-wide cost curve that, on the clearest primary evidence available this week, has not yet started moving in the direction it needs to.
Reading a vendor's own numbers instead of the coverage of them
The practical lesson for anyone evaluating a vendor's capability claim, in orbit or anywhere else, is to go to the primary document before the press release about it. Google's own paper is, in this instance, the strongest check on its own headline: it states the $200 target openly, states its own current baseline openly, and simply does not supply a thermal figure for its own hardware. That absence is reported here as an absence, not as evidence of concealment. The same documents are unusually detailed everywhere else; a company that publishes exact radiation-dose figures from a named cyclotron facility is not a company trying to hide its testing regime.
The discipline is simple and repeatable. Separate what a company has tested from what a company claims. Check whether the number attached to the claim appears in the company's own primary document or only in a single interview that every outlet then repeats. Treat a successful engineering milestone as proof of that milestone, not as proof of the economic case stacked on top of it. A board asked to evaluate a vendor's orbital, AI or cloud capability claim can apply the same three steps before the next slide deck does the work for them, and the questions do not need to be hostile to be useful. Asking a vendor to point to the specific page of its own technical documentation that supports a headline number is a request most credible vendors can answer in minutes; a request that produces only a press release or a repeated interview quote is itself the answer.
The same read-the-source discipline has an open-source answer worth naming directly, because the alternative to trusting a vendor's own account is often a shared, inspectable one. NASA's Core Flight System, released as open source by Goddard Space Flight Center in January 2015 under the Apache 2.0 licence and flown on more than twenty missions since, is flight software any satellite builder, government or commercial, can read, modify and verify rather than take on faith. It will not settle Suncatcher's thermal question, which sits in hardware, not software, but it is the standing counter-example to a single company's black box: software whose behaviour does not depend on trusting one vendor's word for what it does. As orbital compute moves from paper filings to actual hardware, which standards govern the software layer underneath it becomes exactly the kind of question worth asking before the next headline number.
That same question about who gets to verify a claim, rather than simply repeat it, does not stop at software. It is the launch-site jurisdiction itself that frames the next step, because MVP's own test only happens because a particular government installation hosts it. MVP launches from Vandenberg Space Force Base, a United States Space Force installation, aboard a commercial SpaceX rideshare carrying unrelated payloads from more than a hundred other customers. That is a factual description of where the mission flies from and under whose range-safety arrangements, not a claim about strategic partnership or defence significance; commercial rideshare missions have flown from military-operated spaceports for years, and this one is unremarkable in that respect. New Zealand's own Ground-Based Space Infrastructure regime remains relevant only as background at its own regulatory layer, ground-segment authorisation rather than orbital-slot allocation, and nothing here compares the adequacy of one jurisdiction's framework against another's.
A four-chip prototype surviving fifteen minutes in orbit, if it happens on schedule, is a real engineering result and a genuinely interesting one. It is not, on Google's own account, evidence that the economics behind an 81-satellite vision have moved an inch. Testing what a company has shown you against what it has only said is the discipline this whole story turns on.
The next time a vendor, in orbit, in enterprise AI or anywhere else, puts a survivability demonstration next to a decade-out infrastructure claim, which number in the room has actually been tested, and which one has only been said out loud? What would you ask to see before you believed either of them?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Space Mafia examines the sovereignty implications of orbital compute infrastructure.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] Google. "Project Suncatcher: Key Facts." Google Research Blog, 2026. https://blog.google/innovation-and-ai/models-and-research/google-research/google-project-suncatcher-facts/
[2] SpaceX. "Transporter-18 Mission." SpaceX, 2026. https://www.spacex.com/launches/transporter18
[3] Google Research. Project Suncatcher technical report. arXiv preprint 2511.19468, 2026. https://arxiv.org/html/2511.19468v2
[4] SpaceWatch.Global. "Star Catcher, Google and Blackwing Space Bring New Orbital Technologies to Transporter-18." SpaceWatch.Global, September 2026. https://spacewatch.global/2026/09/star-catcher-google-and-blackwing-space-bring-new-orbital-technologies-to-transporter-18
[5] Progressive Robot. "Project Suncatcher: Google First Test AI Chips in Space." progressiverobot.com, 24 September 2026. https://www.progressiverobot.com/2026/09/24/project-suncatcher-google-first-test-ai-chips-in-space/
[6] Cavalier, Andrew (ABI Research). "Orbital Data Centers Heat." IEEE Spectrum, 11 June 2026. https://spectrum.ieee.org/orbital-data-centers-heat
[7] Rocket Lab. "Mission Success: Rocket Lab Launches 97th Electron Mission." GlobeNewswire, 26 September 2026. https://www.globenewswire.com/news-release/2026/09/26/3369387/0/en/mission-success-rocket-lab-launches-97th-electron-mission.html
[8] NASA Goddard Space Flight Center. "Core Flight System." NASA Engineering and Technology Directorate, accessed 1 October 2026. https://etd.gsfc.nasa.gov/capabilities/core-flight-system/news/