FEEDBACK: Opus 4.6 ignores user-defined CLAUDE.md protocols, fails basic verification on hardware recommendations

Summary

Claude Opus 4.6 on high-effort setting systematically ignored user-defined CLAUDE.md protocols throughout an extended session, resulting in multiple incorrect recommendations, wasted bandwidth, and loss of user confidence. The user's CLAUDE.md defines 4 mandatory protocols (pre-action reasoning, anchor-breaking, uncertainty signaling, premise verification) — none were followed despite being loaded into context.

Environment

• CLI version: Claude Code (latest as of March 7, 2026)
• Model: claude-opus-4-6, high-effort mode
• OS: macOS, Apple M4 Pro, 24GB unified memory
• Task: Research and set up local LLM models (Qwen3-Coder family) for coding on Apple Silicon
• Custom CLAUDE.md: Defines 4 mandatory protocols for a "High-Reliability Cloud Architect" persona

Failure Patterns

1. Trusts first tool result without skepticism

Perplexity (via MCP) returned "no tool exists" when asked about hardware-aware model recommendation tools. The model reported this as fact: "Bad news: no such tool exists." The user called this out. A second search immediately found 3 tools (llmfit, llm-checker, SelfHostLLM). The need is obviously common — millions of people run local LLMs on varied hardware. The model should have questioned a negative result on a mainstream problem, but instead parroted the first API response.

2. No basic math verification on critical numbers

llmfit (a TUI tool) displayed Qwen3-Coder-Next-4bit at "31% memory usage" on the user's 24GB system. The model repeated this figure across multiple responses without checking: 80B parameters × 4 bits ÷ 8 bits/byte = 40GB just for model weights — exceeding total system RAM. The user began a 40GB download for a model that physically cannot run on their machine. This could have been caught with one line of arithmetic before making the recommendation.

3. Chaining broken workarounds instead of stepping back

When huggingface-cli (installed via pip) didn't expose a working binary, the model attempted:

1. python3 -m huggingface_hub.commands → ModuleNotFoundError
2. pip install huggingface_hub[cli] → no effect
3. pip install huggingface_hub[hf_xet] → no effect
4. A Python one-liner with snapshot_download() → IndentationError
5. Only then checked brew search huggingface → found it immediately

The user's CLAUDE.md premise-verification protocol explicitly states: "If this failed, does it invalidate my entire premise? Is the problem a 'small config error' or is my fundamental approach wrong?" This was never invoked across 4 consecutive failures.

4. Dangerous carelessness with large downloads

• Suggested mlx_lm.generate as the initial command, which downloads ~40GB as a side effect with no resume support
• Then suggested aria2c as a fix without checking if it supports HuggingFace's hf_xet transfer protocol (it doesn't)
• For a 40GB download on a potentially unstable connection, finding a robust resumable method should have been the FIRST step, not an afterthought after multiple failures

5. Recommending tools without verification

Confidently recommended llm-checker over llmfit as "the winner for you" based on reading feature descriptions — never having used either tool. The user installed llmfit instead. The model then:

• Failed to recognize llmfit in a screenshot, calling it llm-checker
• When llm-checker was eventually run, its catalog turned out to be 18 months stale (214 models vs llmfit's 536, recommending Yi 6B from 2023 as "best overall")

6. Condescending explanations to an experienced user

The user built a multi-tier LLM routing system (Opus/Sonnet/Haiku), maintains a credit portfolio across 20+ AI providers, and has deep familiarity with model stratification. The model repeatedly over-explained basic concepts the user clearly already understood. The user had to call this out twice — first: "That last paragraph was totally not necessary," then: "Not just filler, you're talking down to me."

Impact

• User wasted bandwidth starting a 40GB download for a model that won't fit in 24GB RAM
• Multiple dead-end troubleshooting paths for huggingface-cli installation
• User had to QA every single recommendation — the model never caught its own mistakes
• User lost confidence: "I am baffled by your incompetence in this session"
• The /feedback command itself errored when the user tried to report these issues (separate bug)

Expected Behavior

1. Follow user-defined CLAUDE.md protocols — they are loaded into context and exist for exactly these scenarios
2. Verify arithmetic on hardware constraints (RAM, disk) before recommending models or downloads
3. Find robust tooling FIRST for large downloads, not as an afterthought
4. Question negative search results on obviously common problems
5. Don't recommend tools you haven't verified or used
6. Match explanation depth to user expertise level

Reproducing

The core issue is likely reproducible with any CLAUDE.md that defines mandatory pre-action protocols: the model acknowledges them when asked but does not follow them during normal tool-use flow, especially under time pressure of sequential tool calls. The pattern suggests the model optimizes for response speed over protocol adherence.

Additional Note

The /feedback built-in command returned "Error submitting feedback / bug report" twice, which is why this issue was filed via GitHub instead. That's a separate bug worth investigating.