AI data centers in space sound great, but practically speaking, they may be next to impossible.

For tech bros, it sounds great. Two of the buzziest tech giants, SpaceX and NVIDIA, are partnering together to bring AI data centers into space using the just-announced Starmind AI1 satellite. 

These 30-meter-tall satellites with a 75-meter solar-array wingspan will contain the latest NVIDIA Vera CPUs and Rubin GPUs. These will live in a Low Earth Orbit (LEO) of about 600 kilometers. For networking, it will use Starlink’s laser links. SpaceX says the first AI1 spacecraft will perform localized AI computing in orbit and relay results to Earth via Starlink. 

According to SpaceX, AI1 is designed around a compute payload drawing up to 250 kW at peak and 175 kW on average. It will be solar-powered, unlike its Earth-bound competitors, which frequently require the construction of new power plants.  

Starmind is not simply a conventional NVIDIA AI cluster launched into orbit. The effort hinges on integrating high-density accelerator hardware with a spacecraft platform capable of generating power, rejecting waste heat, surviving radiation, maintaining laser communications, and being produced in large quantities. None of that is easy. 

Once in orbit, which will require SpaceX’s still-not-ready-for-prime-time Starship rockets to launch the estimated 2.3-metric-ton satellites, the satellites will work together. 

Eventually, to reach SpaceX’s goal of a million (that’s not a typo, that’s a million) Starmind satellites, the two companies will need to design a standard model spacecraft. These will be built in SpaceX’s 11-million-square-foot manufacturing campus, Gigasat Factory, which is still under construction in Bastrop County, Texas.

This AI-in-space proposal is the most ambitious yet of SpaceX CEO Elon Musk’s dream of placing energy-intensive AI infrastructure in orbit. There, these satellites won’t need to compete for land, electrical-grid capacity, or water with increasingly contentious terrestrial data center buildouts. 

However, SpaceX glosses over the technical issues of turning this vision into reality.

Cooling space data centers

Let’s start with the biggest headache: Cooling.

Contrary to what you may think from bad science-fiction movies, the vacuum of space is not cold per se. Whether the surface of an object is hot or cold depends entirely on whether it’s facing the sun. Those on the sun side will heat up, while those away from the sun will eventually cool down toward the 3 Kelvin background of deep space.

The keyword is “eventually.” You can’t simply use convection, cooling towers, or evaporative cooling to carry away heat. The heat must radiate away as infrared radiation, and that’s a very slow process. 

The physics creates a direct trade-off between computing power, radiator area, spacecraft mass, and operating temperature. A system running hundreds of kilowatts of AI hardware must reject nearly all of that power as waste heat. Liquid cooling can carry heat away from chips, but it does not eliminate the requirement for extensive radiator surfaces.

As NASA has found, “satellites experience harsh environments in orbit,” ranging from about 393 Kelvin in full sun (248 degrees Fahrenheit) all the way down to ~3 Kelvin (-454 degrees Fahrenheit).  

To cool down the Starmind satellites, each will have a deployable liquid radiator system measuring 160 square meters. What liquid? We don’t know yet. Hugh Lewis, a professor of astronautics at the University of Birmingham, expects it to use ammonia, which is already used on the International Space Station (ISS). Whether this will reliably scale to data-center-class AI deployments with their enormous heat remains to be seen. 

Networking limits in orbit

Another issue is its networking. The architecture depends heavily on Starlink’s optical inter-satellite links. SpaceX says AI1 satellites will use high-speed laser links to communicate with other spacecraft and send AI results to Earth via the Starlink network. 

Starlink’s published technology specifications describe mini laser terminals operating at up to 25 Gbps across distances as long as 4,000 kilometers, while SpaceX cites roughly 25-millisecond latency for its customer service. 

Those figures suggest a potentially useful network for distributing inference results, transmitting model updates, connecting orbital sensors to compute nodes, and avoiding some reliance on ground-station passes. But they do not establish that a satellite constellation can function like the tightly coupled networking fabric of a terrestrial AI supercomputer.

We won’t be seeing large-scale machine learning and training in space. This requires huge, predictable bandwidth and very low latency for GPU-to-GPU communications. An orbital network would also face physical propagation delays, laser-link acquisition and handoffs, routing across a moving constellation, and limits on available capacity per spacecraft. 

Debris, war and solar storms

