Three Unrelated Changes That Looked Like One Regression

A lowered default reasoning effort; a caching bug that kept clearing reasoning history; a system-prompt rule capping output length. The three touched different slices of traffic at different times, and together they presented as a broad, inconsistent drop in quality. That is precisely why they took weeks to isolate one by one. Claude Code, the Agent SDK and Cowork were affected; the API itself was not.

3separate problems, all fixed by 20 April
34 天days for the longest-running of them
−3%drop in benchmark scores caused by the third
v2.1.116the release in which all three were resolved

Problem	Window	What it was
One	4 Mar – 7 Apr	Default reasoning effort dropped from high to medium; users said it "felt dumber"
Two	26 Mar – 10 Apr	A caching bug kept clearing reasoning history, leaving one thinking block per turn after any idle period
Three	16 – 20 Apr	A system prompt capped output length (≤25/100 words), costing about 3% on benchmarks

Context · Problems one and two · Content 1 / 3

One: The Default Reasoning Effort Was Lowered 34 days · Sonnet and Opus 4.6

The reason: some users found the wait under high effort too long, with the interface appearing frozen. Internal evaluations showed medium cost only a little capability while cutting latency markedly, so on 4 March the default moved from high to medium.
The result: users said straight away that Claude Code "felt dumber". Anthropic adjusted the interface repeatedly — a start-up notice, an inline effort selector, the return of ultrathink — yet most users stayed on the medium default. That is the power of a default, and it is the real cost of the change.

Reverted 7 AprilThe default returned to high, and Opus 4.7 went further, to xhigh.
Manual overrideUsers can set reasoning effort themselves through the inline selector.

Two: A Caching Optimisation Went Wrong 15 days · fixed in v2.1.101

The intent: after an hour of inactivity, clear old thinking blocks (clear_thinking_20251015 with keep:1) to cut the token cost of resuming a session.
The bug: a clearing step that should have run once instead ran on every subsequent turn. Once a session had been idle for an hour, each new request kept only the most recent thinking block and discarded the rest.
How it showed: Claude increasingly could not recall why it had made a particular choice — forgetfulness, repeated work, odd tool selection.

Why Two Was So Hard to Find what hid it, and what surfaced it

Two unrelated experiments — a message queue and a change to how thinking was displayed — masked the bug, making it impossible to reproduce in most CLI sessions.
It sat at the intersection of context management, the Anthropic API and extended thinking, and passed human review, unit tests and end-to-end tests undetected.
The continual clearing lowered the cache hit rate, which was mistaken for the cause of unusually fast quota consumption.
It was finally caught when Opus 4.7 reviewed the offending pull request — Opus 4.6 had not found it.
As a result, Anthropic decided to give its code review tooling more of the repository as context.

Pivot · The third problem, and the root cause · Content 2 / 3

Three: A System Prompt Capped Output live for four days · three models affected

The reason: Opus 4.7 wrote at greater length. That helped on hard problems but consumed more tokens, so a rule was added to the 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 result: weeks of internal testing found nothing, but a wider ablation showed the rule cost Opus 4.6 and Opus 4.7 about 3% on benchmarks, with a marked effect on code quality. Sonnet 4.6, Opus 4.6 and Opus 4.7 were all affected — by a prompt written for the characteristics of Opus 4.7 alone.

Root Cause: Why It Resisted Diagnosis four unrelated sources of noise

The three changes hit different slices of traffic at different times, so in aggregate they looked like one broad, inconsistent decline.
Early on it was hard to separate from normal variation in user feedback; neither internal usage nor evaluations reproduced it at first.
The prompt change was designed for one model's characteristics but affected all of them, and weeks of testing showed no regression.
The caching bug's trigger — an hour of inactivity — meant it could not be reproduced in most development testing.

Resolution · Remedies and timeline · Content 3 / 3

What Changes Now five follow-up measures

Have a larger share of staff run exactly the public build of Claude Code, rather than a test build.
Run the full evaluation suite per model on every system-prompt change, with ongoing ablation analysis.
Build tooling that makes prompt changes easier to review and audit, and add model-specific guidance to CLAUDE.md.
Give any change that might affect capability a soak period, a broader evaluation suite and a staged rollout.
Open an @ClaudeDevs account on X and a central GitHub thread explaining product decisions and the reasoning behind them.

Timeline three overlapping threads

02Opus 4.6 ships with high reasoning effort as the default.
03-04The default drops to medium (problem one begins).
03-26The caching bug ships (problem two begins).
04-07Problem one is fixed; the default returns to high, and Opus 4.7 to xhigh.
04-10Problem two is fixed (v2.1.101).
04-16The output-length rule ships (problem three begins).
04-20Problem three is fixed; all three are resolved (v2.1.116).
04-23The postmortem is published, and usage limits are reset for all subscribers.

The lesson underneath

Each change passed its own review. The failure happened between them: no process was responsible for asking what several simultaneous changes would do together. The most substantive of the follow-up measures is exactly that — extending testing from the single change to a full per-model evaluation and a soak period.