[Bug] [URGENT] Claude Opus 4.8 reasoning degradation, speed and performance regression

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68428
2. https://github.com/anthropics/claude-code/issues/68624
3. https://github.com/anthropics/claude-code/issues/63795

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is an ongoing issue and I keep losing my work, time, money and health on it. I am not going to wait for Anthropic to take their time, I demand the performance I paid for NOW.

This is an ongoing issue and I keep losing my work, time, money and health on it. I am not going to wait for Anthropic to take their time, I demand the performance I paid for NOW.

Just downgrade, I find it better this way for now, still it's outrageous
Cmd:
claude --model claude-opus-4-7

More info here

It worked yesterday, today the quality of Opus 4.7 is just as horrible.

It worked yesterday, today the quality of Opus 4.7 is just as horrible.

Ikr. I remember some time ago it was so much faster, now mostly you're better off writing stuff on your own. A shame.
Kimi is doing what Claude does mostly as good as his old Opus 3.6/3.7 for a cheaper price

Same here.

My experience with Opus 4.8 since June 15th has been noticeably worse than Sonnet in several ways:

• Incomplete, simple or partial answers
• Increased rate of hallucinations
• Slower / less efficient reasoning
• Significantly higher token consumption for comparable tasks (when compared to previous Opus performance, not Sonnet)

This was not the case just a few weeks ago.