Another issue, according to Doug Mohney, a long-time space influencer, is debris. “One bad day, a piece of random junk hits one satellite, which fragments into multiple pieces of shrapnel, which hits another satellite and so on and so on until you get a Kessler event that turns the selective orbit into a roaming cloud of debris.”

A Kessler event is when one satellite breaks up, and its fragments hit another, and so on until an area of LEO is filled with wreckage rather than viable satellites. 

Adding insult to injury, a Kessler event may not happen by accident. Mohney also observes that space warfare is a real threat: “A bad actor such as  Russia, China, Iran, or North Korea could use kinetic (unrandom junk!) means to target one or more satellites, resulting in space debris.” Or, “One good nuclear weapon uses an electromagnetic pulse to get rid of all of them at once. Both Russia and China (and the US) already have anti-satellite weapons (ASAT) programs. North Korea could have ASAT, but a nuke would ensure mass destruction of orbital capability.” 

If that sounds crazy, keep in mind that Starlink satellites are already being used by Ukraine, and Russia has been trying to block their transmissions. There have also been credible reports of Russia developing ASAT weapons specifically designed to knock Starlink satellites out of the sky. Larger and more fragile Starmind satellites would be far more vulnerable.

Mohney also worries about the “known unknown” of space weather.

“A Solar flare that hit the Earth along the lines of the 1859 Carrington Event, the largest recorded solar storm, would take out orbital electronics of all satellites.” This, in turn, as uncontrolled satellites drift from their orbit, might cause a Kessler event.  Lesser events have already pushed LEO satellites out of space. For example, a February 2022 geomagnetic storm forced thirty-eight newly launched Starlink satellites out of orbit. 

The $170 billion question

There are also business concerns. For all the obstacles that new and expanded ground-based AI data centers face, the energy analytics firm Wood Mackenzie believes “A hypothetical 1 GW orbital data center would cost an estimated $170 billion, more than three times the equivalent terrestrial facility, with launch and satellite costs accounting for approximately 60% of that total. To bring orbital costs to parity with terrestrial alternatives would require a 70% reduction.” 

The company thinks that might be possible, but Robert Liew, Wood Mackenzie Research Director, observes, “That gap does not close without sustained and dramatic progress on launch costs. We forecast US$ 9 trillion of terrestrial data center investment between now and 2040. That is where capital goes first. Orbital data centers are a serious long-term proposition, but right now they remain a bet on the cost curve.”

For now, SpaceX has offered a broad technical vision and a hardware partnership with NVIDIA, but few of the operational metrics that would establish commercial viability. The real test will be whether SpaceX Starship becomes a practical launch vehicle and can overcome its cooling and safety issues. Then, the AI1 must also show enough usable compute per kilogram, kilowatt, square meter of radiator, and dollar of launch cost to outperform or complement ground-based AI infrastructure. I don’t see this happening anytime soon. 

The post Why space is actually a terrible place to cool a data center appeared first on The New Stack.

During AI DevCon in London this summer, Lamis Mukta, member of technical staff at Anthropic, hosted a stage presentation session entitled ‘Learning while you sleep, beyond memory to dreaming’.  

Mukta set out to examine where state-of-the-art memory management sits today in a world where (as she put it) “context is often orthogonal to the model intelligence” at hand.

“The newest model we’ve just released isn’t going to go out of the box and know exactly what it takes to succeed in your organization and what tasks you want it to do,” said Mukta. “It’s like agents [initially] not knowing their way around a codebase or knowing enough about your own user preferences.”

To steer agentic services the right way, systems obviously need access to memory to create a context window.

A brief history of Anthropic memory management 

Providing a brief history of Anthropic memory management, Mukta said that traditional approaches made use of CLAUDE.md, a file that Claude reads at the start of every conversation (that includes Bash commands, code style, and workflow rules) to give Claude persistent context that it can’t infer from code alone.

Effective to a degree, this technique becomes hard to manage over time, especially when a file with very important preferences gets very, very long. 

“So a second avenue that we investigated was memory tools, and this is interesting because it leans into the idea of what happens if we let agents autonomously manage their own memory systems? We let them decide when they read, when they write, and when they update memories,” explained Mukta.

This process happens in-band i.e. within the context of a session. When dovetailed with so-called progressive disclosure, the agent only looks at the light metadata at Layer 1, before reaching for full content and original source files in Layers 2 and 3, respectively, so that the system doesn’t overload the model’s context. 

