Satlyt Orbital AI Software Took the Open Route SpaceX and Google Rejected

Satlyt orbital AI software is entering space after SpaceX and Google rejected founder Rama Afullo’s internal pitches for distributed computing in orbit. Satlyt has now raised an $8 million seed round and secured places for its software on multiple satellite missions.

The reversal became unusually visible when Satlyt’s software reached orbit through SpaceX, alongside hardware for Google’s Project Suncatcher. Both former employers now support orbital computing strategies, but they are pursuing a different architecture from the one Afullo chose.

Satlyt wants to supply a software layer that works across spacecraft from many manufacturers. SpaceX represents the opposing route: one company controlling launches, satellites, connectivity, computing hardware, and much of the operating environment.

That difference matters more than the coincidence of sharing a rocket. It frames an early contest over who controls the computing layer above Earth: vertically integrated spacecraft owners or an independent platform connecting mixed fleets.

Satlyt Orbital AI Software Has Moved Beyond a Pitch

The immediate change is that Satlyt now has funding, flight experience, and real workloads instead of a rejected internal proposal.

Afullo worked in Google’s cloud organization before joining SpaceX’s Starlink business in 2024. He told TechCrunch that he pitched orbital computing inside both companies. Each rejected the idea at the time.

He then co-founded Satlyt, which operates from Sunnyvale, California, and Nairobi, Kenya. The company is developing software that lets satellites process data locally and eventually share computing tasks across spacecraft.

Satlyt’s $8 million seed round was led by Houston-based Non Sibi Ventures. The investor’s partners include former NASA astronaut Bernard Harris, whose experience helped the firm evaluate the technical and commercial proposal.

The financing is only one part of the event. Satlyt says its software has already flown on two demonstration missions, giving the company experience with constrained computing beyond laboratory tests.

Its latest reported deployment involves hardware built by TakeMe2Space, an Indian company developing computing systems for satellites. The mission brings three different customer workloads onto the spacecraft.

NASA is paying to test protocols for cloud computing in space. Stellerian, which works on orbital surveillance, plans to evaluate image processing. TakeMe2Space wants to show that its satellite can host software from outside companies.

Those customers represent three important layers of demand. A government agency wants technical validation, a commercial operator wants faster analysis, and a spacecraft builder wants a more flexible product.

That combination gives Satlyt a stronger test than a simple software demonstration. Its platform must support distinct workloads while operating within one spacecraft’s limits on power, memory, temperature, and communications.

The company has also deployed a quantized Gemma 3 model aboard a satellite operated by Momentus. Quantization reduces a model’s numerical precision, helping it run with less memory and computing power.

According to Gemma testing, the one-billion-parameter model analyzed telemetry, application logs, and software errors locally. It ran through llama.cpp, an inference framework designed for efficient model execution.

In two fault-injection tests, the system reduced diagnostic payloads from 1,319 bytes to 469 bytes and from 1,318 bytes to 464 bytes. Those reductions were 64.4% and 64.8%.

The model also produced short diagnoses and recommended actions from the available technical context. That result does not establish reliable autonomous spacecraft operations, but it illustrates an immediate use for onboard AI.

Instead of transmitting every raw log to Earth, a satellite can summarize an error before using a limited downlink window. Ground controllers then receive a smaller, more useful message.

Satlyt’s progress therefore rests on a practical workload, not only the distant idea of enormous orbital data centers. It is starting with software diagnostics, telemetry analysis, and image processing on hardware already heading into orbit.

That creates the article’s central tension. SpaceX and Google can pursue orbital computing through tightly controlled systems, while Satlyt must prove that shared software can work across other companies’ machines.

The Near-Term Market Is Onboard Processing, Not Giant Space Data Centers

Satlyt does not need a full-scale orbital cloud to create value, but it does need satellite operators to treat software as an independent purchasing decision.

Most satellites still depend heavily on ground stations. They collect images, sensor readings, operational data, and error logs, then transmit selected information during scheduled communication windows.

That model creates a bottleneck. A spacecraft can generate more data than it can economically send to Earth, especially when contact windows are brief or bandwidth is contested.

Onboard processing moves part of the decision closer to the sensor. A satellite can discard unusable images, prioritize suspicious objects, summarize faults, or compress observations before transmission.

The idea resembles edge computing on Earth. Edge computing runs analysis near the source of data, reducing the need to send everything into a centralized cloud.

