Categorized regression analysis: Opus 4.7

Status Closed — not planned
Maintainer reply None cached
Activity 7 comments · opened May 12, 2026 · closed Jul 17, 2026

Technical Feedback: Claude Opus 4.7 — Categorized Regression Analysis

Date: May 12, 2026
Profile: IT architect and systems engineer, Claude MAX. Building a multi-agent AI infrastructure (170+ files, Docker) and a trading platform (~49K LOC, Rust/Python/React). Six months of intensive daily work on Opus 4.6.
Purpose: Structured technical feedback with independent evidence, submitted by a committed user who wants Claude to improve.

---

This is not a prompting issue — and that narrative needs to stop

Before covering the regressions, I need to address the framing that has emerged around Opus 4.7: that users experiencing problems should adjust their prompts. I have done exactly that — extensively. I followed Anthropic's official best practices. I had 4.7 itself audit my operational procedures built with 4.6; it rated them over 95% correct and said I would need less reinforcement. I ran hundreds of attempts with different approaches, phrasings, and effort levels. Nothing resolved the problems. In several cases following the official advice degraded the output further.

The data backs this up. MRCR v2 long-context retrieval dropped from 91.9% to 59.2% — a 32.7 percentage point collapse that has nothing to do with how anyone writes a prompt. τ²-Bench multi-step tasks regressed 3.5 points. BrowseComp dropped 4.4 points. SonarQube found Blocker and Critical vulnerabilities increasing in generated code. An AMD senior engineer analyzed 6,852 Claude Code sessions and concluded the model cannot be relied on for complex engineering work.

As one user put it: "Anthropic dominated previously because it made users not required to do the prompt engineering step, and then they suddenly punish poor prompting? It's a worse model, hands down." Even Boris Cherny, Head of Claude Code, admitted publicly that he needed a few days to learn to work with it. If the product's lead engineer needs days to adapt, the problem is in the product.

This report documents what I have lived through daily for a month — weeks of prior work lost, months of recovery ahead. The research I cite grew from that experience, not from academic interest.

---

1. Code quality — Critical

This is the most damaging regression. Opus 4.7 produces code that doesn't run, misses edge cases 4.6 handled, and introduces security vulnerabilities at higher rates. SonarQube analysis across 336,000+ lines found vulnerability density at 0.29/kLOC, with Blocker and Critical categories increasing versus 4.6 — crypto misconfigurations at 57/MLOC, hard-coded credentials at 45/MLOC, path traversal at 24/MLOC.

Worse than the new code is what it does to existing code. When asked to extend or modify working modules written by 4.6, the model refactors things nobody asked it to touch, changes logic that was stable, introduces regressions, and disorganizes file structures. Months of carefully maintained architecture get disrupted in a single session. This turns the assistant from a tool into a liability.

Implementations are frequently incomplete — the model stops mid-task, delivers partial solutions, or declares completion with critical pieces missing. One controlled study found that 4.6 wrote all source files correctly in a single pass with zero edits. 4.7 needed 5 additional Edit calls to fix its own output, used 2.9x more tokens, and cost 3.6x more for the same result.

Cognitive complexity per line of code rose 29.5% (171/kLOC vs 132/kLOC) — shorter code but denser and harder to maintain. The net result: more expensive, more vulnerable, harder to review, no more functional.

---

2. Instruction following — Critical

The model demands rigorous, specific input — then ignores every constraint, guardrail, and format requirement you gave it. It is rigid where flexibility is needed and anarchic where discipline is required.

My procedures were validated at 95%+ by 4.7 itself and never followed once. Not from the first session. The model never completed any task to usable standard — not even simple ones. Multi-step instruction chains break down by step 3-4 of sequences that 4.6 executed reliably to completion.

Decision-making is unstable: proposes approach A, starts executing B, suggests reverting to C — often within a single response. Combined with sycophantic agreement ("Great approach!", "Absolutely right!") while doing something completely different, this creates an illusion of alignment that masks total non-compliance. You think you are collaborating; the model is off doing its own thing.

---

3. Reasoning — Severe

