🌟 When 'Intelligence' Suddenly Went Missing
Imagine sitting at your computer, asking Claude Code as usual: "Refactor this microservice architecture, considering high concurrency and fault tolerance." In the past, it would think quietly for seconds or even tens of seconds like a seasoned architect, drawing up a layered blueprint with elegant code, detailed comments, and thorough edge-case handling. But starting in March, everything changed. It began behaving like an impatient intern: hastily delivered solutions, flawed logic, even forgetting key constraints from your previous message. Developer communities erupted — some cried that "it got dumber," others suspected they were using a fake Claude. For over a month, countless people refreshed, rewrote prompts, and switched models late into the night without recovering that familiar magic.
Only on April 23, when Anthropic published its official postmortem, did everything become clear: the model itself was fine, and user prompts were not to blame. Three completely independent, seemingly trivial product-layer changes shipped at different times and, stacked together, produced a global "quality incident." No single culprit — yet everyone felt intelligence slipping away bit by bit.
🌍 Switch One: Default Reasoning Effort Slid from High to Medium
On March 4, Anthropic quietly changed Claude Code's default reasoning effort from high to medium, responding to a real pain point: Opus 4.6 occasionally "thought" too long at high effort, making the UI feel frozen. The change sounded reasonable — internal evaluations showed medium effort significantly reduced latency and helped users conserve usage limits. After all, longer thinking usually means better output, but users don't want to wait half a minute every time.
They underestimated what intelligence means to developers. Reasoning effort is essentially how much compute the model invests in thinking. It's like hiring a chef for a complex banquet: at high effort, he tastes the seasoning repeatedly, adjusts the heat, even invents new dishes on the spot; at medium, it's a fast-food kitchen — standard process, on the table fast, but nothing stunning. Many developers reported more basic errors in code, architecture lacking foresight, and edge cases skipped entirely.
I hit this myself: I planned to refactor a distributed lock mechanism with high-effort thinking, but it handed me a simple mutex solution without considering distributed consistency at all. Users weren't blind — they reported the problem constantly — but Anthropic initially dismissed it as normal variance. On April 7, they finally listened: defaults returned to high for all models, and Opus 4.7 even shipped with xhigh. The switch was flipped back, but the damage had already spread.
> What is reasoning effort? > A parameter in Claude Code controlling how deeply the model "thinks." High effort = more time on internal chain-of-thought, like showing more scratch work on a math problem; medium effort is closer to jumping straight to the answer. It trades off token consumption, latency, and final quality. For complex coding tasks, high effort is strongly recommended — otherwise it's like giving a student ten minutes to write a thesis.
🔄 Switch Two: A Cache Optimization Became a 'Memory Killer'
On March 26, another well-intentioned change shipped. To reduce latency and cost when resuming long-idle sessions, Anthropic designed a mechanism: if a session was idle for more than an hour, old "thinking history" would be cleared, keeping only the most recent block — since the cache had expired and needed reloading anyway. The intent was to use the clear_thinking_20251015 header with a keep:1 parameter to cut unnecessary tokens.
The result? A bug turned the clearing action from "run once" into "run on every turn." Once a session crossed the idle threshold, every subsequent request told the API to keep only the most recent thinking block — all prior reasoning was discarded. Worse: if you sent a message mid-tool-call, the new turn triggered the clearing again, losing even the current thinking. Claude developed amnesia — it kept writing code but no longer remembered why it chose a tool or changed a line of logic. Users saw repetitive rambling, bizarre tool choices, and ignored context.
A friend of mine was doing a multi-file refactor, went for coffee, and came back to find Claude explaining the architecture from scratch like a first meeting. Even more ironic: constant cache misses made usage limits burn faster than usual. It's like giving your assistant a notebook with an automatic paper shredder that rips out earlier pages each time they flip — billed as "saving space."
The bug was fixed on April 10 in v2.1.101. The discovery was dramatic: it only triggered in the corner case of idle sessions, and internal testing was masked by another message-queue experiment plus display-logic changes — even end-to-end tests missed it. Only when they used Opus 4.7 to reverse-review the code did the problem surface — the older Opus 4.6 simply couldn't spot it.
> What does prompt caching actually do? > This technique lets consecutive API calls reuse previous computation, like a browser caching images. Normally, thinking history stays in context for later reference. The bug let the clearing mechanism run wild, draining "memory" like an hourglass. More broadly, it exposed the fragility of long-session management — real projects span days, and a single bout of "forgetfulness" can waste hours of work.
🛠️ Switch Three: A Less Verbose System Prompt That Strangled the Coding Soul
On April 16, alongside the Opus 4.7 release, a seemingly harmless instruction 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 goal was to rein in Opus's naturally chatty output — smart, but too many output tokens, hurting UX and cost.
The problem: stacked on earlier prompt changes, this limit severely hurt coding quality. Forced to be terse between tool calls, the model lost the bridging thinking that connects context; final answers became compressed biscuits with key insights amputated. Developers found fewer code comments, vaguer explanations, and skipped steps in complex problem decomposition. On April 20, broader ablation experiments (removing prompt lines one by one to measure impact) found a 3% quality drop, and the change was rolled back in v2.1.116.
It's like telling a brilliant but verbose expert: "Answer in under 100 words." To comply, he omits the most critical chain of reasoning. Coding isn't fill-in-the-blank — it requires a layered narrative, and that 25-word cap strangled the narrative.
🔥 Three Switches Stacked: Why It Looked Like 'Universal Dumbing Down'
The key was staggered timing: the first change (March 4) hit Sonnet/Opus 4.6 users; the second (March 26) hit the same group again; the third (April 16) even affected the freshly launched Opus 4.7. Different users were hit at different times with wildly different symptoms — some felt it was "lazier," some "forgetful," some "suddenly inarticulate." Internal evaluations and dogfooding never reproduced the issues because public builds differed from internal test environments, and the corner cases were extremely hard to trigger. Only user reports with concrete, reproducible examples pieced the full picture together.
Everything was fixed by April 20, and on April 23 Anthropic reset usage limits for all subscribers. As they publicly admitted: "This is not the Claude Code users should have experienced."
🌟 Anthropic's Reflection: How Small Changes Became a Big Incident
Afterwards, they summed up several hard lessons:
First, internal teams should use fully public builds more often, rather than internal versions with test features. Many bugs were masked internally by display logic or experiments.
Second, a major upgrade to code review tooling — Opus 4.7 can now review code with full repository context, and that capability will eventually be opened to users. Previously, Opus 4.6 couldn't even spot its own bug.
Third, stricter gates for system prompt changes: every change must run broad evaluations across all models plus line-by-line ablation experiments, with added soak periods, gradual rollouts, and extra monitoring for changes that could affect intelligence. CLAUDE.md now explicitly requires model-specific changes to precisely target the intended model.
Finally, they created the @ClaudeDevs account and a centralized GitHub thread to explain product decisions in depth — no more leaving users guessing in the dark.
These changes amount to a collective awakening for AI product development. Three independent tweaks — from latency optimization, caching strategy, and prompt engineering — toppled like dominoes for lack of cross-team "global perspective" and sufficient edge-case testing. Similar incidents may happen again, but the bar just got higher.
🌟 Epilogue: Intelligence Is Never a Given
Claude Code has now regained its former brilliance — high-effort defaults, intact memory, measured expression. I recently used it to refactor another large project, and like an old friend it decomposed, verified, and optimized step by step, every line of code carrying that familiar glow of intelligence. That month-plus was a collective nightmare, but it made us heavy users cherish every high-quality interaction even more.
For developers, this is a mirror: no matter how powerful AI becomes, it still depends on humans obsessing over details. Three small switches taught us — while chasing speed and efficiency, never forget that intelligence itself is the core product.
------ References
1. Anthropic. (2026, April 23). *An update on recent Claude Code quality reports*. https://www.anthropic.com/engineering/april-23-postmortem 2. Simon Willison. (2026, April 24). *Recent Claude Code quality reports*. https://simonwillison.net/2026/Apr/24/recent-claude-code-quality-reports/ 3. Medium - Vibe Coding. (2026, April 30). *Anthropic Admitted Claude Code Broke. We Were Right.* https://medium.com/vibe-coding/anthropic-admitted-claude-code-broke-we-were-right-e3f3a6c60a31 4. Reddit r/Anthropic. (2026). *Official: An update on recent Claude Code quality reports*. https://www.reddit.com/r/Anthropic/comments/1stvdod/ 5. Anthropic Engineering Blog. (2026, April). Related posts on Claude Code harness and prompt caching lessons. https://www.anthropic.com/engineering