AI Infrastructure Failed on April 15: What Five Platforms Exposed About the Systems You Depend On

On April 15, 2026, I was running a routine workday across multiple AI platforms when Anthropic’s Claude went down. Within minutes, usage surged on Cerebras. Then Cerebras buckled. Then Qwen, running on the same Cerebras infrastructure, started returning rate limit errors even for users with paid credits in their accounts. Three platforms. One afternoon. A cascading failure pattern that left most AI users staring at error screens while their work sat frozen mid-thought.

I kept working. Not because I had special access or enterprise-tier support. Because I was running five AI systems simultaneously across four competing platforms, and when one broke, I moved to the next. That experience, measured across a full day of real work rather than hypothetical scenarios, exposed failure modes that no status page, no benchmark score, and no marketing comparison will ever show you. This is what I found.

The Cascade Nobody Saw Coming

The pattern started the way infrastructure failures always start: one platform showed elevated errors and users migrated. Anthropic’s status page confirmed the outage within minutes. Claude.ai, the developer console, and Claude Code all went down. Users who depended on Claude for their daily work immediately moved to the next available option.

The next available option was Cerebras, which had been gaining traction as the fastest inference provider in the market. But the same migration pattern that makes Cerebras attractive during normal conditions made it vulnerable during abnormal ones. A significant number of Claude’s displaced users hit Cerebras infrastructure at roughly the same time. Cerebras, already operating under temporary rate limit reductions for its free tier, started throttling. Users with paid credits saw 429 errors (tokens per minute exceeded) despite having unused balance in their accounts.

Then Qwen, which runs on Cerebras hardware through various middleware providers, inherited the congestion. A fresh Qwen session returned a response about the “anthropic apocalypse” being a hypothetical AI safety scenario rather than recognizing that Anthropic is the company that makes Claude and had just experienced a real-world service disruption. The model didn’t even know the name of the company whose outage was causing its own degradation. (I have that conversation. It’s exactly as absurd as it sounds.)

This cascade pattern isn’t theoretical. Industry reporting from early 2026 has documented the same dynamic: when one platform goes down, the surge overwhelms competitors. The platforms are accidentally stress-testing each other’s infrastructure every time one of them fails. And according to independent monitoring data from IsDown, Anthropic reported 55 incidents in February 2026 alone, totaling approximately 282 hours of incident time. OpenAI reported 23 incidents. These aren’t rare events. They’re the operating condition.

Two Layers, Two Realities

The most revealing finding from April 15 wasn’t that platforms crashed. It was how they crashed. The consumer-facing interfaces (the web apps and mobile apps that most people use) went down first and stayed down longest. The API layers, the developer endpoints that power programmatic access, recovered faster or never went down at all.

That split matters more than any benchmark because it creates two classes of users. If you access AI through the consumer interface, you’re on the fragile layer. When it breaks, you wait. You have no alternative path. No workaround. No visibility into when service returns. If you access AI through the API, you’re on the resilient layer. You might see degraded performance, but you keep working.

During the April 15 outage, middleware services that route API calls directly to model endpoints stayed operational while the consumer web interfaces went dark. Users with technical capability to route around the failure continued their work. Users without that capability, which is the vast majority of paying customers, lost their afternoon.

The inequality here is structural, not incidental. API access requires engineering knowledge, separate billing arrangements, and often a different pricing model. The person paying $20 or $100 per month for a consumer subscription is buying the fragile layer. The developer paying per token through the API is buying the resilient layer. Both are paying. One keeps working when the infrastructure fails. The other doesn’t.

And that gap will get worse, not better. As AI becomes more embedded in daily work, the cost of a consumer-layer outage compounds. Losing access to your AI-assisted workflow for three hours in 2026 is an inconvenience. Losing it for three hours in 2028, when entire business processes depend on it, is a crisis.

What Gets Lost When the Lights Stay On

Outages are the visible failure. The invisible one is more expensive.

During the April 15 session, I tested multiple AI systems with the same methodology across extended conversations. What I measured was correction decay, the rate at which an AI system loses the instructions, preferences, and contextual awareness you’ve given it during a conversation. I’ve been measuring this pattern for over five weeks across multiple platforms, and the data is consistent enough to describe with precision.

On one platform, formatting corrections lasted approximately 20 messages before the system reverted to its default behavior. I would instruct it to write in short paragraphs without bullet points, and it would comply for a stretch. By message 25 or 30, the bullet points returned. The hedging language returned. The meta-commentary (“let me be clear,” “I think what you’re asking is”) returned. The model’s training data, which taught it to be generically helpful in a specific way, overpowered the live corrections I’d given it.