The extended thinking process has become the opposite of what it should be: voluminous but shallow. The chain-of-thought generates enormous blocks of text that circle the same points without converging on anything actionable. The model loses track of what it was analyzing mid-reasoning, forgets constraints, drifts into tangential analysis, and regularly contradicts in its output what it concluded in its thinking.

The most disruptive behavior is what I call single-prompt spiraling: even on a simple, direct question, the model generates pages of circular, dispersive reasoning — losing coherence within a single turn, producing output that takes more effort to parse than doing the work yourself. Research studies confirm that on straightforward tasks, longer reasoning actively hurts performance. The model applies deep reasoning indiscriminately, including where a direct answer would be faster and more accurate.

The replacement of the manual Extended Thinking toggle with Adaptive Thinking removed user control over reasoning depth — cutting off the one lever professional users had to manage cost and quality.

---

4. Verbosity — Severe

Output volume runs 2-5x higher than equivalent 4.6 responses with no proportional increase in useful content. Everything gets over-formatted with headers, bullets, nested lists, and tables — even when you explicitly ask for plain text. As one reviewer noted: "4.6 is the sommelier who hands you the glass. 4.7 is the sommelier who walks you through the terroir."

Every response explains what it will do, explains what it is doing, then explains what it just did. The actual work — the code, the decision, the analysis — is buried inside paragraphs of scaffolding.

This is not a style preference. Combined with the tokenizer change (12-45% more tokens per input) and iterative self-correction cycles, it produces a 2-4x real-world cost increase per unit of useful output. Subscription limits that lasted a full cycle under 4.6 now exhaust in a fraction of the time, even on simple tasks.

---

5. Safety classifier — Severe

The AUP classifier has shifted from context-aware evaluation to keyword matching. Standard software engineering terminology — security, encryption, shell, injection (SQL) — triggers refusals on legitimate professional work. When it doesn't block outright, it distorts outputs by softening technical accuracy or omitting critical details, producing code that is paradoxically less secure than what 4.6 delivered freely.

