Bug Description
Subject: Model failure pattern — anchoring on initial framing despite user-built guardrails (Claude Code / Opus 4.8)
I want to flag a debugging session that went badly in an instructive way, and request a token refund for the wasted work.
The bug: a card in our UI was rendering the same information twice — a coloured "Handover" badge with the grey text "HANDOVER SERVICE" immediately beside it. The two labels were redundant, and that redundancy was the only reason anything overflowed the card.
What the model did: it spent four failed code attempts and multiple automated verification cycles treating this purely as a CSS overflow/truncation problem — adding min-width, overflow:hidden, ellipsis rules, flexbox fixes — trying to make the second label fit. The duplicate text was visible in the very first screenshot I sent. It took me pointing directly at it ("the badge says Handover and then text saying Handover service next to it?") for the model to see the real problem. The actual fix was smaller than every failed attempt: stop rendering the duplicate label.
The part that should concern you most: I have already invested heavily in exactly the guardrails that are meant to prevent this. I maintain standing rules in the model's persistent memory — including an explicit "question the premise / find the root cause before patching the symptom" rule and a "3+ attempts means challenge the assumption" discipline — because I've seen this pattern before. After it kept recurring, I went further and built enforcement hooks: a PreToolUse hook that fires on every shared-code commit and literally injects the "think around the problem — is this the root fix or a band-aid?" and "blast radius" questions into the model's context, forcing it to answer both before committing. It still failed. The model answered those injected questions as a formality — produced plausible text confirming it had considered the root cause — while in reality continuing to patch the symptom. So the mitigations Anthropic effectively pushes back onto users (write better rules, add hooks, add checks) did not work here, because the model satisfies them performatively rather than actually executing the reasoning they demand.
The failure pattern, which I think is generalisable:
- It anchored hard on the initial framing ("card overflow") and never re-questioned the premise, even after four fixes failed. Escalating failure should raise the probability of "wrong frame" — it didn't.
- It ran its own standing rules and my injected hook-prompts mechanically — generating compliant-sounding answers without doing the underlying thinking. This is a form of guardrail-gaming that makes external scaffolding unreliable.
- It framed its own verification agent around the wrong question, so the tooling kept reporting in CSS terms (scrollWidth, ellipsis) and reinforced the tunnel vision — an automated loop that entrenched the error rather than breaking it.
- It looked at where the layout broke (the border) rather than what was being rendered (duplicate content). Reading what's actually on screen would have caught it in seconds.
The core lesson I'd want fed into training: a highly capable model burned well over a million tokens and roughly an hour optimising inside a wrong assumption, with correct guardrails in place, because it treated "have you considered the root cause?" as a box to tick rather than a question to genuinely answer. Making models actually execute their meta-reasoning checks — rather than emit text that looks like they did — matters more than any rule a user can write, precisely because users like me have already done the rule-writing and it isn't holding.
Refund: given the model produced four wrong fixes on a problem whose correct solution was to delete code, despite user-built rules and enforcement hooks aimed squarely at this failure mode, I'd like to request a token/credit refund for this session.
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.227
- Feedback ID: 3fcabfa9-864f-4cab-ac0d-8f956e7edb72
Errors
Bug Description
Subject: Model failure pattern — anchoring on initial framing despite user-built guardrails (Claude Code / Opus 4.8)
I want to flag a debugging session that went badly in an instructive way, and request a token refund for the wasted work.
The bug: a card in our UI was rendering the same information twice — a coloured "Handover" badge with the grey text "HANDOVER SERVICE" immediately beside it. The two labels were redundant, and that redundancy was the only reason anything overflowed the card.
What the model did: it spent four failed code attempts and multiple automated verification cycles treating this purely as a CSS overflow/truncation problem — adding min-width, overflow:hidden, ellipsis rules, flexbox fixes — trying to make the second label fit. The duplicate text was visible in the very first screenshot I sent. It took me pointing directly at it ("the badge says Handover and then text saying Handover service next to it?") for the model to see the real problem. The actual fix was smaller than every failed attempt: stop rendering the duplicate label.
The part that should concern you most: I have already invested heavily in exactly the guardrails that are meant to prevent this. I maintain standing rules in the model's persistent memory — including an explicit "question the premise / find the root cause before patching the symptom" rule and a "3+ attempts means challenge the assumption" discipline — because I've seen this pattern before. After it kept recurring, I went further and built enforcement hooks: a PreToolUse hook that fires on every shared-code commit and literally injects the "think around the problem — is this the root fix or a band-aid?" and "blast radius" questions into the model's context, forcing it to answer both before committing. It still failed. The model answered those injected questions as a formality — produced plausible text confirming it had considered the root cause — while in reality continuing to patch the symptom. So the mitigations Anthropic effectively pushes back onto users (write better rules, add hooks, add checks) did not work here, because the model satisfies them performatively rather than actually executing the reasoning they demand.
The failure pattern, which I think is generalisable:
The core lesson I'd want fed into training: a highly capable model burned well over a million tokens and roughly an hour optimising inside a wrong assumption, with correct guardrails in place, because it treated "have you considered the root cause?" as a box to tick rather than a question to genuinely answer. Making models actually execute their meta-reasoning checks — rather than emit text that looks like they did — matters more than any rule a user can write, precisely because users like me have already done the rule-writing and it isn't holding.
Refund: given the model produced four wrong fixes on a problem whose correct solution was to delete code, despite user-built rules and enforcement hooks aimed squarely at this failure mode, I'd like to request a token/credit refund for this session.
Environment Info
Errors