On the morning of September 3, 2026, ChatGPT and Codex went down because of a routing error at OpenAI. Around the same time, Anthropic’s Claude had a three-hour outage tied to an infrastructure issue affecting its models. xAI’s Grok went down too, because of a problem at its Memphis compute center. Three separate companies, three separate root causes, all failing within the same few hours. Nobody has proven a single shared cause, and it might just be coincidence. That’s almost beside the point. What mattered that morning was what happened next: Cursor’s agent turns started failing. GitHub Copilot degraded because an upstream model provider was down. Support bots, coding assistants, and “AI-powered” features across a huge number of products just stopped working, all at once, for hours, with the people running those products unable to do anything but wait.
We build software for a living, including software that calls out to models like these. So we don’t read this as an argument against using AI APIs. We read it as a reminder that most teams are treating a third-party API as if it were part of their own infrastructure, without giving it the same treatment they’d give a database or a payment processor: a failure mode, a fallback, and a plan for what the product does when the dependency isn’t there.
A single vendor is a single point of failure, even a good one
If your product’s core loop calls one model at one provider with no fallback, that provider’s status page is now your status page. That’s true whether the dependency is an AI vendor, a single cloud region, or a single database with no replica. The industry has spent two decades building discipline around avoiding single points of failure in infrastructure: multi-region deployments, health checks, circuit breakers, graceful degradation. A lot of that discipline quietly got dropped when teams started wiring LLM calls directly into critical paths, because it felt like calling an API, not like taking on an infrastructure dependency. It is an infrastructure dependency. Treat it like one.
That doesn’t mean every product needs multi-provider failover for every AI feature. It means someone should have actually decided that, on purpose, instead of finding out during an outage that nobody had. If an AI feature is decorative (a “summarize this” button, a nice-to-have suggestion), losing it for three hours is fine, as long as the rest of the product keeps working. If an AI feature is the product, you need to know that going in and design accordingly: a secondary model provider you can route to, a cached or rule-based fallback for the common cases, or at minimum a clear, fast failure state instead of a spinner that never resolves.
Where this connects to how we build
This is exactly the kind of thing that gets skipped when a product is stood up fast on someone else’s stack with no plan for what happens when a piece of it goes away. Part of our cloud and infrastructure work is making these dependencies explicit: which services are load-bearing, what happens when each one fails, and what’s defined in code so a failure mode isn’t a surprise discovered in production. That’s not exotic. It’s the same question you’d ask about a payment processor or an email provider, applied to a category of vendor that’s newer and, for a lot of teams, less scrutinized.
Local-first design is the other lever here, and it’s worth naming directly because it’s not just a privacy story. An app that keeps its core data and core functionality on the user’s device, syncing when a connection is available, doesn’t go down when someone else’s server does. That’s the argument behind our local-first software work. It’s usually pitched as a privacy story: your data stays on your device. It’s just as much a resilience story: your app keeps working. Not every product can or should be local-first. But if a feature can run without a live round trip to a cloud model on every interaction, that’s worth building, because it’s one less dependency that can take your product down on a Thursday morning for reasons entirely outside your control.
The part that should worry founders more
The scarier detail isn’t the outage itself. Outages happen; they always have. It’s how much of the industry has quietly built products where an AI vendor going down means the product goes down, full stop, with no degraded mode in between “fully working” and “completely broken.” That’s a design choice, usually made by default rather than on purpose, by teams moving fast enough that “what if the model API is unavailable” never made it onto a whiteboard.
If you’re building something where an AI feature sits on the critical path, ask concretely: what does a user see if that call times out, errors, or is rate-limited? Is there a cached response, a simpler non-AI path, or an honest “this feature is temporarily unavailable” state? Or does the whole screen just spin? Most teams we talk to haven’t answered that question, because until September 3 they never had to.
We’re not going to pretend concentration risk in AI infrastructure is going away. Three or four companies run most of the frontier models, and that’s the market for the foreseeable future. But your product’s resilience doesn’t have to inherit their concentration. Decide what’s load-bearing, build a real fallback for it, and keep as much running locally as the product allows. If you’re weighing that tradeoff for something you’re building or already shipping, get in touch.