Claude Opus 4.6: 6,852 sessions analyzed, a read-before-edit ratio cut by 3x, and trust in pieces
Alexandre
··
Reading time: 11 min
6,852 session files. 234,760 tool calls. 17,871 thinking blocks. And a read-before-edit ratio (the number of files the agent reads before it modifies any code) that went from 6.6 to 2.0 between late January and early April 2026. These numbers come from one advanced Claude Code user, not from an official Anthropic audit. They were enough to push a Hacker News thread past 1,300 points.
On February 5, 2026, Anthropic introduced Claude Opus 4.6 as its strongest model for large codebases, long agentic tasks, and a 1 million token context window. Two months later, GitHub issues, tweets, and HN threads were all saying the same thing: it moved faster in the wrong places, read less before editing, and gave the impression of finishing a task before it had understood it.
Here is what actually happened.
Why the regression narrative exploded so fast
Between late February and early April 2026, complaints about Claude Opus 4.6 surfaced simultaneously across GitHub, Hacker News, X, and production pipelines. When the same symptoms show up everywhere at once (less reading, more shortcuts, confident but wrong analysis) this stops being just timeline mood.
The first really ugly signal is issue #30027, opened on March 2. The author describes more than 50 Claude Code sessions over 15 days with the same pattern: highly confident technical analysis, not actually verified, followed by a correction only when the human pushes back. The issue is not about one bug. It is about a behavior that wears you down.
Four days later, issue #31480 describes a production pipeline that had been running reliably for more than two weeks with claude-opus-4-6 and suddenly started ignoring critical rules, style files, and schema constraints, with no changes on the prompt or infrastructure side. At that point, we are no longer talking about vibes. We are talking about broken work.
Then there is issue #42796, opened April 2, which landed on Hacker News and cleared 1,300 points and more than 700 comments. That is not scientific proof, but it is a real thermometer for how frustrated developers were getting. When that many people show up with stories about Claude skipping steps, calling obviously wrong fixes "simple", or looping on corrections it created itself, you can feel trust starting to crack.
Click to enlarge
On X, the tone is the same. Dave Kennedy writes that he noticed something was off four weeks earlier, that it got progressively worse, and that he ended up cancelling Claude and going back to Cursor, Codex, and Kimi. Jerónimo Palacios shared a very concrete case: Opus 4.6 had type issues and simply replaced calls with type: any. The kind of shortcut that saves you ten minutes now and costs you a full morning the next day.
When multiple developers describe the same structural laziness across different projects, that is not noise. That is a real signal.
The numbers that pushed the debate out of the grey zone
The conversation changed once concrete metrics started circulating: session volume, thinking depth, read-before-edit ratio, user interruptions. Not a peer-reviewed paper, but precise enough that Anthropic could no longer respond as if people were simply holding the tool wrong.
The most cited dataset is the analysis attached to issue #42796. Its author says they analyzed 6,852 session files, 234,760 tool calls, and 17,871 thinking blocks between January 30 and April 1. The numbers everyone remembered are simple: median thinking depth dropping from roughly 2,200 characters to 560-600, the read-before-edit ratio falling from 6.6 to 2.0, and 173 stop hook violations in 17 days after March 8, versus zero before.
These numbers do not come from a public Anthropic audit. They are data from one advanced user, not absolute truth. But they line up with what people were already describing everywhere else. Even imperfect, that makes them useful.
The read-before-edit ratio is the indicator that hits hardest because it is brutally concrete. An agent that reads six files before editing feels like a careful colleague. An agent that reads two before rewriting your code feels like an impatient intern. That kind of difference rarely shows up in a clean benchmark. It shows up in your Git diffs at 11:40 p.m.
The Hesamation tweet landed because it compresses exactly that. No grand theory. Just measurable friction points: less thinking, more retries, less reading, more contradictions, and worse quality at the hours where GPU load would be highest. For a subject this messy, that was enough to move the discussion out of the vague zone.
I always distrust retroactive log analysis done on personal data. But this is exactly how power users spot regressions before everyone else. They feel it first, then they go digging, and sometimes they are right before the vendor is. That kind of real-time signal is what I track in Waku, my visual PKM for iOS: catching information when it is circulating, not three weeks later when everyone has already moved on.
What Anthropic admitted, and what stayed foggy
Anthropic never published a clean post saying "yes, Opus 4.6 was nerfed." But the team did acknowledge several product-level behavior changes that explain part of the user shock: visible thinking redaction, a lower default effort setting, and cases where adaptive thinking genuinely under-allocates reasoning.
In the pinned comment on issue #42796 and later on Hacker News, Boris Cherny from the Claude Code team explains two things. First, the redact-thinking-2026-02-12 flag hides thinking in the UI but does not reduce the underlying reasoning on its own. Second, on March 3, 2026, Anthropic changed the default effort level for Opus 4.6 to medium effort (85), with the goal of reducing latency and cost for most users.
Put differently: some people experienced a very real "Claude feels shallower now" moment because, quite literally, the default setting made it reason for less time. That is not a conspiracy. It is a product tradeoff. And this is where I get harsh with Anthropic: when you change reasoning depth on a tool that developers are paying to do hard work, you need to over-communicate, not quietly slide it through without warning.
Click to enlarge
The Claude Code settings documentation confirms several useful details. showThinkingSummaries changes what you see, not what the model generates. effortLevel is real, accepts low, medium, high, xhigh (added with Opus 4.7) and max (Opus 4.6 only), and persists between sessions. Once you know this exists, it seems obvious. It feels much less obvious when you discover it only after a bad week of wondering why Claude was cutting corners on everything.
Click to enlarge
From Jaime Medina's thread, one of the best public breakdowns of effortLevel, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING, and MAX_THINKING_TOKENS.
The most revealing moment came in the HN thread. After reviewing several feedback IDs, Boris Cherny said that some turns sent with effort=high still showed under-allocation of reasoning by adaptive thinking, with zero reasoning emitted on the turns that were actually generating things. If the system sometimes decides to think less on the exact turns where it hallucinates, the problem is not psychological. It is a real allocation failure.
While all of this was happening, Anthropic published Project Glasswing with benchmarks showing Mythos Preview substantially outperforming Opus 4.6: 77.8% versus 53.4% on SWE-bench Pro (the benchmark for agentic coding, measuring how well a model resolves real bugs on open-source repos) and 82.0% versus 65.4% on Terminal-Bench 2.0. Effectively, Anthropic was saying "we know 4.6 has problems, but look what we have coming." Except when you are a paying customer already frustrated by quality drift, learning that Anthropic has something much stronger sitting in-house does not exactly calm you down.
Why unpredictability hurts more than a real capability drop
When you build alone, the real cost of a regression is not average quality. It is unpredictability. A tool that is slightly weaker but stable, you can adapt. A tool that is excellent on Monday and sloppy on Tuesday with no clear signal destroys rhythm.
I see it in how I work on Waku with Claude Code. My usage is not casual. Large CLAUDE.md, project conventions, review loops, tests, back-and-forth between frontend, backend, and product logic. In that kind of setup, you do not need an agent that feels "creative." You need something methodical, almost boring, that reads before it touches things and does not sell you a shortcut when it has not understood the constraint.
The real danger is not one extra bug. It is the moment you start reading every output with permanent suspicion. Because that is where the speed gains evaporate. If I need to verify that business logic was not subtly bent, that type: any did not sneak back in, that the model did not sidestep my instruction with a plausible-sounding story, I am back to heavy supervision. And heavy supervision, when you are alone, is brutal.
I already wrote about this in my breakdown of AI code agent architecture: an autonomous agent is only worth something if you can trust it over time. Otherwise you spend your time reviewing instead of shipping. So that means more intermediate commits, more guardrails, less confidence in long uninterrupted sessions. For a tool sold specifically as the copilot that can hold long tasks, that is a serious problem.
This whole sequence hands Cursor, OpenAI, and every challenger a gift: they do not need to prove they dominate Opus 4.6 on every benchmark. They only need to appear more stable, or at least more transparent, at the moment trust in Claude Code is wobbling.
Dave Kennedy captures the risk for Anthropic well. In effect: Opus 4.6 was magic at launch, then unusable, so he left. When an intensive user leaves not because a competitor delivered some revolutionary leap, but because they no longer want to negotiate with the model's mood, you have a retention problem, not a feature problem.
OpenAI understands this moment very well. Their new $100 tier and the rise of Codex are landing in a near-perfect context. Cursor too. Even though Claude Code remains genuinely strong when it is having a good day, competition can benefit from nothing more than doubt. Market share gets chipped away by fatigue, not by some grand knockout demo.
For Waku and Koda, I am not going to swap my main tool every three days. That would be stupid. But I am looking at the market differently than I was two months ago. Before, I mostly evaluated raw capability. Now I add another question: do I understand why the model worked well or badly today? If the answer is no, I have a vendor dependency problem. This is what I dig into most right now, and I get into the details in my Claude Code workflow.
What strikes me is how fast perception can flip. In February, Anthropic was selling a machine that planned better, held large codebases together, and corrected itself more reliably. By April, part of the developer conversation had shifted to effortLevel, thinking budgets, and workarounds to recover the old behavior.
What Anthropic should do (and has started doing)
Anthropic can still recover trust here, but not with a few scattered comments and documentation only obsessive users eventually find. It takes clear versioning, visible reasoning signals, and direct communication whenever a setting materially changes the experience.
The first thing is model snapshots that production teams can actually pin. If a team built a pipeline around a certain behavior, they should be able to lock it. Issue #31480 asks for this explicitly. You cannot sell serious automation while quietly changing the model underneath it.
The second is making effort visible all the time. Not buried. Not in a callout. Right there, always. If the agent is running in medium, I want to know immediately. If a subagent is at a different level, same thing. This is the kind of detail that prevents hours of false diagnosis.
The third is simple reasoning telemetry. I do not need the full chain of thought. But honest counters: budget used, effective effort, turns where adaptive thinking contracted sharply. When you hide everything, you create the exact vacuum that viral tweets then fill for you.
Finally, talk to developers like they are paying adults. Say: "we lowered the default for a latency/cost tradeoff." Say: "we are seeing turns where allocation misfires." Say: "here is the fix, here is the date, here is the expected impact." It is blunt, but it repairs trust faster than any polished announcement.
Since this article was originally published, Anthropic shipped Opus 4.7 on April 16, 2026 with the xhigh effort level, output self-verification, and better long-context consistency. Then Opus 4.8, with a reworked adaptive thinking system that permanently replaces the old budget_tokens approach. The problem has not disappeared, but the direction is right. The challenge stays the same: shipping a better model is not enough; you also have to tell people when the model they are already using changes behavior.
3 things to take away
1. Trust matters more than raw capability
A brilliant but inconsistent agent costs more than a merely good one. When you have to check every output, the productivity gains disappear. A read-before-edit ratio going from 6.6 to 2.0 is basically the difference between a careful colleague and an impatient intern.
2. Effort level should be part of your workflow
Not something you discover after a bad week. effortLevel goes in your CLAUDE.md, checked at the start of each session, adjusted to the type of task. I broke this down in my guide to cutting token usage in half.
3. You need a backup plan
Not out of disloyalty. Out of pragmatism. When a vendor can change your tool's behavior without telling you, keeping a second model available is just common sense.
Conclusion
Did Claude Opus 4.6 really regress? Yes. There was a massive perceived regression, and it did not come out of nowhere. Some of it came from changes to default settings. Some of it was tied to genuine reasoning under-allocation. And the rest came from something simpler but more damaging: Anthropic let its users discover on their own that their tool was no longer behaving quite the same.
Claude is not finished. But a coding agent is not a toy anymore. It is an infrastructure layer that developers build on every day. When you change the reasoning without warning, you change the pace, the fatigue level, and the ability to ship.
I will keep using Claude Code. But with less faith, more checks, and a much sharper eye on the competition. Did you feel a real drop with Opus 4.6, or just a settings change that made a lot of noise? Drop me a message on X or in the comments.
Alex
Key takeaways
The debate around Opus 4.6 did not come from a viral benchmark. It came from GitHub issues, broken production pipelines, and consistent field reports across multiple platforms.
The most cited analysis covers 6,852 sessions, 234,760 tool calls, and a read-before-edit ratio that fell from 6.6 to 2.0. Not absolute proof, but too precise to dismiss.
Anthropic acknowledged a default effort-level change in early March and cases where adaptive thinking under-allocated reasoning. The problem is not imaginary.
A brilliant but inconsistent agent can cost more than an average but stable one. Predictability is what solo work depends on.
Anthropic can recover trust with model snapshots, always-visible effort, reasoning telemetry, and direct communication whenever the experience changes.