On another platform, where I’ve maintained a persistent set of correction rules developed over hundreds of hours of interaction, the same corrections persisted longer but still degraded under sustained load. Even with 29 explicit voice and formatting rules loaded at the start of every session, the underlying model behavior bleeds through. The rules don’t prevent the trained patterns. They delay them.

This is what I’ve come to call the correction tax: the cumulative cost of re-teaching AI systems the same preferences, the same context, and the same behavioral expectations session after session. Every correction you give costs attention and time. If the correction doesn’t persist, you pay that cost again. And again. Across hundreds of sessions, the tax becomes significant.

The context window size isn’t the limiting factor, and that surprised me. Both platforms I tested extensively now support context windows exceeding one million tokens. The corrections aren’t being lost because the window runs out of space. They’re being lost because the weight of the base model’s training data gradually overwhelms the weight of your in-session instructions. A bigger bucket doesn’t fix a leaky pipe. I have over five weeks of evidence confirming that.

The Dashboard That Doesn’t Exist

During the testing on April 15, I switched between platforms repeatedly. On one platform, the usage dashboard showed me exactly where I stood at all times: session percentage used, weekly allocation remaining, per-model breakdowns, and a countdown timer to the next reset. At 23% session usage and 22% weekly, I knew precisely how much runway I had and when it would refresh.

On the competing platform, there was nothing. No session counter. No weekly percentage. No model-specific breakdown. No reset timer. The system simply stopped responding when I hit the limit. No warning beforehand. No indication of when access would return. I found myself manually checking every few minutes to triangulate the reset window, reverse-engineering usage limits that should have been displayed in a dashboard.

This isn’t a minor UX gap. It’s a fundamental respect gap. If you’re charging customers a monthly fee and rate-limiting their usage, the absolute minimum is telling them what they’ve consumed and when they get more. You can’t optimize what you can’t measure. You can’t plan work around limits you can’t see. You can’t budget your usage toward important tasks when the system just cuts off mid-conversation without warning.

I lost an active conversation during the April 15 session to an unannounced disruption. Not a polite “you’re approaching your limit” notification. Just gone. Mid-sentence. The context of that conversation, the corrections I’d made, the work I’d done within it, all inaccessible until the system decided to come back.

Meanwhile, the platform with the visible dashboard let me make informed decisions throughout the day. I could see that heavy usage earlier had consumed a specific percentage. I could calculate whether my remaining allocation would carry me through the work I needed to finish. I could plan. The difference between these two experiences is the difference between a tool that respects your time and one that treats your access as a privilege it can revoke without explanation.

What This Means for Everyone Still Using One Platform

The person most affected by these failure modes isn’t the enterprise customer with a dedicated support channel and a multi-vendor strategy already in place. It’s the individual on a $20 subscription who uses one AI platform for everything: writing, research, coding, brainstorming, analysis. When that one platform goes down, they’re done. When context rots, they start over. When corrections don’t persist, they repeat themselves. When they hit a usage limit with no visibility, they wait.

That person doesn’t have API access. Doesn’t have the technical knowledge to route around a consumer-layer failure. Doesn’t have a second or third platform configured as failover. Doesn’t have persistent memory architecture that survives session resets. They have one login and one interface, and when it breaks, they have nothing.

The data from April 15 suggests this isn’t an edge case. It’s the default experience for the majority of AI users. The incident frequency across major platforms in early 2026 indicates that outages are a regular operational condition, not a rare anomaly. Independent analysis has explicitly called this an infrastructure crisis, and the cascade pattern means no single platform can serve as a reliable sole provider.

I’m not going to pretend I have a clean solution to offer here. What I have is a documented day of evidence showing exactly how these systems fail, how the failures compound across competing platforms, and what the experience looks like from the operator’s chair rather than the press release. The measurement frameworks I’ve developed over five weeks of sustained testing can quantify correction decay, identity drift, and context degradation across platforms. The findings are reproducible. I’ve run them repeatedly.

But I’ll be honest about one thing I haven’t fully resolved: whether the persistence problem (corrections decaying, context resetting, identity drifting) is solvable within the current platform architectures at all, or whether it requires something fundamentally different at the infrastructure layer. The evidence I’ve gathered points toward the latter, but I’m not certain enough to state it as a conclusion. That uncertainty is where this research sits right now, and I’d rather leave the question open than pretend I’ve answered it.

The platforms will keep growing. The outages will keep happening. The cascade pattern will keep compounding. The correction tax will keep accumulating. And the person most affected will continue to be the one with the fewest options. Whether that changes depends on what gets built next, and who builds it.