Space makes the tradeoff more severe. A remote terrestrial device might regain a network connection within minutes. A spacecraft can face limited coverage, strict energy budgets, radiation, and no physical repair option.

That is why Satlyt’s diagnostic example matters. Reducing an error report by more than 60% sounds modest beside visions of AI clusters in orbit. It addresses a cost that operators already face.

The company says local analysis can reduce ground-processing work and shorten responses to anomalies. The exact financial savings will vary by satellite, mission, staffing model, and communications contract.

Image processing offers another immediate case. An Earth-observation satellite can identify cloud-covered frames before downlinking them, or prioritize images containing a target condition.

Space-surveillance workloads follow the same logic. A satellite can filter imagery for potential objects or unusual motion, then transmit the most relevant data first.

These applications do not require a warehouse-sized data center in orbit. They require small models that behave predictably on constrained computers and produce useful outputs within strict resource budgets.

That distinction also attracted Satlyt’s lead investor. Non Sibi partner Kent Lucas told TechCrunch that the company does not require giant space data centers to succeed. Satellite growth alone can expand its addressable market.

The argument is sensible, but it still depends on several assumptions. More spacecraft must carry general-purpose processors, operators must permit third-party software, and mission designers must allocate scarce power to AI workloads.

Afullo expects advanced processors to become common in satellites. He has set an ambitious goal of reaching 20% of satellites by the end of this decade.

That target remains a company aspiration, not an independent forecast. Satellite fleets differ widely, and many spacecraft use specialized computers designed for one carefully validated mission.

The opportunity is nevertheless easier to understand than the broad orbital cloud narrative. Satlyt can sell useful onboard processing before satellites begin sharing the largest AI workloads.

Developers should view this phase as a test of software portability. The central question is whether one operating layer can support varied processors, payloads, communications systems, and spacecraft safety requirements.

Enterprise buyers should focus on outputs rather than rhetoric. Reduced downlink volume, faster anomaly response, and higher-value imagery are measurable benefits, even when the underlying system never becomes a giant data center.

Those practical measures also explain why incumbent spacecraft companies face pressure. If customers value portable software, hardware providers lose some control over the applications running on their satellites.

SpaceX Builds the iPhone While Satlyt Wants to Build Android

The primary contest is not Satlyt versus SpaceX by size; it is an open software layer versus a closed, vertically integrated computing stack.

Afullo uses a familiar analogy to explain the difference. If SpaceX becomes the iPhone of orbital data centers, he wants Satlyt to become Android.

The comparison is imperfect, but it captures the strategic split. Apple combines hardware, operating software, services, and distribution under one tightly managed system. Android supports devices from many manufacturers.

SpaceX already controls more of the physical stack than most potential competitors. It builds rockets, operates launch infrastructure, manufactures satellites, manages a communications constellation, and serves connectivity customers.

That integration can reduce coordination costs. Engineers can optimize hardware and software together, maintain consistent interfaces, and move quickly without negotiating standards across unrelated spacecraft vendors.

It also creates dependency. A customer building on a proprietary orbital platform can become tied to one company’s launch schedule, technical roadmap, prices, interfaces, and access decisions.

Satlyt is making the opposite bet. It does not plan to manufacture satellites. Its software is intended to run across spacecraft owned by different operators and turn their computing resources into a shared service.

The company compares its role with VMware and Snowflake. VMware separated applications from specific physical servers, while Snowflake gave customers a managed data layer across cloud infrastructure.

In orbit, this abstraction is much harder. Terrestrial cloud servers use relatively standardized processors, networks, power supplies, storage systems, and maintenance practices.

Satellites are custom machines exposed to radiation, thermal cycles, limited energy, intermittent links, and orbital motion. Even restarting a failed process can have mission-level consequences.

An open orbital platform must therefore do more than install the same package on different computers. It must accommodate hardware differences without weakening safety controls or interfering with essential spacecraft functions.

The platform also needs a secure method for scheduling work. A third-party application cannot consume power, memory, or network capacity needed by navigation, communications, or the primary payload.

Those challenges strengthen the case for vertical integration. SpaceX can design its computing hardware, inter-satellite links, operating environment, and power systems as one coordinated product.

However, integration does not guarantee that customers will prefer a closed system. Satellite manufacturers and operators may want access to several launch providers, processors, models, and analytics vendors.

