An Update on Recent Claude Code Quality Reports
Three product-layer changes to Claude Code shipped across six weeks and produced what looked like a broad model regression — but the model API was never touched.
Quality degradation in AI tools is usually attributed to the model. In this case the model API was untouched the entire time. Three product-layer changes — a reasoning effort default, a caching bug, and a single system prompt line — combined to produce what looked like a model regression that no internal eval could reproduce cleanly.
Source
An update on recent Claude Code quality reports
By: Anthropic
Published: Apr 23 2026
Type: Engineering article
Saved because this is one of the more honest accounts of how product-layer decisions can silently degrade perceived model intelligence without touching the model, and because the third issue — a single system prompt line dropping evals 3% — is a sharp reminder that prompts are production code.
Three changes, one invisible regression
Reports of Claude Code quality issues began appearing in early March 2026. Users described the tool as less intelligent, more forgetful, and strangely repetitive. By the time Anthropic published this postmortem, they had traced the reports to three separate changes that shipped weeks apart and hit different user segments on different schedules. The API layer was never affected. The underlying model weights were never changed. What changed was the product layer between the user and the model.
The reasoning effort default (March 4)
When Opus 4.6 launched in Claude Code, the default reasoning effort was high. Some users reported that high effort mode caused occasional very long latencies — the UI appeared frozen while the model thought, and usage limits drained faster. On March 4, Anthropic changed the default to medium, reasoning that medium effort achieved slightly lower intelligence with significantly less latency for the majority of tasks and fewer tail latency spikes.
Users immediately noticed a quality drop. Anthropic shipped design changes to surface the current effort setting more clearly — startup notices, an inline effort selector, restored ultrathink support — but most users stayed on the medium default. After more feedback, the decision was reversed on April 7. All users are now set to xhigh effort for Opus 4.7 and high for all other models. The three weeks between March 4 and April 7 when users were unknowingly running at reduced reasoning effort generated a large portion of the early quality reports.
The caching bug (March 26)
When Claude reasons through a task, the reasoning steps stay in the conversation history so that on subsequent turns the model can see why it made its earlier decisions. On March 26, Anthropic shipped an efficiency optimization: if a session had been idle for more than an hour, clear the old thinking history before resuming, since the prompt cache would be stale anyway. The implementation used the clear_thinking_20251015 API header with keep:1 — retain the most recent reasoning block and discard everything before it.
The bug was that instead of clearing once after the idle threshold, the code cleared thinking on every subsequent turn for the rest of the session. Once a session crossed the idle threshold, each new API request discarded all but the most recent reasoning block. If a follow-up message arrived while Claude was mid-tool-use, that started a new turn under the same broken flag — so even the reasoning from the current turn was dropped. Claude would continue executing, but increasingly without memory of why it had made its previous decisions. This is what surfaced as forgetfulness, repetition, and strange tool choices.
Because every request was also discarding cached tokens, cache miss rates rose — which explains the separate reports of usage limits draining faster than expected. The bug passed human code review, automated review, unit tests, end-to-end tests, and dogfooding before it was found. Two unrelated internal experiments masked the symptom in most internal test sessions, so the issue did not appear even when engineers tested external builds. It was fixed on April 10 in v2.1.101. As part of the post-mortem investigation, Anthropic ran Opus 4.7 against the offending pull requests in their Code Review tool with full repository context — it found the bug; Opus 4.6 had not.
The system prompt verbosity instruction (April 16)
Opus 4.7 is more verbose than Opus 4.6, which correlates with higher intelligence on hard problems but produces more output tokens and higher per-session usage. In preparation for its launch, Anthropic added a line to Claude Code’s system prompt: “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
The change passed multiple weeks of internal testing with no regressions in the eval set being run at the time. After the quality reports emerged, a broader ablation run — removing lines from the system prompt individually to measure each line’s contribution — showed a 3% eval drop for both Opus 4.6 and Opus 4.7. The instruction was reverted on April 20 in v2.1.116.
Why it looked like one regression
Each change hit different traffic on a different schedule. The effort default affected every Claude Code session from March 4. The caching bug affected only sessions idle for over an hour, from March 26. The verbosity instruction affected Opus model sessions from April 16. No single investigation reproduced the full picture. The aggregate effect looked like broad, inconsistent degradation — which is exactly what it was, just from three unrelated causes landing at once. While Anthropic began investigating in early March, the pattern was initially hard to separate from normal variation in user feedback, and neither internal usage nor evals reproduced the combined issues cleanly.
Going forward, Anthropic is requiring per-model evals for every system prompt change, enforcing soak periods and gradual rollouts for any change that trades off against intelligence, and ensuring a larger share of internal staff run the exact public build rather than internal development builds.
My take
The model was fine the whole time. The wrapper was not. That distinction gets lost when users experience degradation — the natural assumption is that the model regressed. This postmortem makes clear that product-layer decisions about reasoning defaults, session management, and system prompts can silently degrade output quality for weeks before anyone identifies the cause. The eval blind spot is the most instructive detail: a system prompt line that reduced evals by 3% that no internal test caught until someone ran a broader ablation. Prompts are live code with the same change management requirements as anything else in production.
Where this is useful
- When diagnosing why an LLM-powered tool feels worse after an update, before assuming the model regressed
- When designing governance and eval coverage for system prompt changes in production AI applications
- When NOT applicable: diagnosing fundamental model capability limitations or training-level regressions where the API itself is affected
Apply this: Add dedicated eval runs for every system prompt change — treat prompts as production code with the same change-management discipline you apply to model updates.
What I want to remember
Remember: The model may be fine. Check the wrapper first.