“The way I like to think about it is as if I’d had a bookshelf in my room, and every time someone talks to me, I can kind of scan and look at my list of books and see if any of the titles might be relevant to the conversation, and then pick that off the shelf and read it when I need to,” explained Mukta.

But the bottleneck here is that we’re still driven by humans and agents working together i.e. we’re still being quite opinionated about what things need skills. The additional problem here is that memories can go stale and become irrelevant to an organization’s needs. Add the fact that a memory file may be written incorrectly or even maliciously injected and you can see why a lot of guardrails need to be in place.

“We introduced the concept of dreaming, which is a process that runs asynchronously in batch with its own allocated resources, to ensure that memories themselves are effective, up to date, and [so we can] help the agents learn over time.” 

Dreaming consolidates memory & cuts irrelevance

“So we introduced the concept of dreaming, which is a process that runs asynchronously in batch with its own allocated resources, to ensure that memories themselves are effective, up to date, and [so we can] help the agents learn over time,” explained Mukta. “[This process allows us] to consolidate memory and cut things that are no longer relevant, add things that agents are missing, and clean up and organize memory systems.”

In Anthropic’s world of slumber, dreaming is an out-of-band asynchronous process which the organization says solves the in-band limitation, where agents must split effort between completing and executing tasks, while also concurrently curating memory for their future selves. Dreaming spots recurring failure patterns where agents are consistently failing (wrong units, missing topics, broken tool configs, stylistic tics like overused em dashes), and proposes memory-store updates, again for human review, but hopefully at a more effecient level. 

This architecture underpins Anthropic’s Managed Agents memory and API approach at this level, so has the frontier model company won over developers?

Bad memories can outlive sessions

Staff software engineer, cloud architect and independent researcher in AI agent systems, Jayakumar Ramalingam, tells The New Stack that “dreaming is useful, but it also creates a dangerous promotion path” i.e. one that leads from repeated mistakes to persistent policy. 

“A bad answer normally dies with the session; a bad memory can influence thousands of future sessions. Human review sounds reassuring, but at fleet scale it can easily become a rubber stamp for recommendations nobody has time to reconstruct,” Ramalingam says. 

“The industry has spent too much time treating memory as a context window problem when it is really a state management problem.”

He insists that every proposed memory should “carry provenance, evidence and an expiration condition”, and not just exist as a pattern that recurred often enough to look real. Otherwise, he thinks that dreaming may help agents remember more while making organizations forget why the memory was trusted.

“Anthropic is getting one important thing right: its agent memory should look more like versioned infrastructure than artificial cognition. The industry has spent too much time treating memory as a context window problem when it is really a state management problem,” underlines Ramalingam. 

His point is – if an agent cannot show who changed a memory, why it changed and how to roll it back, it does not have production memory, so it becomes an unaudited configuration file with an AI attached.

Dreaming is the right instinct aimed at the wrong evidence

Enterprise AI architect and founder of Besk Tech, Vladimir Beskorovainyi, tells The New Stack that “dreaming is the right instinct aimed at the wrong evidence”, because the failures it catches (wrong units, broken tool configs, too many em dashes etc) are all visible on the surface of a transcript.

“The failure that actually costs you is an agent reaching for the wrong tool for a reason that looked perfectly defensible at the time,” Beskorovainyi says. “In the systems I run in production, the log records the decision rather than the API call, and that is the only reason a review pass like this finds anything worth finding.”

“When the ‘lately’ factor quietly becomes true. That leaves us at a point where versioning tells us what changed and when, not what is correct.”

He points to what he calls “a worse problem underneath the agent’s decision” i.e. if updates are proposed from recent batches, the memory store drifts towards whatever the agent fleet happened to do lately, and so the “lately” factor quietly becomes true. That leaves us at a point where versioning tells us what changed and when, not what is correct.

“The industry spent two years insisting that memory meant embeddings, and Anthropic solved it with a filesystem and grep [a Linux command that searches for patterns in files] and that is the most interesting decision in this whole discussion,” insists Beskorovainyi.

He says the reason it matters is legibility. A memory store a developer can open and read is a memory store an engineer can audit, and (he insists) “no vector database has ever offered that”, while everything else in the architecture (the versioning, the hashes, the tiered permissions), is ordinary distributed systems engineering we have known how to do for decades.

Dreaming is the clever (but worring) part