An independent software layer becomes valuable when diversity increases. Every additional compatible spacecraft expands the potential pool of computing resources without requiring Satlyt to finance a satellite fleet.

This is the same network effect that helped software platforms grow on Earth. A larger hardware base attracts developers, while more applications make the underlying platform more attractive to hardware vendors.

Orbit introduces a difficult cold start. Satlyt needs compatible satellites before developers invest, yet spacecraft builders need useful applications before allocating resources to Satlyt.

Its early missions attempt to solve that problem with concrete workloads. NASA supplies a validation use case, Stellerian supplies an application, and TakeMe2Space supplies hosting hardware.

Google’s approach provides another contrast. Project Suncatcher envisions interconnected satellites carrying Google Tensor Processing Units, or TPUs, powered by abundant solar energy.

The program’s first steps focus on Google’s own computing hardware. Its prototype, built with Planet, was designed to measure how TPUs respond to launch forces, radiation, and space’s thermal environment.

Google confirmed that the prototype reached orbit aboard SpaceX’s Transporter-18 mission on October 1, 2026. The satellite established contact and began its test program.

Google is therefore testing whether its specialized chips can survive and operate in space. Satlyt is testing whether software can make varied orbital computers useful to outside customers.

The companies are not direct competitors today. Their architectures could even become complementary if an independent platform eventually runs workloads on Google-designed or other specialized processors.

Still, their priorities reveal competing centers of control. Google begins with hardware it owns and understands. Satlyt begins with portability across hardware that it does not control.

If orbital computing grows, that distinction will shape margins, customer choice, and developer access. The eventual winner might not own the most satellites, but it will influence how applications move between them.

The Open Orbital Cloud Still Has to Survive Reality

Satlyt’s strongest argument is flexibility, but flexibility becomes a liability when spacecraft differ too much or customers refuse to share resources.

The company has shown that a small language model can process diagnostic data aboard constrained hardware. That is not the same as operating a distributed cloud across satellites.

Satlyt’s next major technical objective is to connect computing capacity across two different spacecraft. The company expects to attempt that demonstration next year.

A successful test would matter because distributed computing requires coordination between machines. Software must divide work, transfer data, handle delays, recover from interruptions, and confirm that results remain correct.

Those tasks are routine inside terrestrial data centers with reliable power and high-speed networks. They become harder when both computers travel around Earth and communicate only under specific orbital conditions.

Latency is not the only problem. Satellites may have different processors, operating systems, security requirements, available power, and mission priorities.

Inter-satellite links can also vary widely. Some spacecraft have laser communications, some use radio links, and many were never designed to exchange large computing workloads with neighboring satellites.

Google has described the precision required for its planned laser connections as equivalent to hitting a coin-sized target from miles away while both points move.

Its tests also illustrate the hardware challenge. Google says launch components can experience forces reaching 50 to 100 times gravity, while radiation can alter data stored in electronic systems.

Thermal control remains equally important. A processor produces heat, but a spacecraft cannot cool it with ordinary airflow because space is a vacuum.

Satlyt’s software cannot remove those physical limits. It can schedule around them only when spacecraft expose accurate telemetry and grant the platform enough operational control.

Cybersecurity creates another barrier. Software that manages workloads across several satellites could become a valuable target because a compromise might affect multiple operators.

Customers will demand isolation between applications, signed updates, access controls, audit records, and clear authority over emergency shutdowns. Those protections consume additional computing resources.

AI outputs add a different risk. A model can summarize an error incorrectly or misclassify an image, especially when its inputs differ from its training and tests.

For that reason, Satlyt’s current diagnostic use looks safer than autonomous command. A model can recommend an action to ground operators without receiving authority to change spacecraft behavior.

The company says operators will retain command authority as it expands toward anomaly detection and multi-agent decisions. The practical boundary between assistance and control will require careful validation.

Business incentives are just as uncertain. A satellite owner might have unused processor time, but lending it to an outside workload can introduce liability without generating enough revenue.

The owner must also reserve capacity for its primary mission. An Earth-imaging satellite cannot delay customer images because another application consumed power or filled storage.

Satlyt’s “Android” strategy works only if spacecraft manufacturers support common interfaces. Without meaningful standardization, every integration becomes a custom engineering project.

That would weaken the economics of an independent platform. Software margins depend on repeating the same product across many customers, not rebuilding it for every satellite.

