Three Bugs Degraded Claude, and Monitoring Never Caught It

In August 2025, Claude users began widely complaining that the model had gotten worse—answers going off track, obvious syntax errors in code, and even Thai characters mixed into English responses. Anthropic's postmortem report, published on September 17, confirmed this feedback: three independent infrastructure bugs degraded Claude's response quality between August and early September. The service never went down, there was no attack, but at its worst (a single hour on August 31), 16% of Sonnet 4 requests were affected—and every check that should have caught this kind of problem passed.

This postmortem revolves almost entirely around routing, server configuration, and compilers. It is a textbook case of the gap between "the service is online" and "the service is correct."

How the Three Bugs Unfolded

Bug One: Requests Sent to the Wrong Servers

On August 5, some Sonnet 4 requests began to be "misrouted to servers configured for an upcoming 1-million-token context window." Initially about 0.8% of Sonnet 4 requests were affected—small enough to look like noise.

On August 29, "a routine load-balancing change inadvertently increased the number of short-context requests being routed to the 1M-context servers." By the worst hour on August 31, 16% of Sonnet 4 requests were affected.

Routing is sticky—"once a request was handled by the wrong server, follow-up turns were also likely to be handled by the same wrong server." This meant some users repeatedly received degraded responses.

The most easily misread figure is: "about 30% of Claude Code users had at least one message routed to the wrong server type during that period." That is the share of users, not the share of requests, and it cannot be added to the 16%—the latter is the share of Sonnet 4 requests in a single hour. The report does not give totals for affected users or requests overall.

Third-party platforms were affected far less: on Amazon Bedrock, misrouted traffic peaked at 0.18% of all Sonnet 4 requests; on Google Vertex AI, fewer than 0.0004% of requests were affected between August 27 and September 16. The fix was deployed on September 4 and fully rolled out by September 18.

Bug Two: The Wrong Tokens

The second bug was "a configuration error in the TPU servers serving the Claude API that caused errors during token generation." The model generates responses token by token, and a runtime performance optimization "occasionally assigned high probability to tokens that should have been very rare."

The result was English prompts getting Thai or Chinese responses, along with obvious syntax errors in code. The issue affected Opus 4.1 and Opus 4 from August 25 to 28, and Sonnet 4 until a rollback on September 2.

Third-party platforms were unaffected. Anthropic has since "added detection tests for anomalous character output to the deployment pipeline."

top-k sampling and approximate algorithms: At each generation step, a language model computes a probability for every token in the vocabulary. Top-k sampling is a decoding strategy that keeps only the k highest-probability candidates and then samples from them according to probability (at temperature zero it degenerates to taking the highest-probability token, i.e., greedy decoding). On accelerators such as TPUs, exactly sorting the full vocabulary is expensive, so approximate top-k algorithms (such as fast selection based on thresholds or bucketing) are often used to reduce latency. The risk of approximate algorithms is that they agree with exact sorting on the vast majority of inputs, but under specific batch sizes, numerical distributions, or compiler optimizations they may return the wrong candidate set—for example, discarding the token that should have had the highest probability, or incorrectly assigning high probability to a low-probability token. This is precisely the technical root of "English prompts getting Thai responses" in Bug Two and "the same prompt working sometimes and failing other times" in Bug Three.

Bug Three: The Hidden Defect in the Compiler

When selecting the next token, the model ranks candidates by probability, using approximate top-k on TPUs—a faster shortcut.

In December 2024, Anthropic found that its "TPU implementation occasionally discarded the most likely token at temperature zero" and deployed a temporary workaround. In August 2025, they deployed code that improved the token-selection logic, and "the fix removed the December workaround because we believed we had addressed the root cause."

This change "inadvertently triggered a latent bug in the XLA:TPU compiler." The approximate algorithm "sometimes returned completely wrong results, but only at specific batch sizes and model configurations." "The December workaround had been unintentionally masking the problem." And "the same prompt might work one time and fail the next."

The issue was confirmed on Haiku 3.5 and rolled back on September 4. Anthropic believes it "may have affected some Sonnet 4 and Opus 3 requests on the Claude API." Opus 3 was rolled back on September 12. On Sonnet 4, "the bug could not be reproduced, but it was rolled back as a precaution." The final fix was to abandon the shortcut, switch to exact top-k, and standardize some operations to fp32—"model quality is non-negotiable, and we accepted a slight efficiency loss."

