Skip to main content
Back to Blog
AI/MLProduct DevelopmentDevOps
16 August 20267 min readUpdated 24 August 2026

Anthropic explains recent Claude Code quality issues

Anthropic identified three separate changes behind recent reports that Claude’s responses had worsened for some users. The issues affected Claude Code, the Claude Agent SDK, and...

By Software Development Team

Anthropic identified three separate changes behind recent reports that Claude’s responses had worsened for some users. The issues affected Claude Code, the Claude Agent SDK, and Claude Cowork. The API and inference layer were not affected.

All three issues had been resolved by April 20, with the release of Claude Code v2.1.116. The company also announced that usage limits would be reset for all subscribers on April 23.

Three separate changes

The reported degradation resulted from three changes that affected different portions of traffic and rolled out on different schedules:

  1. Default reasoning effort: On March 4, Claude Code’s default reasoning effort changed from high to medium. The change was intended to reduce very long delays that could make the interface appear frozen. Anthropic reverted it on April 7 after users said they preferred higher intelligence by default and the option to choose lower effort for simpler tasks. The change affected Sonnet 4.6 and Opus 4.6.
  2. Reasoning-history caching: On March 26, Claude Code began clearing older thinking from sessions idle for more than an hour. A bug caused the clearing to happen on every subsequent turn instead of only once, making Claude appear forgetful and repetitive. Anthropic fixed the issue on April 10 in v2.1.101. It affected Sonnet 4.6 and Opus 4.6.
  3. Verbosity reduction: On April 16, Anthropic added a system-prompt instruction intended to reduce verbosity. Combined with other prompt changes, it reduced coding quality and was reverted on April 20. The change affected Sonnet 4.6, Opus 4.6, and Opus 4.7.

Because the changes affected different traffic segments at different times, their combined effect appeared to be broad and inconsistent degradation. Reports began in early March, but initially they were difficult to distinguish from normal variation in user feedback. Internal usage data and evaluations also did not reproduce the identified issues at first.

Claude Code’s default reasoning effort

When Opus 4.6 became available in Claude Code in February, the default reasoning effort was set to high. Users soon reported that high-effort reasoning could sometimes take long enough for the interface to appear frozen, while also producing unusually high latency and token usage.

In general, additional reasoning can improve output quality, but it also increases latency and usage. Claude Code’s effort settings allow users to choose that tradeoff. Anthropic evaluates different points on this test-time-compute curve, selects a default in the product, and exposes other options through /effort. The selected value is sent to the Messages API as the effort parameter.

Internal evaluations found that medium effort produced slightly lower intelligence but significantly lower latency for most tasks. It also avoided some very long reasoning delays and helped users make better use of their limits. Anthropic therefore made medium the default and explained the decision through an in-product dialog.

Users soon reported that Claude Code felt less intelligent. Anthropic introduced several interface changes, including startup notices, an inline effort selector, and the return of ultrathink, to make the setting easier to change. Most users nevertheless continued using the medium default.

Anthropic reversed the decision on April 7. Opus 4.7 now defaults to xhigh effort, while all other models default to high.

A caching bug that removed earlier reasoning

Claude normally retains its reasoning in the conversation history. This allows it to refer to the rationale behind earlier edits and tool calls on subsequent turns.

On March 26, Anthropic introduced an optimization intended to make it less expensive and faster to resume sessions that had been idle for more than an hour. The design used prompt caching and the clear_thinking_20251015 API header with keep:1. Because an idle session would already result in a cache miss, older thinking sections could be removed from the request to reduce the number of uncached tokens. Full reasoning history would then be sent again on later requests.

A bug caused the system to clear thinking history on every turn for the rest of the session. Once a session crossed the idle threshold, each request kept only the newest reasoning block and discarded earlier blocks. If a user sent a follow-up while Claude was using a tool, the current turn’s reasoning could also be discarded.

Claude continued executing tasks, but with progressively less context about the reasons behind its actions. This led to reports of forgetfulness, repetition, and unusual tool choices. Since the repeated removal of thinking blocks also caused subsequent requests to miss the cache, Anthropic believes the bug contributed to reports that usage limits were being consumed faster than expected.

Two unrelated experiments initially made the issue difficult to reproduce: an internal server-side experiment involving message queuing, and a separate change in how thinking was displayed, which hid the bug in most command-line sessions.

The problem involved Claude Code’s context management, the Anthropic API, and extended thinking. It passed human and automated code reviews, unit tests, end-to-end tests, automated verification, and internal use. The issue was limited to a corner case involving stale sessions and was difficult to reproduce, so identifying and confirming the root cause took more than a week.

As part of the investigation, Anthropic back-tested Code Review against the pull requests containing the bug using Opus 4.7. When given the repositories required for full context, Opus 4.7 found the problem, while Opus 4.6 did not. Anthropic is adding support for additional repositories as Code Review context.

The bug was fixed on April 10 in v2.1.101.

A system prompt change intended to reduce verbosity

Compared with its predecessor, Claude Opus 4.7 tends to produce more verbose responses. This behavior can improve performance on difficult problems, but it also generates more output tokens.

In preparation for the Opus 4.7 release, Anthropic tuned Claude Code using model training, prompting, and changes to the product’s thinking interface. One system-prompt addition had a larger-than-expected effect on coding intelligence:

“Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”

After several weeks of internal testing without regressions in the evaluations being used at the time, Anthropic shipped the change with Opus 4.7 on April 16.

During the investigation, Anthropic ran broader evaluations and performed ablation tests, removing individual system-prompt lines to measure their effects. One evaluation showed a 3% decline for both Opus 4.6 and Opus 4.7. The prompt change was reverted in the April 20 release.

Changes to the development process

Anthropic plans to increase the number of internal staff using the exact public Claude Code build rather than a version that includes experimental features. It also plans to improve the Code Review tool used internally and provide the improved version to customers.

The company is adding stricter controls for Claude Code system-prompt changes. Each change will receive a broad set of per-model evaluations, and ablation testing will continue to measure the effect of individual prompt lines. New tooling has also been introduced to make prompt changes easier to review and audit.

Additional guidance in CLAUDE.md requires model-specific changes to be restricted to the models they target. Changes that could reduce intelligence will receive soak periods, broader evaluation coverage, and gradual rollouts.

Anthropic also plans to share more detailed product updates through @ClaudeDevs on X and centralized GitHub threads. User feedback, including reports submitted with /feedback and specific reproducible examples, helped identify and fix the issues.