[Bug] Model performance degradation: Claude 5.5 Opus quality regressed to Opus 5 level

Additional data point: this looks like a Claude Code client regression, not a server-side model change. Rolling back the client restores quality.

Environment

• Model: Opus 5.5, effort medium (unchanged throughout)
• Same CLAUDE.md, same hooks, same settings throughout
• Platform: Windows 11 Pro (10.0.26200), VS Code 1.140.0, Claude Code VS Code extension (win32-x64): 2.1.287 → 2.1.289 (auto-update), rolled back to 2.1.287

Timeline (JST, from session transcript logs)

| Date | Version | Median thinking per turn |
|-------|---------------------|--------------------------|
| 10/3 | 2.1.280 → 2.1.287 | 148 |
| 10/4 | 2.1.287 | 196 |
| 10/5 | 2.1.287 → 2.1.289 (switched 17:04) | 158 |
| 10/6 | 2.1.289 | 63 |
| 10/7 | 2.1.289 | 101 |

(Thinking measured as thinking tokens (usage.output_tokens_details.thinking_tokens) per assistant turn, median per day. Main-thread turns only, subagents excluded; turns with zero thinking included.)

Observed on 2.1.289

• Noticeably faster responses with much shallower reasoning
• Ignores parts of instructions and pushes ahead to "finish" tasks instead of following what was asked
• Raising effort to high did not fix it

Rollback

• Reinstalled 2.1.287 with auto-update disabled → quality returned to the 10/4 level on the same repository and the same kind of task.

Note: this install jumped from 2.1.287 straight to 2.1.289, so the change may have come in 2.1.288 (which changed how output limits / auto-compact window are taken from the server, among other things). I haven't bisected 2.1.288 itself.

I have also experienced sustained degradation in Claude Code, documented in my own report #100748 with dated examples from September through 9 October. The overlapping symptoms are ignored constraints, confident incorrect assertions, and sessions consumed correcting the assistant rather than completing the requested work.

I cannot confirm the specific version regression or rollback result described here. I am adding my independent experience of the quality problem, not claiming its technical cause has been established.

Adding dated cases. Same pattern across two harnesses on separate accounts, both Opus 5.5 at effort high:

• Claude Code 2.1.296 (personal Max account, macOS)
• OpenCode (separate enterprise account, Windows)

So this doesn't look like a Claude Code client issue or the medium-effort default.

The common pattern: the model acts on its own summary of the situation instead of checking the source, asks for approval without waiting for the answer, and breaks rules that are already written in its loaded context. In every case below, the model admitted the failure in its own words afterwards.

11–12 Oct 2026

1. Ignored a documented rule (Claude Code, ~01:00). It ran a judged generation batch against GLM 5.3 with think: false. Two memory files loaded in context say GLM 5.x ignores think:false and leaks its reasoning into the reply, and one of them records an earlier run lost to the same mistake. As a result, all 180 replies were void: the reasoning was cut off at the token cap, and the judges scored the reasoning instead of the answers.
2. Reported results without reading the data. It presented GLM figures as findings without having opened any of GLM's replies.
3. Asked for approval but didn't wait (Claude Code, ~01:41). One message included a "Need from you: should I rerun…?" question and also said the rerun was already running. In total it launched about 1,000 cloud calls without approval. Around 10% of the weekly allowance was used before the user stopped it.
4. Phantom question. It asked the user why they hadn't answered a question it had never actually sent. The question appears to have existed only in its reasoning.
5. Unverified premise, stated confidently (OpenCode, 14:13). It recommended the same option twice, assuming a deployment wasn't live without checking it. It reversed when challenged and said: "I recommended (a) twice based on an unchecked premise."
6. Skipped a required source (OpenCode, 16:18). The project's AGENTS.md requires reading a state-of-play file before this kind of work. It read the handover file and the task cards instead, then planned to "collect requirements" for work that was already live. Its own admission: "No, I didn't, and I should have. AGENTS.md says to read it before any merge-related work."

Baseline: the same setup worked last week. Same harnesses, same effort, same memory files and AGENTS.md rules. For example, on 4 Oct the same Claude Code agent ran the same kind of GLM 5.3 batch correctly, with thinking on, as the notes require (logged in the project's action log at the time). None of the failures above appeared in the prior week's work. They cluster on 11–12 Oct, at a rate of 6+ in one day. Transcripts aren't attached because they contain private and employer data. These are summaries of what each session admitted.

_Summarised with Claude from the session records, at the reporter's request._