TPUs and the XLA compiler: A TPU (Tensor Processing Unit) is an accelerator chip designed by Google specifically for neural-network computation, and Claude models run inference on TPU clusters. XLA (Accelerated Linear Algebra) is a deep-learning compiler developed by Google that compiles and optimizes model computation graphs into TPU-executable code. During optimization, the compiler performs transformations such as operator fusion and memory-layout adjustments, some of which can introduce subtle numerical differences that have no effect in the vast majority of cases but may surface as incorrect results at specific batch sizes or model configurations. Such "compiler bugs" are usually extremely difficult to troubleshoot because they are not in the model code or inference framework and often depend on the specific shapes and hardware state at runtime, manifesting as intermittent, non-reproducible failures. Anthropic ultimately standardized some operations to fp32 (32-bit floating point) precisely to avoid the compiler's uncertainty on low-precision approximate paths, trading an acceptable performance loss for numerical stability.

Why It Took Weeks to Detect

Anthropic gave four reasons.

The checks passed. The validation pipeline relies on benchmarks, safety evaluations, and performance metrics; engineering teams do spot checks and first deploy to small canary groups. But the evaluations "simply did not catch the degradation users were reporting, partly because Claude often recovers well from isolated errors."

The symptoms overlapped. Each bug produced different symptoms at different frequencies on different platforms, and together they "looked like random, inconsistent degradation."

The timing obscured the cause. "When negative feedback surged on August 29, we did not immediately connect it to a routine load-balancing change."

The door was closed. Internal privacy and security controls limited how and when engineers could access user interactions, especially interactions that were not reported as feedback. This protected user privacy, but it also prevented engineers from examining the problematic conversations needed to identify or reproduce the bugs.

This control is correct in itself. And precisely because of it, the users held the evidence—Anthropic says user reports "all helped us locate the problems."

The limits of canary releases and quality evaluation: A canary deployment pushes a new change to a very small fraction of real traffic first, then gradually expands once metrics look normal. It effectively catches hard failures such as crashes, latency spikes, and rising error rates, but it is not sensitive to soft degradation like "a slight drop in answer quality"—because quality evaluation usually relies on benchmark sets and automated scoring, and the distribution of benchmark questions differs from real user requests. The model also has some ability to recover from isolated errors, which dilutes fluctuations in end-to-end quality metrics. In addition, when multiple independent bugs coexist, their symptoms cancel out or blur together in aggregate metrics, further reducing the chance of detection during the canary stage. This explains why all three bugs passed the validation pipeline and were only taken seriously after large-scale user feedback.

Anthropic's Clear Statement

The postmortem opens with:

"To be blunt: we never degrade model quality due to demand, time of day, or server load. The problems users reported stemmed entirely from infrastructure bugs."

This is Anthropic's statement, and the report itself is the evidence it provides.

What Changed

Anthropic made three commitments: more sensitive evaluations that can distinguish a normal implementation from a faulty one; running quality evaluations in more places, which "will run continuously on real production systems"; and faster debugging tools so it can "better debug community feedback without compromising user privacy."

It also encourages users to keep reporting issues via the /bug command in Claude Code or the thumbs-down button in the app.

Four Lessons for Infrastructure Teams

Online does not mean correct. None of these three bugs stopped the service from responding. If monitoring only tests whether the system answers and not whether the answer is correct, quality failures are invisible to it.

Small changes compound. A routine load-balancing change amplified a bug affecting about 0.8% of requests to 16% in the worst hour. Before declaring a new change clean, first understand what was already broken.

Workarounds mask problems. Removing one may expose what it has been quietly covering up. Treat removing a workaround itself as a separate change.

Decide in advance how to investigate failures you are not authorized to see. The privacy door should stay, but the consent channel and the accompanying tools must exist before the day you need them.

One-line Summary

Anthropic's postmortem shows how three infrastructure bugs quietly degraded Claude—and why online does not mean correct.

Paragraph Summary

From August to early September 2025, Claude users widely reported that the model had gotten worse. Anthropic's postmortem confirmed that three independent infrastructure bugs degraded response quality: requests misrouted to servers configured for a 1M-token context (up to 16% of Sonnet 4 requests at worst), a TPU misconfiguration causing token-generation errors (Thai mixed into English responses, code syntax errors), and a latent XLA compiler bug triggered after removing a workaround (the same prompt working inconsistently). The service never went down and all validation checks passed; the problems took weeks to detect because evaluations missed the degradation, symptoms overlapped, timing was misleading, and privacy controls limited access. Anthropic committed to better evaluations and debugging tools and stressed that it never degrades model quality due to load.