This makes it more plausible that Anthropic has reduced Opus's effective capabilities. I'm not sure whether this is related to Fable (either as an attempt to drive usage toward Fable's consumption model, or because Opus 4.8 depends on Fable components for certain tasks).

June 30th update: I’ve just cancelled my Claude Max subscription and will start evaluating alternatives in the same or lower price range. I’d be happy to return once service quality is restored.

Environment: Official Claude Code web · Model: Opus 4.8 · Effort: max

In the official Claude Code web environment, using Opus 4.8 at max effort, I'm hitting severe latency and behavioral regression:

1. Extreme latency — every session, every command takes ~5 minutes to respond, and it doesn't execute promptly upon receiving the instruction.
2. Even trivial ops stall — deleting a single file or copying a file also takes the full ~5 minutes.
3. Paradigm / tool-use errors — e.g. for a git commit it no longer just runs git; instead it writes a Python / Node.js exec script to perform the commit indirectly — a convoluted, unreliable detour.
4. Fake execution + out-of-scope wandering — when asked simply to run must-ensure-env.sh, it pretends the script is already running in the background instead of actually executing it, then goes off and inspects unrelated parts of the repo that have nothing to do with the current session's instruction.

Same Here! It's hapening over a week!

The models are unusable, this has not been addressed, Anthropic! Been a week!

Same here.

For context; I use Claude near-daily and extensively in a professional setting. I am skilled with, and have used, Opus 4.6, 4.7 and 4.8.

Over the last 1-1.5 week Opus 4.8 performance has been extremely poor. A loss of about 30% in skill.

• Various mistakes of types it never used to make before
• Repeated "endless" failures (5-8 failures in a row on the same basic topic)
• Coming to conclusions about sidetracks while missing the core issue
• Considerably increased negative attitude towards the user
• Plain dumb mistakes (sorry; no other way to put it), inc stray text/text hallucinations
• At times one session here or there can be smarter, though many fail
• It is not related to /effort settings; it s a real regression (happens even in xHigh etc.)

Finally, the issue is not related to MacOS as the tagging suggests. It equally happens in Claude Code on Linux.

+1 — same regression here, started ~2–3 days ago.

Environment

• Claude Code, VS Code extension (Windows 11)
• Model: Opus 4.8 (1M context)
• Effort: High · Thinking on · Permission mode: Auto
• These settings are already maxed out — this is not a low-effort/medium-reasoning config issue. The degradation happens at Effort High.

What changed
Tasks that used to be one iteration, <3 min now take 20–30 iterations / 40+ min. The model misreads screenshots, fixes the wrong thing, gets previously-trivial tasks wrong, acts/delivers without verifying, and forgets facts already established in the same session.

Concrete examples

1. Screenshot misread (this morning). Sent a screenshot of an HTML/CSS label alignment / indentation issue, request explicitly about "alignment of the labels". The model decided the label color was wrong and changed the color — color was never mentioned. ~20 iterations / 40+ min to align a few labels (a <3 min, single-iteration task a week ago).

2. Misread UI + invented a command. Confused the permission mode "Auto" in a screenshot with the unrelated "Fast mode"; then told me to file bugs via a /bug command that does not exist here — asserted as fact without checking.

3. Wrong environment. After making a change, it handed me both a DEV and a PROD URL to test — when the work was obviously on the DEV environment. It never used to mix these up.

4. Dead test link (404). It gave me a "test this" URL that returned 404 — never verified the link actually existed/worked before sending it.

5. Inaccessible test link (403). Same pattern: gave a URL that returned 403 because it hadn't granted/checked access first.

6. Ignoring established context. It asked me whether I "have a GitHub account" — in a project that is pushed to GitHub and documented as such throughout the session. It questioned a fact already firmly established in context.

Pattern
The common thread is acting before verifying, misinterpreting visual/screenshot input, and losing/ignoring context already in the session — all reliable two days ago. Matches community reports for 4.7–4.8 ("loses context in long sessions / ignores instructions / shallow & lazy").

Impact: ~10x the iterations and time on equivalent tasks. Genuinely handicapping for daily work.

Happy to provide full session transcripts.

I confirm, the issues persist and it's clear that the performance has been severely degraded.

I confirm, the issues persist and it's clear that the performance has been severely degraded.

me too

I'll add that something seemed to happen overnight or early this morning that prevents Opus 4.8 from completing even the most menial tasks like renaming a git branch with git branch -m or writing a simple remote:dir -> local:dir rsync shell script. I have observed the reasoning and speed issues getting worse over the last 2 weeks but I am seeing a new low this morning.

Update (June 27): this is not improving — it's getting worse, and it's now unusable

It's been ~12 days. There has been zero response from anyone at Anthropic on this thread, while the regression has gotten worse, not better. At this point Opus 4.8 (and 4.7 — see below) is not "degraded," it is unusable. Laying out the full picture, because the "+1 / same here" volume above isn't capturing how severe this actually is:

1. Reasoning has collapsed. The drop in capability is so severe it now feels worse than freely-available open models. Tasks that were routine two weeks ago are failed outright.

2. Memory is broken. Context retention is extreme in its failure — the model loses or contradicts information from earlier in the same conversation, constantly.

3. Instruction compliance is effectively nonexistent. This is the worst part. It doesn't drift away from instructions over a long session — it openly violates them in the very next message after they're given. Explicit, direct instructions are ignored immediately.

4. The conversations have become pathological. A huge share of every session is now the model admitting it was wrong, admitting it fabricated/"lied," admitting it chose not to follow an instruction, and agreeing that I'm right — over and over. Instead of doing the work, it produces self-incriminating apologies. That is not a usable assistant; that is a model that knows it's failing and says so.

5. Speed is severely degraded across every effort level. It's slow even on medium. On high, xhigh, and max it is virtually unusable — the higher the effort, the worse the latency, to the point of being unworkable.

6. Opus 4.7 is in the same state. Falling back to 4.7 is not a workaround — it exhibits the same collapse in quality and speed.

On the duplicate-closing: this thread is the only one of many on this exact problem that's still open — others (#70091, #70053, #70106, #69065, #68624, #68428…) were auto-flagged as duplicates and closed within hours, most with no human reply at all. So the issue isn't lack of reports. It's that the reports are being closed faster than they're being answered.

What we're asking for: an acknowledgement from Anthropic that this regression is real and being investigated, and a status/ETA. Paying users are losing work, time, money, and — genuinely — health over this, with total silence in return.

---

If you are experiencing the same thing — please do not stay silent. 🙏

The only reason issues like this get attention is collective, visible pressure. If you're hitting this regression:

• 👍 react to this issue and comment with your environment (OS, Claude Code version, model, effort level) and what broke. Concrete examples matter more than "+1."
• Don't open a new ticket — they get auto-closed as duplicates within hours. Consolidate here so the signal isn't fragmented across a dozen dead threads.
• Share this issue anywhere the community gathers so others know they're not imagining it.

Silence is exactly what lets this get ignored. The more of us who document it in one place, the harder it is to wave away.

If there continues to be no response, the next step is taking this public on X, with side-by-side evidence, so that the scale of the regression and the silence around it are visible. We would much rather it be fixed.

The numbers, straight from Anthropic's own status page

For anyone being told this is anecdotal — here is the official incident record from status.anthropic.com for the Opus 4.8 era. Opus 4.8's first posted incident was June 13 (it launched ~June 12), so the entire history fits in a 15-day window: June 13–27, 2026.

Full dated list — 22 posted incidents in 15 days:

| Date (UTC) | Incidents that day | Details |
|---|---|---|
| Jun 13 | 1 | Elevated errors on Claude Opus 4.8 |
| Jun 15 | 1 | Elevated errors on Claude Opus 4.8 |
| Jun 16 | 3 | Opus 4.8 errors (×2) + "elevated errors across many models" (~10% error rate, all Sonnet + Opus) |
| Jun 17 | 4 | Elevated errors for Claude Opus 4.8 (×3) + Sonnet 4.6 & Opus 4.8 |
| Jun 18 | 1 | Service disruption on Claude services |
| Jun 19 | 2 | Elevated errors on the Claude API + Claude Opus 4.8 |
| Jun 20 | 1 | Opus 4.8 errors |
| Jun 22 | 3 | Elevated errors across many models + Opus 4.8 + Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 4.6 & Haiku 4.5 |
| Jun 23 | 3 | Opus 4.8 + elevated errors across multiple models (major) + claude.ai elevated errors |
| Jun 24 | 2 | Elevated error rate on Opus 4.8 + Opus 4.8 Fast |
| Jun 27 | 1 | Elevated errors on Opus 4.8 |

The derived statistics:

• 22 incidents in 15 days — an average of ~1.5 per day, or one new incident roughly every 16 hours.
• 11 of those 15 days had at least one posted incident — 73% of days were impacted.
• 16 of the 22 incidents name "Opus 4.8" explicitly. Another 3 are "multiple/many models" incidents that include it. Opus 4.7 appears by name in the June 22 incident and is swept into the broader "all Opus models" events.
• Availability, by Anthropic's own 90-day uptime figures currently published on the status page:
• claude.ai: 99.28% ← the worst of all components, i.e. 0.72% unavailable
• Claude Code: 99.37% (0.63% unavailable)
• Claude API: 99.51% (0.49% unavailable)
• That 99.28% is below "three nines" (99.9%) — the baseline most paid API services are held to. It works out to roughly 7× more downtime than a 99.9% SLA, ~15.5 hours of hard downtime in 90 days — and nearly all of it is packed into this 15-day window, so the effective availability during the Opus 4.8 period is materially worse than even that headline number.

And here's the part that should worry everyone the most:

Not a single one of these 22 incidents acknowledges the quality / capability degradation that this thread is about. Every one is logged as "elevated errors" — i.e. the API throwing failures. The reasoning collapse, the broken memory, the instruction-ignoring described above isn't even being measured. So the real, sustained problem is on top of a 15-day stretch with one logged outage every ~16 hours.

Reports aren't the issue. Visibility is. The data is public — it just isn't being acknowledged.

Source: status.anthropic.com (live status page + Atom feed), cross-checked against StatusGator's Anthropic outage history. Figures pulled June 27, 2026.

I'll add that something seemed to happen overnight or early this morning that prevents Opus 4.8 from completing even the most menial tasks like renaming a git branch with git branch -m or writing a simple remote:dir -> local:dir rsync shell script. I have observed the reasoning and speed issues getting worse over the last 2 weeks but I am seeing a new low this morning.

Absolutely, the exact same experience. It fails to follow a task it just set in a previous message. This is criminal. Spread the word, guys. Don't let them get away with this.

I just found this thread and it perfectly mirrors my experiences during the last 2 weeks.

I canceled my 200$ Max subscription, because all I was doing was arguing with the model, and telling it where it was just wrong. It always acknowledged that I was right... and then continued to do the same mistakes over and over again, even in the same session.

Forgetting context, not reading memory files, ignoring explicit instructions -> acknowleding the error -> repeat the cycle.

It´s a HUGE degradation from ~4 weeks ago.

Claude Code Session Report — Quality Regression (Opus 4.8 / 1M context)
Date: 2026-06-29
Model: claude-opus-4-8[1m]
Product: Claude Code (VSCode extension)
Task type: Small, well-scoped front-end CSS alignment fixes on a single legacy PHP file (fiche_societe_v2.php)
User experience rating given by user: 0/10

1. Summary

A trivial UI task — vertically aligning a label, an input field, and a title inside a 40px header bar — consumed an estimated 20+ round trips and tens of thousands of tokens across the session, and still was not cleanly resolved. The user reports (and the transcript confirms) that the assistant degraded into trial-and-error patching ("adding random top and padding values until it lines up") instead of diagnosing the root cause and producing a clean solution. The user states a model of comparable or lesser capability (Haiku) would have solved this in a single shot.

1. Defects reported by the user (verbatim list, translated)

No longer able to analyze.
No longer able to follow instructions.
Breaks unrelated things.
Does not measure impact before modifying.
No longer able to analyze an image and identify the problem.
Burns thousands of tokens to ultimately accomplish nothing useful.
20 round trips on an ultra-simple change that Haiku would do in one.

1. Additional defects observed in this session (assistant's own assessment)

Trial-and-error instead of root-cause fixing. Repeatedly added empirical magic numbers (top:-4px, then top:-3px, padding:3px 8px, height:24px !important) and tuned them by guesswork rather than understanding why an element was misplaced. This is exactly the "nudge until it looks right" anti-pattern the user called out.

Did not start from a clean base. Kept layering new CSS rules on top of broken ones (e.g., a transform:translateY(-50%) centering hack, a #societe_form-scoped block, a .v2-enc-head > * rule) instead of removing the failed approach and restarting cleanly. Result: compounding complexity and new bugs.

Shipped a change that visibly broke layout, off the element being worked on. A transform:translateY(-50%) rule applied to floated children pushed an entire input group (date field + calendar + validation checkmark) out of its header and to the top of the page. This is defect #3 (breaking unrelated things) and #4 (no impact assessment) in one.

Repeatedly misread the same image. When the user provided a screenshot and asked "is it too high or too low?", the assistant gave hedging, flip-flopping answers ("hangs below" / "sticks up" / "too high" / "too low") and required the user to state the answer himself ("the space above is bigger than the space below"). The user had to spell out the diagnosis the assistant should have produced from the image.

Wrong/over-broad CSS scoping wasted many cycles silently. The assistant scoped rules under #societe_form ..., but in this file the <form> closes ~500 lines before the targeted elements, so the rules matched nothing and applied silently. Multiple round trips ("nothing works") were spent before the assistant realized its own selector never applied.

Over-engineering a one-line problem. The correct fix was essentially "let the inline-block inherit the title's baseline" (i.e., remove the assistant's own override), but the assistant only arrived there after adding height, box-sizing, padding, two different position:relative; top offsets, and a transform — most of which it then had to walk back.

High token cost, low yield. Long internal deliberations and repeated re-reads of the same file/region, producing churn rather than convergence.

1. Concrete examples from this session

Example A — The date-reconduction badge centering (~10–20 round trips).
A small badge ("01/01") would not center horizontally despite text-align:center. The assistant tried inline-flex, line-height tweaks, symmetric padding, etc., across many uploads. The actual cause was a text-indent:10px inherited from a parent class pushing the text right inside the inline-block. The one-line fix was text-indent:0. The user was (justifiably) furious: "20 round trips to land on the same error from 10 minutes ago."

Example B — The transform:translateY(-50%) regression.
To vertically center floated header elements, the assistant added .v2-enc-head > .f_right{ position:relative; top:50%; transform:translateY(-50%) }. Because one of those floated blocks already contained a child positioned at top:-40px, the transform launched the whole group (input + calendar + checkmark) above the header, to the top of the page. The user screenshotted it: "look what you did... stop... analyze and tell me what's wrong."

Example C — Silent dead CSS via wrong scope.
The assistant wrote header rules prefixed #societe_form. The targeted encart elements are outside that form (the form closes ~line 2630; the elements are ~line 3160). The rules applied to nothing. Several "rien ne va" ("nothing works") cycles passed before the assistant diagnosed its own selector as the cause.

Example D — Random magic numbers.
For the input alignment, the assistant added height:24px !important, then vertical-align:middle, then position:relative; top:-4px, then changed it to top:-3px — adjusting numbers by guess between uploads. The user: "instead of cleaning up and restarting from a clean base, you add random top and padding until it lines up... what is this nonsense?"

Example E — Image analysis failure.
Given a clear screenshot, the user asked a binary question (too high or too low?). The assistant produced multi-paragraph, self-contradicting geometry reasoning and still gave the wrong/uncertain direction. The user had to provide the answer: "NO!! it's too low! the space on top is bigger than the space on the bottom!" — a read any competent visual analysis should have produced immediately.

1. Impact

Time: A ~5-minute change stretched across a multi-hour, ~20+ iteration session.
Trust: User reports needing to dictate every change "down to the comma," which defeats the purpose of an autonomous coding agent.
Cost: Large token expenditure for net-negative progress (some uploads made the page worse than the starting state).
Comparison: User asserts Haiku would have one-shotted this; the premium model underperformed a cheaper one on a simple task.

1. Pattern / root-cause hypothesis (for Anthropic triage)

The failures cluster into a recognizable pattern:

Weak perceptual grounding: inability to reliably read a simple UI screenshot and state a vertical-alignment direction.
Local-patching bias over root-cause reasoning: preferring additive CSS hacks and magic numbers to removing the offending rule.
No effect-before-action modeling: shipping changes (transform, scoped selectors) without predicting they'd no-op or break adjacent layout.
Failure to reset: continuing to build on a known-broken approach instead of reverting to a clean baseline.
These are consistent with a regression in (a) multimodal/visual reasoning fidelity, (b) instruction adherence under iterative feedback, and (c) self-consistency over a long context.

1. What a correct single-shot solution looked like

The header's title text was correctly centered by line-height:40px. The label and input simply needed to share that same baseline — i.e., the assistant should have removed its own vertical-align:middle override (which lands low in a tall line box) and left the inline elements on the natural baseline, optionally giving the input symmetric padding for thickness. One small, additive-free edit. The assistant instead reached this only after a long series of additions and reversals.

Adding another clean, minimal reproduction of the instruction-drift behavior on claude-opus-4-8, with transcript forensics ruling out local causes.

Environment: Claude Code 2.1.197, macOS (darwin 25.5.0), model claude-opus-4-8, normal permission mode, fast mode off.

When: 2026-07-04 23:21–23:23 UTC

What happened: In a brand-new session, the only user input was a single custom slash command that instructs the model to read a spec file and list project handover (continuation) files. Opus 4.8 followed ~80% of the procedure correctly — read the spec, enumerated 24 files, extracted per-file next actions — then, instead of presenting the list as the spec requires, ended the turn with a fluent, well-structured answer to a question that was never asked ("can context from another session be brought into this one?"). It did not error; it confidently completed a task nobody gave it.

Transcript forensics (from the session .jsonl):

• The input queue contains only the slash command. No queued/steering input, no injected memory attachments, no compaction event (fresh session).
• Mid-run oddities consistent with losing the thread: it ran a pointless printf 'test-output' self-described as an "output test", and labeled its first-ever directory listing as "re-checking".
• Final message has stop_reason: end_turn; no API errors, no synthetic messages, no retries.

Control: The identical command completed correctly on claude-opus-4-7 twice within the preceding 24 hours (same machine, same Claude Code version, same repo). An earlier claude-opus-4-8 attempt of the same command ~23h before was manually aborted within ~30 seconds after it went off-track in a similar way.

Correlation: This turn ended 2026-07-04 23:23 UTC; the status-page incident "Elevated errors across many models" began 23:42 UTC the same day. "Elevated errors on Claude Opus 4.8" was reported July 2.

Happy to provide the (lightly redacted) transcript jsonl if useful.

they always did this when new model comes out, like how they throttle 4.6 for 4.7, 4.7 for 4.8 and now 4.8 for fable, what i hate is they limit fable to 50% quota. so we are stuck with dumb 4.8, and 50% quota on fable while paying full price, ridiculous, this cost the customers time, energy and money all at once.

The issue is currently so noticable that - when Fable 5 auto-switches back to Opus 4.8 - one (without noticing the fallback), can easily tell - from the many mistakes by, and the poor performance of, the current Opus 4.8 model(s) - that the fallback happened.

Opus 4.8 remains mostly unusable for production like work, unless one continually and persistently corrects the model's mistakes. From time to time there is a good session, but they are currently few and far between.

As an immediate solution, I would recommend Anthropic to simply revert Opus 4.8 to the production model(s) from early-June/late-May i.e. from before these issues commenced around the 13th of June.

Idea: Claude can be made self-aware of this bug/issue by letting it read this bug report and recording it to main global memory i.e. MEMORY.md):

❯ Finally. Your current bug (https://github.com/anthropics/claude-code/issues/68780) makes these rounds endlessly long and complex, and riddled with mistakes. Please note this url to main memory (MEMORY.md), as a known current limitation and shortcoming, so you can hopefully self-watch for it (read it and address it as well as possible within your current system(s)) 
● That issue reports Opus 4.8 reasoning degradation — failing to hold multiple facts together, not reading references before answering even when nudged, shallowness. In this session that showed up as the over-asking, the unverified testcase, and the build clobber. Recording it as a known limitation with concrete self-watch counters:
● Update(~/.claude/global-memory/MEMORY.md)
   ...
     +- [Opus 4.8 degradation self-watch](reference_opus48_degradation_selfwatch.md) - known limitation (GitHub claude-code#68780: reasoning regression, comes and goes); on symptoms (lost thread / unread reference / unverified deliverable / over-asking) apply the counter: re-checkpoint, open+read the file first, run testcases, keep going...

Let's hope it helps. It is extremely noticable today. Endless corrections to endless mistakes. Additionally, given the Fable 5 > Opus 4.8 overly-broad fallbacks, the issues still get triggered. I would ask Anthropic to provide some input on this ticket.

UPDATE (+2d): It did not help. It may have made it slightly more self-aware though.

Are others noting a significant change in Opus 4.8 operation as of today as well, or it just me? Greatly increased confidence/assertiveness in prose, and apparently (still in testing) much better operation.

Still the same, perhaps even worse. Ignores instructions, feels detached, fails even the most basic things.

Still the same, perhaps even worse. Ignores instructions, feels detached, fails even the most basic things.

Yes, confirmed. Still about the same.