// blog/claude-code-quality-issues-what-happened
Claude Code Quality Issues: What Happened
Claude Code quality reports in April 2026 had three distinct causes: a lower default reasoning effort, a session-context bug that discarded prior reasoning, and a system-prompt constraint that reduced coding quality. Anthropic resolved all three by April 20 in Claude Code v2.1.116, while the underlying API and inference layer were unaffected. The company’s April 23 postmortem is useful because it separates model behavior from the product-layer choices that shape how a model behaves in an agent loop.
That distinction matters for anyone evaluating coding agents. “The model got worse” can describe several very different failures: less test-time compute, incomplete context, a bad harness instruction, or an actual model-serving issue. These reports involved the first three.
Why did Claude Code seem less capable?
The reports looked broad and inconsistent because each issue affected a different part of Claude Code traffic, on a different schedule.
| Change | Date shipped | User-visible effect | Fixed |
|---|---|---|---|
| Default reasoning effort changed from high to medium | March 4 | Less capable responses for users who remained on the new default | April 7 |
| Idle-session thinking cleanup bug | March 26 | Forgetfulness, repetition, odd tool choices, faster usage-limit drain | April 10 |
| System prompt verbosity constraint | April 16 | Lower coding quality for affected models | April 20 |
The first change was intentional, the second was an implementation bug, and the third was a prompt-level tuning decision with an unintended quality cost. Grouping all three together as “degradation” was understandable from the user’s side, but it obscured the mechanics needed to diagnose each problem.
Anthropic says it began investigating feedback in early March, but its internal usage data and evaluations did not initially reproduce the reported issues. That is a common problem in agent products. An internal evaluation can hold task, context, timing, and tool state steady. Real sessions include interrupted work, resumed sessions, arbitrary repositories, and people making several follow-up requests while the agent is already using tools.
A coding agent is a system around a model. The model matters, but the effort setting, context construction, cache behavior, prompt instructions, tool loop, and user interface all affect the output a person experiences.
How does Claude Code reasoning effort affect quality?
Claude Code exposes reasoning effort as a tradeoff between more thinking, lower latency, and fewer usage-limit hits. In the product layer, the selected effort is sent to the Messages API as an effort parameter; users can choose alternatives with /effort.
When Anthropic released Opus 4.6 in Claude Code in February, it set the default reasoning effort to high. Some users then experienced sufficiently long thinking periods that the interface appeared frozen. Anthropic changed the default from high to medium on March 4 for Sonnet 4.6 and Opus 4.6.
Its internal testing found that medium effort had slightly lower intelligence and substantially lower latency on most tasks. It also avoided some long-tail thinking latency and conserved users’ limits. Those are sensible product considerations, especially for short tasks where an agent’s additional reasoning has little practical value.
The problem was the default: longer thinking generally produces better output. A user who expects a coding agent to reason through a difficult change often values that quality margin more than a lower average response time.
Anthropic added several interface changes to make the selected effort more visible: startup notices, an inline effort selector, and the return of ultrathink. Most users still stayed on the medium default. Following customer feedback, Anthropic restored a higher default on April 7:
| Model | Current default effort described in the postmortem |
|---|---|
| Opus 4.7 | xhigh |
| All other models | high |
This is a product-design lesson more than a model-quality lesson. An advanced control does little for users if the default remains sticky and the cost of discovering the control arrives after they have already concluded the tool is weaker.
For practitioners, effort should be treated as an explicit variable in any evaluation. If one run uses medium effort and another uses high or xhigh, a comparison is measuring different amounts of test-time compute. Recording only the model name leaves out a material part of the configuration.
How did an idle session lose Claude’s reasoning context?
The most concrete bug involved Claude Code’s handling of extended thinking after a session had been idle for more than an hour.
Claude normally keeps its reasoning in conversation history. On subsequent turns, that history helps the agent understand why it made earlier edits and tool calls. This matters when an agent has modified several files, encountered a failing test, changed direction, and then receives a follow-up instruction. The visible repository state is part of the context, but it does not fully explain the chain of decisions that produced it.
Anthropic uses prompt caching to make back-to-back API calls faster and cheaper. Once a prompt has sat idle, it can be evicted from cache. The intended optimization was to clear old thinking sections once when resuming a session that had been idle for more than an hour. Since the resumed request would already be a cache miss, pruning unnecessary messages would reduce uncached input tokens. Future turns were supposed to resume with full reasoning history.
The implementation used the clear_thinking_20251015 API header with keep:1. Instead of applying the cleanup once, the bug applied it on every later turn in that session.
The resulting failure compounded over time:
- A session crossed the one-hour idle threshold.
- Claude Code sent a request that retained only the most recent reasoning block.
- Each later request continued discarding earlier reasoning.
- A follow-up message during tool use could begin another broken turn, dropping reasoning from the current task as well.
- The agent continued working with progressively less memory of why it had selected prior actions.
That is why users described the behavior as forgetfulness, repetition, and strange tool choices. The model could still execute requests, but the harness kept removing the explanatory context that connected one action to the next.
The bug also explains reports of usage limits draining unexpectedly. Since thinking blocks were repeatedly dropped from later requests, those requests also became cache misses. More uncached tokens meant more usage against the applicable limit.
Anthropic says two unrelated experiments complicated reproduction: an internal server-side experiment involving message queuing, and a separate change to how suppressed thinking was displayed. The latter hid the bug in most command-line sessions, including external-build testing.
The incident is a reminder that cache and context-management work needs behavioral tests, not merely token-count or latency checks. A good test case would include an idle period, a resumed multi-step task, a follow-up while tool use is underway, and assertions that the agent can explain or continue its prior plan. Unit tests can validate that a header is present. They do not automatically validate that the header stops being present after the intended one-time cleanup.
Anthropic fixed this issue in Claude Code v2.1.101 on April 10.
Why can a shorter system prompt hurt coding quality?
The third issue came from a system-prompt instruction added with Opus 4.7 on April 16. Anthropic describes Opus 4.7 as more verbose than its predecessor, with the added output contributing to its performance on hard problems.
The team had several ways to manage verbosity: model training, prompting, and changes to the thinking user experience. The system-prompt addition imposed these limits:
Length limits: keep text between tool calls to ≤25 words.
Keep final responses to ≤100 words unless the task requires more detail.
The change had passed multiple weeks of internal testing without regressions in the evaluations Anthropic ran. After further investigation, the team performed ablations that removed individual prompt lines and used a broader evaluation set. One evaluation found a 3% drop for both Opus 4.6 and Opus 4.7. Anthropic reverted the prompt as part of the April 20 release.
Output verbosity and working quality can be coupled in an agent harness. Text between tool calls can contain the model’s decision framing, uncertainty, next action, and interpretation of a tool result. A terse final answer is usually harmless when the task is complete. A hard cap during the middle of a tool loop can constrain how the agent coordinates its own work.
Prompt changes deserve the same release discipline as code changes when they affect an agent’s operating instructions. A system prompt is executable product behavior in the broad sense: it changes choices the model makes across every eligible task.
Anthropic’s planned controls reflect that. It says future system-prompt changes will receive a broad suite of per-model evaluations, continuing ablations for individual lines, and new tooling for prompt review and audit. Its CLAUDE.md guidance will also gate model-specific changes to the particular model they target.
What should teams test after changing an agent harness?
The postmortem shows why generic benchmark success is insufficient for a coding-agent release. The failures emerged from defaults, stale sessions, and system instructions. A useful release gate needs tests that exercise each of those layers.
| Change category | Test that catches the relevant risk |
|---|---|
| Effort-default change | Evaluate representative tasks at both old and new effort, then inspect latency, quality, and limit consumption separately |
| Context-pruning change | Resume sessions after the idle threshold and verify continuity across multiple later turns |
| Tool-loop behavior | Send follow-up instructions while tools are active and confirm the active task’s rationale survives |
| Prompt edit | Run per-model evaluations, ablate changed prompt lines, and inspect coding behavior beyond final-answer quality |
| Build divergence | Test the exact public build rather than relying only on an internal feature-testing build |
Anthropic says it will ensure a larger share of internal staff use the exact public Claude Code build. That is an important correction. A tool can be well tested in the build used for feature development while still behaving differently in the build customers receive.
The company also back-tested its Code Review tool against the pull requests containing the session bug. Given the repository context needed to understand the change, Opus 4.7 found the bug while Opus 4.6 did not. Anthropic plans to add support for additional repositories as code-review context and ship the improved version to customers.
That result is narrow and appropriately framed: it concerns those offending pull requests with the required repository context. It does show why code review for agent infrastructure cannot be limited to a changed file or isolated diff when the bug depends on interactions among context management, API behavior, and extended thinking.
For changes that may trade intelligence against latency, Anthropic says it will use soak periods, broader evaluations, and gradual rollouts. Those are the right safeguards for an agent product. A default can affect every task immediately; a slow rollout creates room for reports from real workflows before the new behavior becomes universal.