Anthropic (Aug-Sep 2025): three bugs degrade Claude

01 · CONTEXT

One model on several platforms

Between August and early September, three infrastructure bugs intermittently degraded the quality of Claude's responses. The company states that it never reduces model quality due to demand, time of day, or server load, and attributes what users reported solely to infrastructure bugs.

Claude is served through the first-party API, Amazon Bedrock, and Google Cloud's Vertex AI, and runs on Trainium, NVIDIA GPUs, and TPUs. Each platform has its own characteristics and optimizations, but the goal is for users to receive responses of the same quality regardless of which platform serves the request.

1. Claude reaches users through the first-party API and also through Amazon Bedrock and Google Cloud's Vertex AI.

2. The same models run on Trainium, NVIDIA GPUs, and TPUs, each with its own characteristics and optimizations.

3. A routing layer directs each request to the appropriate set of servers. The design is a simplification, but this is the layer where the first bug will appear.

02 · TIMELINE

Three overlapping bugs, a single symptom

The first bug appeared on August 5 and affected about 0.8% of requests to Sonnet 4. Two others came from deployments on August 25 and 26. On August 29, a change to load balancing began to increase the affected traffic. The status page described the first issue as affecting a small share of Sonnet 4 requests, from Aug 5 to Sep 4, with increasing impact from Aug 29.

03 · ROUTING BUG

Load balancing and sticky routing

On August 5, some Sonnet 4 requests were routed to servers configured for the upcoming 1M-token context window, and at first this affected 0.8% of requests. On August 29, a routine change to load balancing unintentionally increased the number of short-context requests sent to those servers. At the worst hour, on August 31, 16% of Sonnet 4 requests were affected.

Routing was sticky: once a request was served by the wrong server, subsequent messages tended to land on the same server. About 30% of Claude Code users who made requests in the period had at least one message routed to the wrong type of server.

1. A short-context request should be directed to the set of short-context servers.

2. A routing error sent some short requests to the servers configured for long context.

3. A routine load balancing change, on August 29, unintentionally increased the number of short requests sent to the long-context servers.

4. Because routing was sticky, anyone who landed on the wrong server tended to stay on it in subsequent messages.

5. The fix made short and long requests return to the correct sets of servers.

04 · OUTPUT AND TOP-K

Numerical precision and the TPU compiler

On August 25, a misconfiguration on the API's TPU servers caused an error in token generation. A runtime performance optimization sometimes assigned high probability to tokens that should have been rare, such as Thai or Chinese characters in responses to English prompts, or obvious syntax errors in code. The change was rolled back on September 2, and the company added tests to detect unexpected characters to the deployment process.

The third bug came from a change to the token selection code, which triggered a latent bug in the XLA:TPU compiler. It was confirmed for Haiku 3.5, and the company believes it may have affected some of Sonnet 4 and Opus 3 on the API. Third-party platforms were not affected.

To understand the mechanism: Claude computes probabilities for each possible next word and draws a sample from that distribution, considering only the words whose cumulative probability reaches a threshold (top-p). The models are partitioned across dozens of chips or more, and sorting those probabilities is a distributed sort.

1. At each token, the model computes probabilities for the possible next words and the sampling step draws one of them.

2. Top-p restricts the draw to the words whose cumulative probability reaches a threshold, avoiding nonsensical outputs.

3. The compiler can convert operations to higher precision, and operations that should agree on the most likely token were running at different precision levels.

4. Approximate top-k, used for performance, sometimes returned wrong results and could drop the most likely token, only for certain batch sizes and configurations.

5. The fix replaced approximate top-k with exact top-k and standardized other operations at higher precision, accepting a small efficiency cost.

In December 2024, the team had seen the TPU implementation sometimes drop the most likely token at temperature zero and applied a workaround. On August 26, a rewrite of the sampling code to fix the precision problems removed that workaround, since the root cause was believed to be resolved. The workaround had been masking the deeper approximate top-k bug.

The rollback of the top-k bug came per model: Haiku 3.5 was rolled back on September 4 and Opus 3, after consistent reports, on September 12. Sonnet 4 was also rolled back as a precaution, although the company could not reproduce the bug in it.

05 · DETECTION AND CHANGES

Why it took so long to see the problem

Validation usually combined benchmarks, safety evaluations, and performance metrics, plus manual checks and deployment to small canary groups. Even so, the evaluations did not catch the reported degradation, partly because Claude often recovers well from isolated mistakes, and each bug produced different symptoms on different platforms and at different rates.

Internal privacy and security controls limit engineers' access to interactions not reported as feedback. The company admits it relied too heavily on noisy evaluations and had no clear way to link the reports to recent changes.