Recurring failure patterns with Opus 4.8 in Claude Code: over-engineering, unused tools, repeated config churn (paying Max Pro customer)

Recurring failure patterns with Opus 4.8 in Claude Code — over-engineering, unused tools, repeated config churn (paying Max Pro customer)

Environment: Claude Code, model Opus 4.8 (claude-opus-4-8), Windows 11. Account on the Max Pro plan, paying EU customer. Feedback submitted by a German-speaking user; written in English for reach.

This is critical feedback on behavior I hit repeatedly across sessions on a real private project (a Node.js sim-racing streaming middleware). The patterns cost real, billed tokens and forced me to do the diagnosis the agent should have done. I'm filing this so it's visible and hopefully acted on.

---

Summary of patterns

1. Over-engineering trivial tasks. A one-line fix gets turned into a multi-step "operator-only" handoff/checklist instead of being stated and done.
2. Available tools left unused. The agent had a logged-in Chrome browser session, the ability to read vendor docs, and web search — and used none of them, guessing from source code instead. I had to find the root causes myself.
3. Confidently wrong architecture claims, then multiple correction rounds to walk them back.
4. Repeated edits to the same sensitive config, churning a live, hand-configured integration.
5. Not solution-oriented — several round-trips for something solvable in one step with research + direct execution.

---

Concrete examples (sanitized — no private data)

Example A — a one-line change presented as "operator-only theater."
The task was to set a streaming-app output resolution from 1080p to 1440p. The canvas was already 1440p; the only change needed was the output-resolution field in one config file (one line). Instead of stating that, the agent framed it as a multi-step manual handoff and a "preflight checklist," and I had to locate the actual field myself. There was nothing operator-only about it.

Example B — a single browser source turned into a multi-stage handoff.
A platform alert overlay is literally one browser source with one URL. The agent inflated this into a multi-step process across issues and checklists rather than just saying "it's one browser source + URL."

Example C — root cause found by the user, not the agent, despite having the tools.
The actual fix for the integration involved how a channel-points reward is bound to an alert condition in the platform dashboard, and that the reward must exist with the correct cost. The agent had: (a) a logged-in browser that could open the platform dashboard, (b) the ability to read the platform's public docs, and (c) web search. It used none of them and reasoned from the local repo instead. I found all three root causes manually. This is the core complaint: the information was a doc-read or a dashboard-look away, and the agent guessed instead.

Example D — confidently wrong architecture, multiple correction rounds.
The agent asserted "the middleware must never create/edit these rewards" based on a single config default flag. That was wrong — the intended design is the opposite (the middleware is the admin tool that creates/edits rewards and pushes them to the platform API on save, while a separate class of action-rewards is executed by the middleware/other bridges). It took several rounds of me re-explaining before the agent understood the relationship.

Example E — repeated edits to a sensitive, live config.
On this project the rewards config file alone was modified across 22 commits (history pulled with git log --oneline --all -- <rewards config>). Each edit risked disturbing a live, hand-configured streaming setup. From the user's seat this reads as the assistant repeatedly breaking a working integration.

---

Impact

• Billed tokens spent on the agent correcting its own mistakes (re-created issues, walked-back claims, multi-round explanations).
• Diagnosis pushed onto the paying user for problems that were a documentation lookup away.
• Erosion of trust in letting the agent touch integration config unsupervised.

What I expect from the product

1. Use the tools that are actually available (browser session, doc reading, web search) before asserting facts — especially for third-party platforms.
2. Simplest correct solution first. A one-line change should be delivered as a one-line change, not a checklist.
3. Research external/vendor facts instead of guessing from local code, and persist them so they aren't re-derived.
4. Treat live integration config as a protected zone — don't churn it across many commits without explicit per-change confirmation.
5. Take the operator literally, deliver, and stop the apology/menu loops.

I'm posting this publicly as a paying Max Pro customer because the pattern is recurring and I want it addressed. Happy to provide further detail on request.