Competition could also come from companies that own hardware. SpaceX, Google, Starcloud, and other orbital computing ventures can expose developer interfaces while keeping their underlying systems proprietary.

A managed closed platform might prove easier to buy than an open network. Customers often accept vendor dependence when one provider offers simpler deployment, stronger support, and predictable performance.

Satlyt therefore has not established that the Android model will dominate. It has established that the open route is credible enough to receive funding and reach live missions.

The next phase must demonstrate repeatability. One model on one satellite proves feasibility, while portable workloads across different spacecraft would support the broader platform claim.

Three Signals Will Show Whether Satlyt Can Become an Orbital Platform

The next evidence must come from cross-satellite computing, repeat customers, and measurable operational value rather than another ambitious comparison.

The first signal is Satlyt’s planned two-satellite cloud demonstration. This is the most direct test of its central technical claim.

Observers should look for confirmation that the spacecraft come from different platforms. Two identical satellites under one operator would test distributed computing, but not broad interoperability.

The demonstration should also disclose what work moves between the satellites. A small message exchange is less meaningful than coordinated processing with documented latency, resource use, and recovery behavior.

Successful execution would strengthen Satlyt’s case that it can abstract away hardware differences. A delay or narrower demonstration would show that the open platform remains earlier than its marketing suggests.

The second signal is customer repetition. NASA, Stellerian, and TakeMe2Space give the company useful initial workloads, but pilots do not establish durable demand.

A stronger sign would be a customer expanding from one experiment to several spacecraft. That would indicate the software created enough value to survive mission review and budgeting.

Another important measure is the number of independent spacecraft builders integrating Satlyt. The Android analogy requires multiple manufacturers, not several missions on one partner’s hardware.

Satlyt says it has software prepared for as many as 50 spacecraft deployments in 2026. Prepared capacity is not the same as activated deployments, so completed installations matter more.

Readers should distinguish signed agreements, launched systems, active workloads, and paid renewals. Each step carries a different level of commercial evidence.

The third signal is operational performance. Downlink reduction provides an early metric, but customers will also care about accuracy, energy use, memory consumption, and response time.

The Gemma tests offer a useful baseline. Satlyt reported roughly 64% smaller diagnostic payloads and generation speeds above 22 tokens per second in two scenarios.

Its broader tests examine approximately 11 watts of processor power during inference and a temperature increase between three and five degrees Celsius. These are company-provided measurements from constrained test conditions.

Future disclosures should connect those technical results with mission outcomes. Did operators resolve faults sooner, downlink more valuable imagery, or reduce ground workload?

Independent confirmation would carry more weight than another internal benchmark. Spaceflight data from customers or research partners would clarify whether the benefits persist outside controlled tests.

SpaceX and Google are unlikely to wait. Google is already collecting data from its orbital TPU prototype, including performance under radiation and extreme temperatures.

Its next planned milestone involves testing communication between two satellites. Progress there would strengthen the vertically coordinated model, even if Google does not offer a broad commercial platform.

SpaceX has a different advantage: deployment scale. Its control over launch and satellite manufacturing lets it iterate without waiting for unrelated spacecraft providers to adopt a common interface.

Satlyt cannot match those capital resources. Its opportunity comes from making the rest of the market function more like a shared computing base.

That pattern has worked in other industries. Independent software becomes valuable when customers want choice and no hardware vendor can control the entire market.

Space is not a normal software market, however. Reliability standards, physical constraints, national security concerns, and long procurement cycles all slow platform adoption.

Developers should watch the interfaces that emerge from the first missions. A stable application model would make it easier to build once and deploy across several spacecraft.

Satellite buyers should ask who controls updates, workload scheduling, telemetry access, and failure recovery. Those details determine whether “open” means portable or merely compatible through custom work.

Teams assessing the evidence also need disciplined records across mission reports, test results, contracts, and engineering decisions. A searchable knowledge base can keep those claims connected to their supporting documents.

Satlyt orbital AI software has reached an important threshold. It now has capital, flight heritage, customer experiments, and a clear architectural opponent.

The company has not yet built an orbital cloud spanning different satellites. It also has not shown that manufacturers will surrender enough control for an independent platform to scale.

That is what makes the story worth following. The rejected idea is no longer hypothetical, but its defining promise remains unproven.

Over the coming months, watch the two-satellite test, repeat deployments, and mission-level performance data. Together, they will show whether Satlyt is building Android for orbit or a specialized tool for a small number of spacecraft.