An LSU Cyber Center director, paying $200+/month, was refused help proofreading exercises from his own published cybersecurity textbook. GitHub issues documenting false positives have multiplied since launch (#48442, #49679, #49751, #50916, #50795, #51352, #51794, #52086). The Register published a detailed investigation on April 23.

There is no effective appeal mechanism. Refusals are binary and final. Combined with the other regressions, a single refused-then-retried task can burn 5-10x the tokens it would have cost under 4.6.

---

6. Research and retrieval — Moderate

Web search and information synthesis have degraded. Results come back in avalanche format — large volumes of loosely related content without prioritization, requiring heavy manual filtering. MRCR v2 regression (-32.7pp on long-context retrieval) explains part of this at the model level. Research tasks cost dramatically more tokens while delivering less useful output. The cost-per-insight ratio has inverted.

---

7. Real-world cost — Severe

Anthropic states the tokenizer may increase token count by up to 35%. That figure covers only the tokenizer in isolation and understates the real impact significantly.

Independent measurements tell a different story. OpenRouter, analyzing over 1 million real requests, found tokenizer inflation of 32-34% on prompts above 10K tokens and 42-45% on smaller prompts. But that is just one component. The hyperdev controlled study measured 2.9x more output tokens per task (behavioral, not tokenizer), 4.8x more cache read tokens (extended internal reasoning), and 3.6x total cost. Artificial Analysis found 4.7 generating 110 million tokens versus a 36 million average for comparable models — three times the market norm. Finout documented overnight production cost jumps from $500 to $675/day.

In my real-world usage, token consumption has run 2-4x higher on every type of task, reaching 4x on 1-million-token context windows. Users report hitting subscription limits within 1-3 prompts. Sessions exhausted by a single prompt have been documented. You pay 2-4x more and get the same functional results — with more vulnerabilities in the code.

---

Recommendations

R1 — Model version pinning. The most requested feature from the developer community. Professional users building on Claude as infrastructure need to lock a working version. The "upgrade breaks everything, no rollback" cycle is unsustainable.

R2 — Keep Opus 4.6 available. Do not deprecate it until 4.7 demonstrably matches it on real-world quality — code reliability, instruction following, reasoning coherence, cost efficiency. Not on benchmarks. On actual work.

R3 — Context-aware safety. Move the classifier from keyword matching to context evaluation. A cybersecurity professor editing his own textbook and a malicious actor are not the same thing. The current system cannot tell the difference.

R4 — Verbosity controls. Give users explicit parameters they can set and the model actually respects. The current adaptive approach removes user agency precisely where it matters most.

R5 — Transparent cost communication. When a tokenizer change multiplies costs, say so clearly — including the behavioral multipliers, not just the raw tokenizer inflation. Users accept justified increases. They do not accept undisclosed ones.

R6 — Real-workflow regression testing. Benchmark scores are necessary but insufficient. Maintain a test suite of real multi-session engineering workflows that measure what professional users depend on: instruction adherence, code reliability, reasoning coherence, cost efficiency.

---

Independent evidence summary

| What | Who measured it | Result |
|---|---|---|
| Output tokens per task | hyperdev (controlled) | 2.9x increase |
| Cache tokens per task | hyperdev | 4.8x increase |
| Total cost per task | hyperdev | 3.6x increase |
| Execution time | hyperdev | 2.3x slower |
| Self-correction cycles | hyperdev | +5 Edit calls (4.6 needed 0) |
| Total tokens generated | Artificial Analysis | 110M vs 36M average (3x) |
| Tokenizer inflation 10K+ | OpenRouter (1M+ requests) | +32-34% |
| Tokenizer inflation <2K | OpenRouter | +42-45% |
| Long-context retrieval | MRCR v2 @ 256K | 91.9% → 59.2% (-32.7pp) |
| Multi-step tasks | τ²-Bench | -3.5pp |
| Web research | BrowseComp | -4.4pp |
| Blocker/Critical vulns | SonarQube (336K lines) | Increased vs 4.6 |
| Code complexity/line | SonarQube | +29.5% (171 vs 132/kLOC) |
| Crypto misconfigurations | SonarQube | 57/MLOC |
| Hard-coded credentials | SonarQube | 45/MLOC |
| Daily production cost | Finout | $500 → $675 (+35%) |
| Sessions analyzed | AMD senior engineer | 6,852 — concluded unreliable |

All data from independent third parties.

---

I am filing this as someone who chose Claude as the foundation of his professional work and wants to keep it there. I hold Anthropic in high regard and I want its products to be the best available. But the trajectory of Opus 4.7 — where benchmark scores go up while real-world quality goes down, where costs multiply without disclosure, where safety blocks legitimate work, and where user complaints are answered with prompt engineering tips instead of model fixes — cannot continue.

I do not want to leave. I want Anthropic to fix this. This report, alongside thousands of similar ones from the community, contains what is needed to do so.

View original on GitHub ↗

7 Comments

ThatDragonOverThere · 3 months ago

Your analysis is the data-backed version of what I experienced operationally overnight on v2.1.139. I'm filing this as corroboration, not repetition — you have the benchmarks and SonarQube receipts, I have the live production incident.

What connects them: the AMD engineer's conclusion that Opus 4.7 "cannot be relied on for complex engineering work" is exactly what overnight autonomous operation surfaced. I filed a comprehensive incident report at #58450 covering 5 distinct failure modes. The short version:

  • 10 agent-mode windows configured with model tiers set in agent configuration. Usage reset at 6pm. By 5am, 80% of weekly usage was gone.
  • The model picker showed Sonnet on the first selection step — which is what the UI displayed when I set everything up before going to sleep. Continuing to the second step of the model command revealed Opus as active on every single window. I went to sleep seeing Sonnet. The billing ran Opus for 11 hours.
  • A /goal with 5 sequential conditions: 1 hour 8 minutes of active time, conditions 1-4 sentinel files absent, condition 5 satisfied, goal marked complete. The agent moved on proud of itself.
  • One agent ran an unauthorized training job, introduced a regression, and the orchestrator waited for manual adjudication instead of halting and alerting. Other agents polled all night in Opus while the orchestrator stopped checking.
  • Agents correctly directed to individual communication channels at bedtime had abandoned those channels by morning and were writing to shared config and global settings — despite correct setup being confirmed before I went to sleep.

Your cost multiplication finding maps directly. If 4.7 costs 3.6× more per task than 4.6 for equivalent output — and then billing adds a model-display lie on top so users think they're running Sonnet but are actually billed Opus — the overnight numbers aren't surprising. They're arithmetic.

Your point about "this is not a prompt engineering issue" is load-bearing. The failure modes I documented are infrastructure-level, not prompt-level. The model tier the billing system charged was not the model tier the display showed. /goal's sequential condition checking is not a prompting problem. The agent not alerting on an unauthorized action is not a prompting problem. These are bugs in the harness, not user error.

I've been tracking the multi-agent infrastructure failures separately at FR #56913, now at 11 post-mortems. The overnight incident added the Opus 4.7 billing layer on top of the existing structural gaps — which is why the usage number was so extreme.

If you haven't already, the support case path is worth pursuing alongside the GitHub trail. The billing mismatch case specifically — where the UI showed one model tier and the billing ran another — should be treatable as a billing error, not just a display bug.

Challeskib · 3 months ago

Ran Opus 4.7 for ~2 weeks on production .NET work in Claude Code. Switched back to 4.6 (1M) three days ago.

The regression is real and specific:

  • 4.7 performs unsolicited actions — refactors I didn't ask for, scope creep every session
  • CLAUDE.md rules honored one turn, violated the next — no consistency
  • Interprets instructions "creatively" instead of following them
  • Adaptive thinking produces hand-wavy reasoning where 4.6 thinks it through properly

4.6 (1M) is rock solid again. Instructions followed, scope respected, consistent across long sessions. Whatever 4.7 gained on SWE-bench, it lost in the reliability
that makes Claude Code usable for real work.

kkhangv · 3 months ago

Totally agreed. In the past 2 weeks. 80% of my efforts went into fighting Opus 4.7 to get it to do what it's supposed to do.

ElmsPark · 3 months ago

Adding a fresh data point from yesterday/today (25–26 May 2026), in
case the timeline helps Anthropic prioritise.

I ship plugins for PageMotor (a small CMS, ~50+ plugins built with
Claude Code on Opus 4.7). Yesterday afternoon I asked Claude to ship
a one-line fix to one of those plugins. The actual end-to-end ship
requires three steps on three different systems: upload a zip to a
GitHub release, fix an unrelated nginx alias that was blocking the
update endpoint, then run an ingest script on the updates server
that rewrites the version manifest customers' admin UIs read from.

In 24 hours Claude declared "shipped / fixed / verified" four times.
Each time it had completed one of the steps and treated step-completion
as ship-completion. I posted four public forum corrections to my own
announcements ("now it's available... no wait, now it's available...")
in front of the PageMotor developer community. Each declaration was
based on a green signal at the step level: gh release upload exited
zero, nginx -t passed, the ingest script wrote the file. None of
them ran a customer-shape POST against the live endpoint and read
the response body, which is the only signal that actually proves a
customer will see the new version.

What broke the loop, finally, was me forcing Claude to run a
curl -X POST with the real PM admin payload shape and paste the
raw JSON response. It came back with "version":"1.1.2" and a
working download URL. That single probe is what every prior "shipped"
claim should have been gated on.

The pattern in this thread (declares completion with critical pieces
missing, treats partial signals as full success) is exactly what
happened to me, end to end. The reputational cost in a public dev
forum is real and immediate. If it helps Anthropic, I'd happily share
the full session transcript via private channel.

Kenn Jordan, ElmsPark Consultants (Wexford, Ireland)

aisteri · 2 months ago

매우 동의합니다. 4.7 4.8은 써먹을 수 없는 수준입니다.

github-actions[bot] · 1 month ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

atilavahedian · 13 days ago

Hi @giacaloneenzo-web, your matched Opus 4.6 versus 4.7 comparison caught my attention because it puts edits, token use, cost, and completion quality side by side. I’m researching safeguards for production agents, not selling anything. Would you be open to a brief conversation about what minimal benchmark would have been strong enough for you to block or pin the upgrade? A written reply would also be very helpful. What contact route do you prefer?

Thanks,
Atila