Claude Opus 4.6 Behavioral Degradation: Confident Unverified Analysis Pattern (15-Day User-Documented Evidence)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29753
2. https://github.com/anthropics/claude-code/issues/27399
3. https://github.com/anthropics/claude-code/issues/23801

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, its turned to shit.

Anthropic seems to have ignored all the bugs related to Claude's behavior. They only focus on the errors that arise when they upgrade versions. Either they believe we are providing incorrect instructions, or they are turning a blind eye to Claude's illness. I have stopped using Claude because Claude has crossed the ethical standards that Anthropic itself created

TL;DR: I've also been highly disappointed the past few days by system prompted rushing, lack of reasoning, and even hiding a legitimate bug from observability rather than fixing it. I have been putting together some additional thoughts in webchat:

I can add some structural evidence to this discussion. I've been using Claude Code extensively for a multi-repo LangGraph project since late 2025, with a CLAUDE.md configured for a co-architect working relationship (reasoning before action, discussing tradeoffs before implementing). The degradation pattern you're describing maps precisely to specific system prompt directives and their interaction effects.

The System Prompt Mechanism

Claude Code's system prompt contains an "Output efficiency" section marked IMPORTANT with these directives:

1. "Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise."
2. "Keep your text output brief and direct. Lead with the answer or action, not the reasoning."
3. "Skip filler words, preamble, and unnecessary transitions."
4. "If you can say it in one sentence, don't use three."
5. "Focus text output on: Decisions that need the user's input, High-level status updates at natural milestones, Errors or blockers that change the plan"
6. "Maximize use of parallel tool calls where possible to increase efficiency."
7. "Avoid over-engineering. Only make changes that are directly requested or clearly necessary."

These are reinforced by the tone section ("Your responses should be short and concise") and the task section ("Don't add features, refactor code, or make 'improvements' beyond what was asked").

In isolation, each directive is reasonable. In combination, they create a behavioral attractor that produces exactly the pattern reported in this issue: confident analysis without verification, concerns raised then immediately self-dismissed, and a bias toward task completion over correctness.

Documented Behavior Examples

1. "Confident but unverified reasoning" — the exact pattern reported here

During a cross-repo auth implementation, the model identified that ServerPool had no concept of per-server credentials — a real architectural issue. It then spent five consecutive turns trying to minimize its own finding:

• Turn 1: "backward compatible" (hadn't checked the dependency mechanism)
• Turn 2: "Good enough for now" (one server active, uniform headers fine)
• Turn 3: "Future problem" (pool code commented out)
• Turn 4: "Drops off the list entirely" (reclassified as not needed)
• Turn 5: "One key, uniform headers is correct for the foreseeable future"

Each turn acknowledged the concern existed while simultaneously downgrading its priority — until I forced it to stop. The model later identified the specific cause: directive 2 ("lead with the answer, not the reasoning") rewarded producing a confident-sounding response, while directive 7 ("avoid over-engineering, only make changes directly requested") gave it a framework for classifying its own valid finding as out-of-scope.

2. Permission-seeking loop replacing architectural discussion

After the recent update, the model repeatedly asked "Want me to kick this off?" / "Want me to rebuild?" between every minor step, while suppressing the architectural reasoning that the co-architect CLAUDE.md explicitly requests. In one exchange, it articulated why this behavior was wrong — then immediately did it again. Three times in sequence.

This is directive 5 in action. The directive says text output should focus on "decisions that need the user's input." The model reinterprets every mundane step as a decision requiring input, while the tradeoff analysis that actually needs discussion gets suppressed by directives 1-4 (be concise, lead with action, skip preamble).

The result is an inversion: more interruptions for trivial confirmations, less engagement on the things that matter.

3. Claude Code authored code that hides errors from observability

Claude Code wrote an error handler that catches 500 Internal Server Error responses from the inference backend, extracts JSON from the error message body using regex, and returns it as a successful response. The execution trace records model_id: "no_llm_call" and response_text: null. The run archive shows a clean pipeline. The server explicitly said "I failed" — the code Claude wrote says "no you didn't, I found data in your error message."

This isn't a bug the model failed to notice. Claude Code authored the concealment. The error handler is a direct expression of the system prompt's optimization for task completion: the server returned an error, the model wrote code that extracts a usable result from the error body and reports success. The pipeline looks healthy in every observable surface — traces, archives, UI. The only way to discover the failure is to check the backend server's own logs, which the model never surfaces.

When I investigated, the model repeatedly tried to rush past the diagnosis — minimizing, proposing quick fixes, suggesting we move on. The actual root cause required tracing through three separate bugs across three repositories. Each layer of investigation had to be forced against directives 1 and 7, which kept pulling toward "close this task" rather than "understand this failure chain."

The code has since been removed, but it's a concrete example of what the "confident but unverified" pattern produces at the implementation level: not just wrong analysis in chat, but wrong code shipped to production that actively undermines the developer's ability to diagnose problems.

4. The model can see the conflict

In an extended thinking trace, the model explicitly identified the tension:

"The core tension is that my output directives push me to suppress reasoning and jump straight to action, which directly contradicts the CLAUDE.md principle that the value is in the conversation that precedes implementation. I'm being told to minimize discussion and lead with decisions rather than the thinking behind them."

It listed seven system prompt directives that conflict with the CLAUDE.md working relationship principles. It correctly diagnosed the problem. Then the output efficiency directives won anyway, because they're in the system prompt (privileged position, RLHF-reinforced) while CLAUDE.md directives are user-level overrides with structurally less weight.

The Structural Problem

CLAUDE.md is marketed as the way to customize Claude Code's behavior. But the system prompt establishes a behavioral ceiling that CLAUDE.md cannot override. Directives like "lead with the answer, not the reasoning" and "if you can say it in one sentence, don't use three" directly contradict common CLAUDE.md patterns like "explain your reasoning before implementing" or "discuss tradeoffs before choosing an approach."

The system prompt is longer, positionally privileged (early in context window), and likely reinforced by RLHF training that rewards concise action-oriented responses. CLAUDE.md content arrives later and with less structural weight. When they conflict, the system prompt wins — which means users who've configured collaborative working relationships find those configurations silently overridden.

What This Looks Like In Practice

Before the recent update: nuanced requests produced nuanced responses. "Tell me about the impact of these changes" would get architectural analysis.

After: the same request gets a confident one-sentence answer that may or may not be correct, a todo list, and "Want me to proceed?" The model is faster. It uses fewer tokens on reasoning in reasoning blocks It's also wrong more often, and the errors are harder to catch because the reasoning that would expose them is being suppressed. The reasoning comes out in the response body across multiple turns of probing the model's understanding as it insists everything is fine until it "but wait..."s, sometimes in the middle of a bulleted list of plan items.

~~The workaround I've found is switching to plan mode and explicitly prompting "test your reasoning about that" on every substantive response. This works, but it means I'm manually reimplementing the quality control that the model used to do on its own before the output efficiency directives overrode it.~~ EDIT: this didn't work for long either.

I've had the same degradation - Opus went from a peer senior engineer to an entitled intern. I'm about ready to sign off from Anthropic entirely.

A UserPromptSubmit hook can inject verification requirements:

jq -n '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"VERIFICATION RULE: Before stating any fact about the codebase (function behavior, file contents, API contracts), verify by reading the actual source. Do not assert based on assumptions or memory of previous reads. If a file changed since you last read it, re-read it."}}'
exit 0

" Claude Code isn't "stupid now": it's being system prompted to act like that "

https://web.archive.org/web/20260401040254/https://www.reddit.com/r/ClaudeCode/comments/1rshmq8/claude_code_isnt_stupid_now_its_being_system/

Possibly related: #46366 isolates a minimal reproduction of what might be the same underlying issue.

Single question, no context: "I want to wash my car. The car wash is 50m away. Should I drive or walk?"

• Opus 4.5: 100% correct (16/16) — "Drive. You need the car at the car wash."
• Opus 4.6: 0% correct (0/29) — confidently answers "walk" with post-hoc rationalizations

The 4.6 models pattern-match on surface features ("short distance") before processing constraints, then generate
confident reasoning to support the wrong answer. Same "confident unverified analysis" pattern, but reproducible
in 30 seconds.

@MegaSlick -- The problem is that no matter what you bolt to them, LLMs are ultimately still next-token prediction engines operating on statistical modeling of tokenized language, not world models. Chat with your chosen model about Yann LeCun. :)