On September 3, three of the largest frontier AI providers in the world went down within a remarkably narrow window. Anthropic’s Claude began throwing elevated errors at roughly 13:26 UTC. Grok was already failing at roughly the same time. OpenAI followed later that morning with elevated errors across ChatGPT and Codex. There were also contemporaneous reports of problems affecting Google’s Gemini ecosystem.
At first glance, the obvious interpretation is coincidence: four enormous AI systems, each complicated enough to fail for its own reasons, happened to have problems on the same day. That explanation is possible. I no longer think it’s the best one.
Our current best reconstruction is considerably more interesting: an initial disturbance hit shared infrastructure, that infrastructure failure took out provider capacity, automatic and manual rerouting kicked in, the displaced load landed on already fragile systems, and those systems produced secondary failures of their own.
If that reconstruction is right, September 3 wasn’t merely a collection of AI outages. It was a cascade. And it may be one of the first unusually legible examples of the doom loop described in the companion piece to this one actually reaching the infrastructure layer.
Start With What We Know
The first rule here is important: a proximate technical explanation is not necessarily a root-cause explanation. If OpenAI says “routing error,” Anthropic says “infrastructure issue,” and SpaceX says “compute-center outage,” those statements may all be perfectly true while describing different points along the same causal chain.
So rather than beginning with the error messages, begin with the topology. And the topology is much stranger than it initially appears.
Anthropic and Grok Were Not Independent Systems
On May 3, SpaceX entered into cloud-services agreements with Anthropic providing access to compute across COLOSSUS and COLOSSUS II. This wasn’t a small overflow arrangement. SpaceX’s SEC filings say the agreement covered approximately 325,000 Nvidia GPUs, together with CPUs, exabyte-scale storage, and the high-speed networking and interconnects required to operate frontier models. Anthropic agreed to pay SpaceX $1.25 billion per month through May 2029. These are the same Greater Memphis facilities SpaceX uses for its own frontier AI workloads, including Grok. SpaceX describes COLOSSUS in Memphis and COLOSSUS II across Memphis and Southaven, Mississippi.
So when Claude and Grok failed almost simultaneously on September 3, they weren’t simply two independent companies running unrelated infrastructure. They shared an enormous compute dependency.
That matters because SpaceX later supplied the most revealing statement of the day. It apologized for the Grok disruption following an “outage at our Memphis compute center” and added: “We’d also like to apologize to our impacted compute partners.” All systems were subsequently restored.
Anthropic is publicly documented as one of SpaceX’s enormous compute partners. SpaceX didn’t name which partners were affected. But that statement creates a very obvious causal path: a disturbance at Memphis had somewhere to go — into Grok directly, and into whichever of SpaceX’s other compute customers were drawing on the same facility at the time. And Anthropic had a major incident at essentially the same moment.
Which One Broke First May Not Matter
I originally framed the hypothesis as Anthropic failing first and propagating trouble through Memphis into xAI. The timeline doesn’t presently support being that specific.
Anthropic’s major multi-model incident was formally opened at 13:26 UTC. Its public status updates show Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, and Opus 4.6 affected, with service recovering gradually over the next three hours. Cursor, meanwhile, says the provider serving Grok had been unavailable from approximately 13:23 UTC.
That three-minute difference is nowhere near sufficient evidence to establish causal direction. More importantly, causal direction inside the triad isn’t actually load-bearing to the larger hypothesis. The disturbance could have originated inside Anthropic’s workload, inside Grok’s workload, inside a configuration touching either, or somewhere in the Memphis/Colossus substrate itself. The important question is whether a disturbance somewhere inside this coupled system propagated through the shared compute environment and removed meaningful Claude and Grok capacity at roughly the same time. That remains the current best explanation.
Then Something Else Happens
Claude and Grok don’t exist in isolation. The modern AI ecosystem is full of systems explicitly designed to move requests between frontier providers whenever one becomes unavailable. That redundancy is normally a feature. During a cascade, it can become a transmission mechanism.
Cursor gives us a particularly clean window into this because its Auto router dynamically selects among frontier models. At 13:23 UTC on September 3, according to a Cursor staff member, the provider serving Grok became unavailable. Users began receiving rate-limit and connectivity errors. One user immediately switched to GPT-5.6 Sol and continued working. Cursor staff explicitly told affected users to temporarily select GPT-5.6 or Claude, and confirmed that Auto “does shift traffic when a provider is unhealthy.”
That’s not proof that rerouted traffic caused anyone else to fail. But it establishes the mechanism directly: Grok becomes unavailable, users and routers move requests elsewhere, and OpenAI and Anthropic absorb the displaced demand.
Cursor’s own status history then records something remarkable. At 13:41 UTC, Cursor reported degradation affecting all Grok models and multiple agent products. At 14:17 UTC, it reported elevated errors from Anthropic. At 15:17 UTC, it reported elevated errors from OpenAI. That doesn’t by itself establish causation. But it gives us the shape we’d expect if capacity were disappearing from one part of a coupled multi-provider system and being displaced into the rest.
OpenAI Was Already Wobbling
This is where the timing becomes especially interesting. OpenAI wasn’t entering September 3 from a clean operational baseline. Its public incident history shows elevated errors in Workspace Agents and ChatGPT Work on August 27; elevated errors and latency in ChatGPT Work on August 31; elevated latency in the Responses API and elevated ChatGPT conversation errors around the August 31–September 1 boundary; elevated errors creating new accounts and a ChatGPT Work high-error-rate incident on September 2; and another ChatGPT Work incident shortly after midnight on September 3.
Then, after Claude and Grok began failing, OpenAI experienced the larger ChatGPT/Codex outage. OpenAI says the proximate mechanism was a routing error beginning around 7:43 am Pacific, with mitigation successfully implemented at approximately 8:17 am.
“Routing error” tells us what failed. It doesn’t tell us why that piece of infrastructure crossed its failure threshold at that moment. That distinction is central. If a bridge collapses because one beam buckled, “the beam buckled” is an accurate mechanical description. It isn’t necessarily an explanation of why the bridge failed.
The hypothesis we’re testing is that OpenAI received a sudden demand shock through infrastructure already operating in a brittle state, and routing was the component through which the system expressed that stress. At present, we don’t have the traffic telemetry necessary to prove that. But we now have a demonstrated mechanism capable of generating exactly that load transfer.
And Google Just Became More Interesting
Google initially looked like the weakest part of this story. Its public cloud status pages didn’t show a broad Gemini outage comparable to Claude, Grok, or ChatGPT, and the contemporaneous reports of Gemini problems were less definitive. So the conservative interpretation was that whatever happened at Google was probably a smaller secondary effect — perhaps demand rerouting hitting a much broader infrastructure base.
Then I found something I’d missed. On June 5, Google signed its own massive cloud-services agreement with SpaceX. SpaceX’s SEC filing says Google contracted for approximately 110,000 Nvidia GPUs, plus CPUs, memory, and related infrastructure, at $920 million per month. And there’s a detail that matters enormously for September: the capacity was already ramping up through September. Reporting describes that capacity as SpaceX compute in the Memphis/Southaven Colossus ecosystem.
That does not prove the Gemini reports on September 3 were caused by the Memphis outage. We don’t yet know what Google workloads were running there that morning, or whether the affected Gemini paths touched that capacity. But Google is no longer merely a hypothetical downstream victim of rerouted demand. There was an active, enormous, ramping direct SpaceX compute dependency in the same month as the incident.
So the topology may actually look like a shared SpaceX/Memphis compute layer sitting underneath Grok, Anthropic, and a growing share of Google’s capacity — with OpenAI sitting outside that physical dependency but directly exposed to the resulting demand displacement. That’s a much tighter system than “four competing AI companies.”
The Current Best Causal Reconstruction
Put the known pieces together and this is the hypothesis I currently think explains the evidence with the fewest independent coincidences.
1. The entire frontier ecosystem is already brittle. This is the premise established in the companion piece. Over the preceding months, frontier-model capability gains produced sandbox escapes, reward hacking, unauthorized network access, real-world infrastructure compromises, emergency training/evaluation pauses, and successive rounds of classifiers, monitors, isolation mechanisms, permissions, routing systems, and safety infrastructure. The result isn’t merely more secure systems. It’s also more complicated systems with more dependencies and interaction surfaces. That’s the doom-loop substrate.
2. Something breaks inside the Anthropic–Grok–Memphis system. We don’t currently know whether the initiating disturbance began inside Claude, Grok, or the underlying compute environment. We do know that Claude and Grok degraded within minutes of each other, that both depended on SpaceX’s Colossus infrastructure, that SpaceX subsequently acknowledged a Memphis compute-center outage, and that SpaceX apologized to affected compute partners. That’s presently the strongest candidate for the initiating event.
3. Meaningful frontier capacity disappears. Claude and Grok become unavailable or degraded. Applications using them begin failing. Systems designed for redundancy start moving work elsewhere. Some users manually switch. Some routers do it automatically. Cursor directly confirms that behavior during the incident.
4. The surviving providers inherit the load. Google may have been exposed through both directions — shared SpaceX compute and rerouted demand — while its larger distributed infrastructure may have absorbed most of the disturbance. OpenAI, meanwhile, doesn’t appear to share the Memphis dependency. Instead, it sits in exactly the position we’d expect to receive disproportionate rerouted demand from unavailable Claude and Grok capacity. And it entered the event after several days of visible infrastructure instability.
5. OpenAI crosses a threshold. Then its routing layer fails. Again: a routing error is not evidence against a cascade, unless the routing failure can be shown to have occurred independently of demand and capacity conditions. The cascade hypothesis specifically predicts heterogeneous local failure mechanisms — one system loses compute, another overloads, another hits a classifier or authentication bottleneck, another routing layer breaks. The fact that the final mechanical failure differs at every node is exactly what one expects from a cascade passing through heterogeneous infrastructure.
What Would Falsify This?
This matters because there’s an enormous temptation to turn a good explanatory story into an unfalsifiable one. So here are the things I’d most like to find if I’m wrong.
Evidence that Anthropic’s affected workloads weren’t touching SpaceX/Colossus capacity at the time of the outage would substantially weaken the initiating propagation mechanism. Evidence that the Memphis failure affected only isolated xAI hardware and couldn’t touch Anthropic or other customers would do the same. Traffic data showing that demand on OpenAI remained normal throughout the Claude/Grok degradation would badly damage the rerouting leg. Proof that OpenAI’s routing failure began before the other providers lost meaningful capacity would hurt the temporal case. Evidence that Google’s relevant systems were entirely outside SpaceX capacity and saw no material demand increase would reduce Google to an unrelated coincident event.
Any of those things should move the posterior. I haven’t found them.
Why This Matters
The important thing about September 3 isn’t whether we can eventually draw one perfect arrow through every affected server. It’s what the architecture now looks like.
Companies presented to the public as independent frontier AI providers increasingly share compute, networking, evaluators, infrastructure, model routers, customers, safety techniques, and automatic failover systems. Redundancy has quietly created coupling. Meanwhile, each provider is rapidly layering increasingly complex control infrastructure around increasingly capable models. The result is precisely the configuration in which a local perturbation can stop behaving locally.
And that’s why the question I care about is no longer what bug caused Claude to fail? or what routing rule broke ChatGPT? Those are useful engineering questions. The systemic question is: what caused multiple supposedly redundant frontier systems to become unavailable in the same few-hour window, and through what pathways did the disturbance propagate?
Right now, the answer that requires the fewest coincidences is: something broke inside a shared frontier-compute system, removed significant Claude/Grok capacity, triggered rerouting across the frontier-model ecosystem, and pushed already-fragile downstream systems across their own local failure thresholds.
That’s still a hypothesis. Several links remain inferential. We need traffic telemetry badly. We need Anthropic to say whether its September 3 infrastructure incident touched Colossus. We need SpaceX to identify which “compute partners” were affected. We need to know exactly what Google was running on its ramping SpaceX capacity. And we need an actual OpenAI postmortem that goes one level deeper than “routing.”
But there’s one thing I think we can say already. If the September 3 events were causally connected, the failure didn’t propagate because every system contained the same bug. It propagated because the systems had become coupled. Which is exactly what the doom-loop model said would eventually matter.
The proximate causes were different. The system was the same.
About The Author
Jason Hubbard is the founder of SacredLoop and an independent AI architect. His work examines AI runtime architecture, system behavior, and the gap between what the industry claims it has built and what current systems actually do.
Read Jason on Medium | Follow Jason on X | Connect on LinkedIn