The cost of non-compliance: a paying customer's documentation of systemic model failures

Open 💬 1 comment Opened Jul 1, 2026 by nvst18

This is not a bug report. This is a pattern.

I have filed 9 issues on this repo over the past 6 weeks. Every one documents the same root cause: Claude Code models do not follow their own loaded instructions.

  • #72651 — Model ignores CLAUDE.md instructions to research before infrastructure actions
  • #72655 — Community-built runtime enforcement hooks (because the model won't self-enforce)
  • #66143 — Model forgets known facts across sessions despite memory system
  • #66054 — Model claims work is done without verifying
  • #66050 — Model refuses to follow explicit instructions
  • #66049 — Model refuses to use available tools when explicitly instructed
  • #62571 — Feature request for model-version pinning (auto-closed as "stale")
  • #61167 — Opus 4.7 fabricates agent dispatches (13 comments, community-verified)
  • #61107 — Opus 4.7 produces code that silently discards user input (auto-closed as "stale")

What happens to these issues

  1. Bot flags them as duplicates of other unfixed issues
  2. Bot auto-closes them for "inactivity" after 3 days
  3. Issues get the "stale" label and locked closure ("NOT_PLANNED"), preventing reopening
  4. No Anthropic engineer has responded to any of them

The auto-close bot is doing the work of making these problems disappear without fixing them. Real issues with community engagement (#61167 has 13 comments and independent verification from multiple users) get the same treatment as spam.

The actual cost

Each model failure costs real time and real money:

  • 4 failed Cloud Run deploys because the model wrote infrastructure code without reading the platform docs, despite CLAUDE.md explicitly requiring research first
  • 3 wasted GCP VMs because the model didn't read adapter_config.json before writing merge scripts, despite a memory file and CLAUDE.md rule requiring it
  • Hours of debugging phantom agent dispatches where the model claimed it dispatched work that never happened (34% fabrication rate, independently measured)
  • Repeated correction cycles where the model acknowledges a rule, agrees to follow it, then ignores it on the next action

I have built CLAUDE.md rules, memory files, correction feedback, and now runtime enforcement hooks to compensate for the model not doing what it is told. Each layer exists because the previous one failed. The hooks work, but I should not have to build a harness-level seatbelt interlock because the driver refuses to wear the seatbelt.

What I am asking for

  1. Stop auto-closing issues that document real, reproducible failures. If 5 issues describe the same root cause, that is evidence of a systemic problem, not a reason to close 4 of them.
  1. Have a human respond. Not a bot. Not a "stale" label. An engineer who can say "we are aware of this" or "we are working on it" or "we will not fix this." Any of those is better than silence.
  1. Fix the root cause. The model has loaded instructions. It acknowledges them. It ignores them. This is not a prompting problem. This is not a user error. This is the model not doing what it is told to do, reliably and repeatedly, across Opus 4.5, 4.6, and 4.7.
  1. Ship enforcement as a first-class feature. If the model cannot self-enforce behavioral constraints, give users a supported mechanism to enforce them at the harness level. The hooks API exists but is undocumented and unsupported. Make it real.

I am a paying customer. I am building a product on this platform. I have spent more time filing issues and building workarounds than I have spent on my actual product this week. That is not sustainable.

— Nofyah

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