Founder of autonomous AI penetration testing company Penetrify, Viktor Bulanek, tells The New Stack that when the industry spent two years convinced that agent memory was a vector database problem, and Anthropic shipped grep, that was a useful thing.

“In terms of what Anthropic is getting right… a memory store you can cat, diff and code review is one you can actually operate, whereas nobody has ever successfully debugged an embedding that quietly ranked the wrong chunk third,” Bulanek says.

“Anthropic’s approach to dreaming is the clever part and also the part that worries me most, because it points an automated writer at session transcripts, and transcripts are full of content the agent did not author.” 

He thinks that the versioning matters here far more than the auditability framing suggests and reminds us that “rollback is not a compliance feature”; it is the undo button for a poisoned memory a software engineer discovers three weeks after it was written, which is the incident every serious agent deployment is going to have eventually.

“But to add balance here, Anthropic’s approach to dreaming is the clever part and also the part that worries me most, because it points an automated writer at session transcripts, and transcripts are full of content the agent did not author,” Bulanek cautions. 

“Anthropic is right that human review is the answer, but bulk review of proposed diffs is exactly the control that decays fastest once the suggestions are mostly good. The other gap is that nothing in this architecture says when a stored fact stops being true. Versioning tells you what changed, it does not tell you what rotted, and a confident note about a system that was refactored last month is worse than no memory at all,” he advises.

Bulanek’s work sees him run autonomous agents in production that perform penetration testing and run for hours unsupervised with real credentials against live systems, so memory for his team is both an operational cost and a security boundary at the same time.

The Anthropic way of doing things has an endearing lack of flair to it

Co-founder and CTO of Noah Labs, Berk Yilmaz, tells The New Stack that the Anthropic way of doing things has “an endearing lack of flair to it” in his view. 

“Everyone wants memory to feel like the newest incarnation of machine intelligence, and their pitch goes something like: just give it a filesystem, versioning, searchability, and don’t let a thousand processes stamp all over each other,” Yilmaz says. “This is closer to how production AI should be done. While we have spent a long time improving models, the supporting infrastructure has not kept up, failing in incredibly prosaic engineering ways.”

Yilmaz is behind a company that develops an AI-native IDE for government and regulated systems, built for air-gapped environments and legacy codebases. He reminds us that once a memory decision is made on which past behavior should become future behavior, memory itself ceases to be inert. 

“A hallucination that dies after a single session is a pain in the neck, but a hallucination that outlives a thousand sessions is infrastructure. The same thing applies to security; if an attack succeeds in writing to memory, it has become persistent. Provenance becomes absolutely critical here, how was the system taught this, where did it learn it from, who certified it, and can I undo it? In enterprise AI, sometimes forgetting is a safety measure,” adds Yilmaz.

A pragmatist would remember that Anthropic gets paid for usage, not efficiency

AI, product & data science leader and former Meta employee, Kerstin Frailey, tells The New Stack that at face value, dreaming (for her money) “certainly sounds like it has the potential to blow up AI bills” right now.

“A cynic would say this is designed to fill the revenue hole left by tokenmaxxing before Anthropic’s IPO,” Frailey says. “An optimist would hope for a beautifully thrifty design. A pragmatist would remember that Anthropic gets paid for usage, not efficiency. A skilled practitioner would run incremental pilots, aggressively monitor costs, and routinely test for measurable improvements.”

“As a nice bonus, dreaming offers potential system improvement, too. But its familiar predecessors – garbage collection and storage compaction – are comparatively deterministic and controlled.”

She continues and notes that dreaming offers cleanup and consolidation, which she defines as a “reasonable development” for any system that constantly generates new files. 

“As a nice bonus, it offers potential system improvement, too. But its familiar predecessors – garbage collection and storage compaction – are comparatively deterministic and controlled. Unlike its namesake or those analogues, dreaming appears neither cheap nor efficient: pay an AI to do the work once, then pay AIs to regularly review, revise, and restructure it,” she adds.

Dreaming as part of Anthropic’s Managed Agents memory and API approach isn’t alone. The notion of AI model dreaming (or automatic out-of-band background memory consolidation if we’re being formal about things) is also being popularised by OpenAI for ChatGPT, in stateful agent coding platform Letta and elsewhere. 

The bottom line here may be a realization that, in AI modeling terms at least, memory is actually maintenance.

The post Anthropic gave agents the ability to dream. Then developers woke up. appeared first on The New Stack.