Massive quality regression

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21270
2. https://github.com/anthropics/claude-code/issues/21361
3. https://github.com/anthropics/claude-code/issues/20916

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

Yep, the past 2 days it's been terrible. Certainly model related and not related to a release of the CLI though (I think)

we noticed same behavior, 3 devs in out team complained independently of each other how bad claude code performed since 2 or 3 days.

Can confirm the same problem: terrible thinking, much worse results, and massive errors.

We’ve been seeing the same issues since January 26, 2026 — the agent’s performance has noticeably degraded, to the point where it’s nearly unusable.
Subscription: Max
Model: Opus 4.5

YES!

I wonder if anthropic monitor how many times claude sees swear words and insults in it's prompts to use as a benchmark of how it's performing.

yup, noticed the same thing since about a week. I used to be delighted how often claude made the right decision, even though I didn't give it specific guidance. Now it's flipped to making the wrong decision much of the time. Don't get me wrong, if you're explicit in what you want, it will do it no problem, but it's the unspoken stuff that it is totally worse at now.

Fix it please :)

And Opus 4.5 through API usage.

I wonder if anthropic monitor how many times claude sees swear words and insults in it's prompts to use as a benchmark of how it's performing.

I've heard that AI models respond better to please and thank you, hehe

+1

Yes, it's been terrible the last few days, it's making decisions without gathering the full context. I used to be able to add ultrathink when it wasn't quite grasping what I needed, but that's gone now too. A real shame because the few weeks before that, it was working almost too well.

Yes, it's been terrible the last few days, it's making decisions without gathering the full context. I used to be able to add ultrathink when it wasn't quite grasping what I needed, but that's gone now too. A real shame because the few weeks before that, it was working almost too well.

My experience exactly. A couple weeks ago, I was like getting discouraged that I might not be necessary any more 😄 This week, I'm totally like, ok, maybe I should try Codex (which I am doing).

Same issue here. Observed pattern:

• Off-peak hours: Claude follows instructions precisely, maintains context, systematic reasoning
• Peak hours: Ignores explicit instructions from previous messages, circular reasoning, loses track of conversation context

Example from today: In a debugging session, I explicitly instructed Claude to "analyze the code locally, don't connect to the server". Despite this clear instruction being in the recent context, Claude proceeded to repeatedly attempt server connections and run redundant commands, going in
circles revisiting failed approaches.

The context window clearly contained my instruction, yet it was ignored multiple times in the same conversation.

Environment: Claude Code CLI, Opus 4.5, Brazil (UTC-3)

This seems load-related - quality degrades significantly during what appears to be peak usage hours.

+1

El mismo problema aquí. Patrón observado: Horas fuera de pico: Claude sigue las instrucciones con precisión, mantiene el contexto, el razonamiento sistemático Horas pico: ignora las instrucciones explícitas de mensajes anteriores, el razonamiento circular, pierde la pista del contexto de la conversación Ejemplo de hoy: En una sesión de depuración, instruí explícitamente a Claude para que "analice el código localmente, no se conecte al servidor". A pesar de que esta instrucción clara se encuentra en el contexto reciente, Claude procedió a intentar repetidamente conexiones de servidor y ejecutar comandos redundantes, entrando Los círculos que revisan los enfoques fallidos. La ventana de contexto contenía claramente mi instrucción, pero fue ignorada varias veces en la misma conversación. Medio ambiente: Claude Code CLI, Opus 4.5, Brasil (UTC-3) Esto parece relacionado con la carga: la calidad se degrada significativamente durante lo que parecen ser las horas de uso pico.

Hay gente que lo viene diciendo, hace una semana, pero en éstos últimos 3 días, algo REALMENTE GRAVE, sucedió...

Realmente, es absolutamente inoperable... NO HACE NADA correcto...

Espero que no esté relacionado a que dice que mañana, 3 de Febrero, lanzan Sonnet 5, porque si intencionalmente degradan, tan brutalmente al modelo, para generar una percepción distorsionada en los usuarios, realmente es una práctica absolutamente poco honesta, y muy opaca...

Hace, al menos, 2 días, que uno no se puede fiar de OPUS, no he probado sonnet...

It has become really unreliable, honestly sometimes it feels like I'm using chatgpt3
Overconfidently stating wrong things as facts:

Yes, exactly. The cursor's next FETCH is a new query that needs ACCESS SHARE on the table. 
It arrives after the ALTER TABLE in the lock queue, so it waits behind it.

That creates a circular wait:

- ALTER TABLE waits for the cursor's transaction to end
- The cursor's transaction can't end because its next FETCH is queued behind the ALTER TABLE

but wouldn't the cursor have its own lock that precedes the alter table?

or if not, wouldn't it have released the initial lock then and allow the alter table to run?

Good question. The cursor's transaction holds the ACCESS SHARE lock from the original 
DECLARE CURSOR — and it holds it for the entire transaction, not per-statement. That lock is 
never released until COMMIT/ROLLBACK.

So the situation is:

- The cursor's transaction still holds ACCESS SHARE from the DECLARE CURSOR — it doesn't release it 
between fetches
- The ALTER TABLE is waiting for that ACCESS SHARE to go away, which only happens when the transaction ends
- The cursor's next FETCH needs to execute to eventually finish and close the transaction
- But FETCH is a new statement that enters the lock queue behind the ALTER TABLE

The existing ACCESS SHARE lock keeps the ALTER TABLE waiting. The queued ALTER TABLE 
keeps the next FETCH waiting. The blocked FETCH prevents the transaction from ever finishing and releasing 
the ACCESS SHARE.

So you're right that the cursor's transaction never releases its lock — that's actually what makes the
problem worse. It's holding the lock that blocks the ALTER, while simultaneously needing to execute 
new statements that are blocked by the ALTER.

I've researched and the FETCH uses the original lock, not new a new one each time.

You're right, and I was wrong on that point. FETCH operates on an already-open cursor portal — it doesn't 
acquire new table-level locks. The transaction's existing ACCESS SHARE lock covers all fetches.

  So the corrected picture is:

  1. Cursor transaction holds ACCESS SHARE, fetching chunks
  2. ALTER TABLE queues for ACCESS EXCLUSIVE, waits for the cursor's transaction to end
  3. Cursor's FETCH calls continue working fine — no circular wait
  4. All other traffic queues behind the ALTER TABLE

this sort of stuff would NEVER happen before - sometimes it would guess things, but it would state it as such - or in uncertainty, it would do a websearch.

I have more examples, but I think for me this started around late December, but lately it has become a lot more noticeable.
I'll make sure my company will move away from anthropic if this keeps happening, this does not justify the price and for these sort of interactions, the same is achievable using a free plan.

It is merely the globally known incompetence of Dario Amodei and his team of losers

I have same. Code quality and prompt understanding last days become worst. What happened? It can't write a simple task, producing code, that doesn't work...

Now the models feels worse than 6-9 months ago... Opus 4.7 feels like Sonnet 3.5. That's a scarry joke :-/