Three Edge Constellations in Two Weeks
A billion-dollar program in Paris, a $300 million financing framework, and a Chinese launch. The supply side of hosted orbital compute arrived this month, and it is shared.
September has been busy on the supply side.
On the 9th, Orbitworks and Loft Orbital announced a billion-dollar program in Paris for a fifty-satellite constellation with AI compute on board, built to carry applications from more than one provider. On the 14th, Sophia Space and SLI announced a 300 million dollar financing framework for a ten-satellite edge computing constellation. On the 20th, CAS Space’s Kinetica-1 lifted off with nine satellites, among them Supercomputing-1, which pairs a camera with an on-board AI computer so that Earth observation imagery can be processed in orbit and only the useful part sent down. The stated goal is to cut response times from hours to minutes.
Three programs, three countries, two weeks. None of them is a megawatt data center. All of them are the fleet we described in June: modest compute, next to a sensor, in an ordinary orbit, doing Earth observation first.
The word that is new this month is shared.
Shared means scheduled
A single-customer satellite does not need a scheduler. The operator knows the one workload, knows the orbit, and plans it by hand. It works, at the cost of an engineer’s afternoon every time something changes.
A shared satellite is a different animal. Orbitworks has said customers will choose applications from several providers and run them on the same spacecraft. That means several tenants want the same sunlit minutes, the same handful of passes, the same power budget and the same thermal margin. Somebody has to decide whose job runs in which window, and somebody has to be able to say no, with a reason, when a job does not fit.
That somebody is a scheduler. Today, in most operations we know of, it is a person with a spreadsheet, and the spreadsheet works right up until the third customer signs.
One shared satellite, one orbit, three customers. Two fit. The third needs more power than is left before its deadline, and the honest answer is no, now, rather than a missed deadline later.
What a good answer looks like
Three things, in our experience.
It is a plan, not a queue. A queue says your job will run when the one ahead of it finishes. A plan says your job will run in this window, on this satellite, with this much power, and its result will come down on this pass. Customers can build on the second. They cannot build on the first.
It refuses early. The worst outcome on a shared satellite is a job that was accepted, consumed power and a pass, and then did not finish before its deadline because it was never going to. A scheduler that knows the windows can say no before the job is uploaded, and say why. That is worth more to the customer than a yes.
It is the same answer for everyone. The operator, the customer, and the on-board agent should all be looking at the same plan. The moment the spreadsheet and the spacecraft disagree, somebody’s job gets dropped and nobody can say whose.
That is how our planner is built, and it is why we built it that way before there were shared constellations to run it on. We do not know how Orbitworks or Sophia will allocate their satellites, and we are not claiming to. What we are saying is that the programs announced this month have created, on paper, exactly the problem the planner answers.
The quiet implication
A year ago the question was whether anyone would put compute on satellites to sell. This month three programs said yes, with money behind the answer. The next question is what happens when the second and third customer show up on the same spacecraft, and the answer to that is not a bigger radiator or a better chip. It is a schedule.