Claude goes down again, with errors across models

In the early hours of Monday 24 August Claude started returning errors again, and not on a single model: Notebookcheck reports another service outage with failures that reached several models at once. That detail is what matters if you run the API in production. An isolated incident can be dodged by switching models inside the same family, but one that hits several of them cancels out the plan B almost everyone has written into their code.

The heaviest word in the story is not outage, it is another. Inference platform downtime has stopped being an exceptional event and has become a design parameter, much like latency or cost per million tokens. Anthropic publishes service status at status.anthropic.com, but that page tells you what is already broken, not what your system will do when it happens.

What actually breaks

In the chat interface an outage means an error message and a manual retry. In an automated system the effect is different. Unsupervised agents, Claude Code hooks firing model calls on PostToolUse, subagents launched in parallel and MCP servers bridging to external tools all share the same single point of failure. When the API returns 429 or 529 for a sustained period, the result is rarely a clean error: it is retries that resend the whole context, token budgets that evaporate and half finished tasks that leave files written, branches open and no commit.

Why model fallback falls short

The most common pattern chains models by cost: Opus 4.8 for the hard parts, Sonnet 4.6 for the bulk of the work and Haiku 4.5 for the mechanical bits. It helps against a specific model being saturated and does nothing when the problem sits underneath, in the shared routing or serving layer. A fallback that only swaps the model identifier inside the same provider is, in practice, a fallback inside the same failure domain. If the incident reaches several models at once, as the report describes, the whole chain goes down together.

Who this matters to

Three profiles above all. First, teams that have put Claude Code into CI and run agents in unattended pipelines, where a failure at three in the morning goes unnoticed until the build blows up. Second, products with the model on the critical path of a user facing feature. Third, anyone who has built internal automation on top of MCP servers and treats it as infrastructure without having given it infrastructure grade defences yet.

A short list to review this week

1. Retries with exponential backoff and jitter, with a maximum attempt count and a bounded total time. Retrying without brakes turns ten minutes of downtime into an invoice.
2. Idempotent tools. If the agent repeats an MCP call that creates a record or sends an email, the second run has to be harmless.
3. A circuit breaker per provider. After several consecutive failures, stop pushing and queue instead of hammering the same door.
4. Separate interactive work from deferred work. Batch jobs can wait in a queue, a user request cannot.
5. Explicit degradation in the product. A clear message saying the model is unavailable beats an endless spinner.
6. Your own error rate and latency metrics. The provider status page usually lags behind what your own chart is already showing.

Our take

None of this is new to anyone who has integrated payment gateways or messaging providers, and that is the heart of it: the model is now one more critical dependency and deserves the same defensive treatment. After similar episodes, the sensible move is to write the degraded path now, while the service is up, rather than improvising it during the next incident.