Opus 5 is a regression

I've been using Opus 5 in Cladue code for about a month since I returned from summer holidays. Before that was using an older Opus model.

Opus 5 kinda sucks and I'm "not gonna take it anymore", problems:

• its slow 
• it goes down rabbit holes a lot more often and adds code which is not required
• code quality is not good enough
• it uses up the context window quickly past safe point ~60%
• it feels like its optimized to generate as much tokens as possible (good for Anthropic, not good for me)
• for some reason it adds significant useless code comments, when I asked does it know code comments best practices? Opus 5 confirmed it did but also admitted it did not follow. 

I talked with other engs and they all agree, same experiences. Most went back to 4.8 or switched to using Codex and Sol.

Google "Opus is bad" yourself and you'll see others having similar issues e.g. reddit post

I have made improvements to CLAUDE.md to instruct AI to:

• follow code comment best practices (but I should not need to do this!!)
• stick to the question at hand, not obscure edge cases
• be more concise and not generate plans until we finish our discovery cycle

I looked back over recent conversations and asked "I'm looking for recent conversations where you Claude Code spent too long doing something, or went down a "rabbit hole" or were too slow and I questioned you on it"

some examples as follows:

me 8/4: "what is the status? why taking so long?"       

Claude: You're right, and I should be straight about it: I re-derived your own doc's recommendation" 4 agents  and ~7 greps to reach a conclusion your retrospective already listed as recommendation #6     

me 8/4: "why so slow? has it really taken 32 mins ~85k tokens for this question? 

Claude:  "You're right — that was disproportionate. Two exploration passes for a question I could answer from the  "  two files you pointed me at. I've stopped; no more agents."             

me 8/6:  "I feel we're going around in circles… Clobber what edits exactly?"

Claude: "You're right, and my framing was misleading. The probe navigated to step 4 without saving — so it measured the Back path, not the forward one." The circling was my own bad measurement feeding the debate."

me 8/11: "three levels of indirection (in code) to answer 'is this toggle on?
Claude: You're right that it shouldn't look like this."

me 8/14: "why are you changing transformXYZDto and useABC.ts?"

Claude: "Good catch on the transformer — it doesn't need to change."

me 8/14: "the latest changes… look weird, why is it doing dirtyTabIds.map(...)"?
Claude: "You're right, and the complexity came from a wrong assumption of mine. I claimed the inactive tab's content leaves are unregistered… forcing a tab-subtree reset, which then dragged abcMode in and needed the pin-and-restore dance." Verified in RHF 7.62 that the premise was false — the whole dance was built on it.

Claude 8/12: "instead of removing it I explained it… a 6-line block comment justifying the component's existence. You concluded the component was over-engineering and deleted it. So the comment volume was a signal. When I need a paragraph to justify why a param or a layer exists, that's usually the design asking to be simplified, not documented." That one became the "Justifying vs documenting" section in apps-hospitality/AGENTS.md, origin note and all — the only pattern here with a durable fix in place.
The recurring shape: in nearly every case I built on an unverified premise (the probe measured the wrong path; leaves are unregistered; the transformer needs changing), and the complexity was downstream of that, not of the requirement. You caught it by asking why a specific line was necessary — which is faster than my own verification was."