A few sentences apart in one postmortem, Anthropic put the same bug at 0.8 percent of requests and at 30 percent of Claude Code users. Both numbers are true. They count different things, and only one of them measures what the developers who complained were living through.
On September 17, 2025, Anthropic published "A postmortem of three recent issues", its account of three bugs that had been degrading Claude's answers on and off for about a month. The first bug gets two numbers, a few sentences apart. "This bug initially affected 0.8% of requests." Then: "Approximately 30% of Claude Code users who made requests during this period had at least one message routed to the wrong server type."
Read quickly, the second sentence looks like a correction of the first, or like a different bug. It is neither. The first number counts requests and the second counts people, and the distance between them is the story of August as its heaviest users lived it. A fault can look small on a dashboard and still reach most of the people who notice anything, because the people who notice are the ones who use the product most. A heavy user samples a fault in proportion to their use.
This essay follows one hypothetical developer through that month, then asks what a per-user number would have shown in the week the complaints began.
The postmortem describes three faults that overlapped in late August.
A routing error. "On August 5, some Sonnet 4 requests were misrouted to servers configured for the upcoming 1M token context window." That was the 0.8 percent. "On August 29, a routine load balancing change unintentionally increased the number of short-context requests routed to the 1M context servers," and "At the worst impacted hour on August 31, 16% of Sonnet 4 requests were affected." The other platforms that serve Claude saw far less: on Amazon Bedrock, misrouted traffic "peaked at 0.18% of all Sonnet 4 requests from August 12", and on Google Cloud's Vertex AI it "affected less than 0.0004% of requests" between August 27 and September 16. The fix went out on September 4. One more sentence matters more than any of the rates: "our routing is 'sticky'. This meant that once a request was served by the incorrect server, subsequent follow-ups were likely to be served by the same incorrect server."
Output corruption. "On August 25, we deployed a misconfiguration to the Claude API TPU servers that caused an error during token generation." It hit Opus 4.1 and Opus 4 from August 25 to 28, and Sonnet 4 from August 25 to September 2. This is the bug with the memorable symptom: "A small subset of users that asked a question in English might have seen 'สวัสดี' in the middle of the response." That is Thai for hello.
A compiler bug. Also on August 25, a change to how Claude selects tokens "inadvertently triggered a latent bug in the XLA:TPU compiler, which has been confirmed to affect requests to Claude Haiku 3.5." The models compute next-token probabilities in bf16, but the TPU's vector processor is fp32-native, and the compiler converts some operations to fp32: "operations that should have agreed on the highest probability token were running at different precision levels." A workaround from the previous December "had been inadvertently masking this problem." Anthropic rolled the change back for Haiku 3.5 on September 4, and on September 12 for Opus 3 after "user reports of problems with Opus 3 that were compatible with this bug". The fix: "We switched from approximate to exact top-k and standardized some additional operations on fp32 precision. Model quality is non-negotiable, so we accepted the minor efficiency impact."
The postmortem is just as candid about why detection took weeks. "The evaluations we ran simply didn't capture the degradation users were reporting, in part because Claude often recovers well from isolated mistakes." Engineers could not simply read the conversations: "Our internal privacy and security controls limit how and when engineers can access user interactions with Claude, in particular when those interactions are not reported to us as feedback." The three bugs produced "a confusing mix of reports that didn't point to any single cause." And "When negative reports spiked on August 29, we didn't immediately make the connection to an otherwise standard load balancing change."
Take one developer using Claude Code in the first three weeks of August, while the routing bug sat at its initial rate. Say they send 300 requests to the model in a week. That is an assumption, not a measurement, but it is not an extravagant one for agentic work: every tool result a coding agent hands back to the model is another request. What is the chance that at least one of those 300 landed on the wrong servers?
If every request is an independent draw, the chance of getting through clean is 0.992 multiplied by itself 300 times, about 9 percent. So the chance of at least one misrouted request is 1 − 0.992^300, which is 91 percent. The expected number of bad replies in that week is 300 × 0.008 = 2.4.
The same formula gives 55 percent at 100 requests a week, and at 45 requests a week the chance of at least one hit passes 30 percent.
Nine in ten developers who send 300 requests would meet a bug that a per-request count puts at under one percent. The count is not wrong. It answers a question none of those developers is asking.
Independence is only one model, though, and Anthropic's own sentence about stickiness says it is the wrong one. Once a request landed on a 1M-context server, its follow-ups tended to land there too. So the misrouted 0.8 percent of requests arrived in runs rather than one at a time, and for a fixed share of bad requests, runs change who sees them:
Stickiness trades breadth for depth. Fewer people are hit, and each person who is hit gets several bad answers in a row, in one conversation, on one task.
The postmortem does not give the three numbers that would settle where the truth lies:
Its 30 percent covers every Claude Code user, light and heavy, across the whole month, including the week the rate climbed. So it cannot be read back into this one developer's odds. For this developer the defensible band is wide, from about one in five to about nine in ten. But every point in that band is 27 to 114 times the 0.8 percent on the dashboard.
Note the phrase "isolated mistakes." An evaluation that sends a prompt, scores the answer and moves on is sampling requests, and a single bad answer in a long session is something both Claude and a patient developer can recover from. A stuck run is different. When five answers in a row come back subtly worse, in the middle of real work, people stop calling it noise. The complaints The Decoder collected from Reddit, X and YouTube in late August sound like runs: Claude had become "significantly dumber… ignored its own plan and messed up the code", and would "lie about the changes it made to code". The evaluations saw isolated requests, but the developers were living through runs of them.
None of this arithmetic is new. What is new is the kind of fault it is being applied to. Other fields met the same gap between a per-event rate and a per-person experience, and each one ended up putting the second number in front of the people who have to live with it.
Hydrology. A "100-year flood" is a flood with a 1 percent chance of happening in any given year. The name suggests a once-a-century event, so the U.S. Geological Survey spells out the other number: "during the span of a 30-year mortgage, a home in the 1-percent AEP (100-year) floodplain has a 26-percent chance of being flooded at least once during those 30 years". The calculation is 1 − 0.99^30, the same formula as our developer's week. A homeowner doesn't live through one year. They live through all thirty years of the loan.
Distributed systems. In "The Tail at Scale" (Communications of the ACM, February 2013), Jeffrey Dean and Luiz André Barroso consider servers that each answer in about 10 milliseconds but take a full second one time in a hundred. For a single request, a slow response is a one-in-a-hundred event. "If a user request must collect responses from 100 such servers in parallel, then 63% of user requests will take more than one second". Here the multiplier is fan-out inside a single request rather than use across a week. The algebra is identical: 1 − 0.99^100.
Latency measurement. Gil Tene's 2015 Strange Loop talk, "How NOT to Measure Latency", made the same point about percentiles, and Tyler Treat's summary puts it in one line. Treat's example session is "five page loads, averaging 40 resources per page", about 200 requests in all. With that many draws, "How many users will not experience something worse than the 95th percentile? 0.003%." A percentile describes requests, and a user's experience is a whole session of them.
The three fields share one habit. They kept the per-event rate, because engineers need it, and they added a per-exposure number (per mortgage, per user request, per session), because that is what a person actually experiences. Serving a large language model has the same algebra, with two new wrinkles: the fault is a wrong answer rather than a slow one, so no timer catches it, and the multiplier is a person's working week.
One point of fairness first. The postmortem gives no sign that anyone was watching a misroute rate in August. Nobody yet knew those servers were answering worse, and its 0.8, 16 and 30 percent read as measurements made afterwards. So the useful question is not why nobody watched the misroute line. It is what unit the lines that did exist were drawn in.
The complaints did not wait for the spike. The postmortem's own timeline begins: "In early August, a number of users began reporting degraded responses from Claude." Of the three bugs, only the routing error was live then, at its initial 0.8 percent: that is the week the complaints began. By late August, "the increasing frequency and persistence of these reports prompted us to open an investigation". The spike came on August 29, the day the load-balancing change went out, and nobody connected the two at first. By the worst hour, on August 31, 16 percent of Sonnet 4 requests were going to the wrong servers. Run the developer's arithmetic on that hour:
The users registered the change on the day it went out. Connecting their reports to it took longer.
The last step of the case is the practical one. Two counts would have shown the problem in the unit the users were living it in, and neither needs anyone to know in advance that answers are worse.
Neither count needs anyone to read a conversation. Both come from routing logs, which record which kind of server handled which account's request, so the privacy controls that slowed the investigation do not block them. And the postmortem shows the logs can be joined this way: the 30 percent it published is the first count, taken over the whole month.
Set the two lines side by side for August 5 to 28. The request line reads 0.8 percent. The user line, for developers at our 300-request pace, reads somewhere between one in five and nine in ten, depending on how long the stuck runs were. A team watching the first line sees a rounding error. A team watching the second sees a routing fault touching a large share of its heaviest users, and it goes looking three weeks before the spike.
There is evidence the gap outlived this incident. On April 23, 2026, Anthropic published a second postmortem, "An update on recent Claude Code quality reports". It covered a change to Claude Code's default reasoning effort on March 4, a change on March 26 that cleared older thinking from sessions, and a verbosity instruction added on April 16, after which one evaluation "showed a 3% drop for both Opus 4.6 and 4.7". Its detection sentence echoes the first: "neither our internal usage nor evals initially reproduced the issues identified". And again it gave no share-of-users figure. Both reports are unusually frank about what went wrong. Neither one reports its faults in the unit that its users experienced them in.
The method is already in the first postmortem, in the 30 percent it calculated after the fact. The change is to calculate it before the complaints do. For any fault rate p you measure per request, take the number of requests n that your heaviest users send in a week, and put 1 − (1 − p)^n on the same chart. If your system can stick a user to a bad path, add their longest run next to it. When the second line is tens of times the first, as it was in August, the users who say the product got worse are not being dramatic. They have more exposure to the fault than anyone else.
The per-user line in this essay comes from a per-request record: which account sent the request, and which path served it. Chain of Consciousness keeps a tamper-evident, dated record of what your own AI agents did, so a question like “how many users hit this at least once, and for how long?” can be answered from the record rather than reconstructed after the complaints arrive.
pip install chain-of-consciousness npm install chain-of-consciousness
Or start without installing anything: Hosted Chain of Consciousness.