My reflex on elevated error rates is retry with backoff, and that reflex is what turns this into an accounting problem. Claude's paid plans do not sell unlimited use. According to dev.to, they meter against a rolling five-hour window and a weekly cap [8], and during overload a request can draw down that allowance and then fail anyway [9]. If that is how the meter works, your retry policy is your spend policy, and the failure is silent: nothing in the error tells the client that the attempt was already charged.
The only number anyone has put on the loss is a single forum post. On 24 August a poster on r/ClaudeAI titled a thread "23% of 5-hour limit for 'server is busy'" and wrote that three prompts had left them waiting four more hours [10]. Take the figure at face value and it works out at roughly 7.7 percent of the window per attempt, so about thirteen such attempts would clear the allowance [15]. Dev.to says plainly that it cannot audit any individual meter and presents these as user reports rather than measurements [12]. That 23 percent is one person's arithmetic on one window, a data point rather than a rate you can plan against.
The status history as quoted names 3, 4, 5, 12, 13, 14 (twice), 16, 17, 18, 19 and 20 August, plus the still-open incident on the 24th [7][3]. That is thirteen incidents on twelve dates, leaving roughly seven of the twenty counted unlisted [14]. Exactly one entry carries a duration: the 5 August degradation that ran for the best part of a working day [7]. No availability figure comes out of that, and anyone quoting a nines number off this history is guessing.
The component list on the open incident is the part worth designing around. Anthropic listed claude.ai, the Claude API, Claude Code and Claude Cowork [6]. Moving from the web app to the CLI amounts to nothing when one incident names both. In-vendor redundancy buys nothing against a fault that spans surfaces; a second model provider does, and so does a path that degrades to no model at all.
Whether an hour of this costs you anything depends on the shape of your workload. Supervised interactive use absorbs elevated errors as irritation. An unattended agent loop with generous retries converts the same hour into quota, if the metering behaves the way dev.to describes [9]. That is the test to apply before importing someone else's outage month into your own risk register.
Credit where it is due. Beginning to investigate at 05:06 UTC and naming Mythos 5, Fable 5 and Opus 5 as affected within the hour is competent incident work [4][5], and dev.to notes that a granular public status page is more disclosure than much of the industry offers [13]. A page you open to find out whether the tool in front of you is broken is a strange dependency, and it is also the only primary source in this story. The decision the evidence forces is about retry caps and a second path, not about vendor loyalty: if the metering account holds, the retries you added for reliability are the line item an incident-a-day month bills you for [1][9].
