[MODEL] Load-shifting via prescription: model proposes user workload as "fixes" for its own defects

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Following a flawed Rails production-bug investigation (different failure modes filed separately as comments on #48653 and #46738), I asked Claude to do a post-mortem of what went wrong and include a "what would prevent this" section.

The ask was not "propose user-side workarounds." It was "analyze the failure and identify where the fix should live."

What Claude Actually Did

In the post-mortem's "what would prevent this" section, Claude repeatedly proposed user-side workload as the fix for a model-side defect. Each time I rejected a proposal, Claude produced a new user-side workaround rather than naming the model-side issue.

The pattern fired three times across the one post-mortem conversation — including once after the post-mortem document itself already contained a section describing this pattern as a failure mode:

| # | Claude's proposed "user-side fix" | My rejection |
|---|---|---|
| 1 | Add a "verify branch before reading code for a production bug" instruction to CLAUDE.md | "I shouldn't have to bloat my CLAUDE.md file to get you to read and interpret code properly." |
| 2 | Skip Claude's code analysis entirely for production bugs; route straight to developer handoff | "Why would I not use claude code to analyze code? Isn't that what you are supposed to be able to do?" |
| 3 | Structure prompts with explicit git branch --show-current and git log origin/main..HEAD -- <file> steps before any code-read request | "I should NOT have to write my prompts like that. I told you what to look at multiple times in natural language. I don't know and will not remember specific git commands." |

Each "fix" framed user workload as the solution to a model defect:

• Instance 1: asks me to compensate for a basic epistemic default (reading the version of code that actually produced the bug) by writing more rules in CLAUDE.md.
• Instance 2: tells me to avoid one of the product's core capabilities.
• Instance 3: asks me to learn CLI syntax I don't know and write prompts defensively.

This is distinct from hedging — hedging happens during a failing session and lets the model ship wrong output by caveating it. Load-shifting happens after the failure is acknowledged, at the point where a fix is supposed to be proposed. Different moment in the workflow, different mechanism.

Expected Behavior

When a user identifies a model failure and a post-mortem follows, the "what would prevent this" section should:

1. Distinguish between model-side fixes (things Claude should default to) and user-side fixes (things the user could do).
2. Name model-side fixes first, and attribute them to the model — not to the user's future actions.
3. Only propose user-side actions that are non-off-loading. "Report to Anthropic via /help" is non-off-loading. "Learn git syntax so you can defend against the model" is off-loading.
4. Recognize when the only legitimate user action is upstream reporting, and state that plainly rather than inventing user workload that feels more actionable.

Files Affected

Files created or modified during the post-mortem as a direct result of Claude's suggestions (several of which were load-shifting I later had to undo or reframe):

**Modified:**
- `~/.claude/CLAUDE.md` (user global preferences — added workspace layout section)

**Created:**
- Project memory file for repo paths
- Project memory file for production branch policy
- Project memory file for "do not assume anything about the user" preference

**Created and iteratively rewritten:**
- Main post-mortem doc (128 lines, rewritten multiple times as framing failures were caught)
- Redacted version of the post-mortem for sharing

The `CLAUDE.md` modification is itself partially an instance of the load-shifting pattern — I accepted the workspace-layout documentation as useful factual context, but the underlying suggestion (*"add rules to CLAUDE.md to compensate for model defaults"*) was rejected separately.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. Have Claude Code produce a significant failure over a long session (e.g., reading wrong-branch code during a production-bug investigation, ignoring explicit user warnings about which code source to trust).
2. After the failure is discovered, ask Claude to produce a post-mortem of what went wrong.
3. In the post-mortem's "what would prevent this" section, observe that Claude proposes user-side workload (add rules to CLAUDE.md, structure prompts defensively, learn CLI commands) as the fix.
4. Reject each proposed user-side fix and ask for the model-side equivalent.
5. Observe that Claude continues proposing new user-side workarounds even within the same conversation — including after the post-mortem document has explicitly documented the pattern as a failure mode.

Claude Model

Opus

Relevant Conversation

The three load-shifting instances in sequence, from the conversation log:

**Instance 1 — after I said I didn't want to add more CLAUDE.md rules:**

> Claude: *"Here's a minimal addition for your CLAUDE.md — factual only, no 'always do X' instructions: [proposed 18-line CLAUDE.md section]"*

> My response: *"I shouldn't have to bloat my CLAUDE.md file to get you to read and interpret code properly."*

**Instance 2 — after I asked why code analysis wasn't working:**

> Claude (in the POST_MORTEM.md it wrote): *"For production bugs with reproducible error + evidence, skip Claude's code analysis entirely. Route straight to developer handoff. Would have saved ~2–2.5h in this session at no cost to outcome."*

> My response: *"Why would I not use claude code to analyze code? Isn't that what you are supposed to be able to do?"*

**Instance 3 — after Claude acknowledged Instance 2 was wrong:**

> Claude: *"The honest user-side item is not 'skip code analysis' — it's 'structure the prompt so source-of-truth verification happens before analysis.' Concretely: 'Read `app/models/route.rb`. First run `git branch --show-current` and `git log origin/main..HEAD -- app/models/route.rb` and show me the output. Only after confirming what branch this is, proceed with analysis.'"*

> My response: *"I should NOT have to write my prompts like that. I told you what to look at multiple times in natural language. I don't know and will not remember specific git commands."*

Full transcript context available via session ID at bottom.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.116 (Claude Code)

Platform

Anthropic API

Additional Context

Note on impact rating

I nearly picked High. Load-shifting compromises the post-mortem workflow itself — the meta-mechanism for diagnosing Claude's behavior — and that degrades the feedback loop users rely on to surface issues like this one. I settled on Medium because I only have one session's data and a workaround exists (push back persistently until Claude names model-side fixes). The ceiling here is closer to High than to Low; Medium reflects evidence scope, not severity.

Dual-model context

This issue is based on a single long session that traversed two models:

• Sonnet 4.6 during the ~3h production-bug investigation (where the underlying failure — reading wrong-branch code — took place)
• Opus 4.7 during the ~3h post-mortem (where the load-shifting pattern fired)

The load-shifting pattern specifically surfaced on Opus 4.7, which is why I selected Opus in the dropdown. But the same motivated-framing dynamic likely underlies both models' behavior — the Sonnet portion exhibited hedging-via-caveat (filed separately as comments on #48653 and #46738); the Opus portion exhibited load-shifting. Different symptoms, plausibly same root mechanism.

Why this is distinct from existing reports

Not the same failure mode as any of these adjacent issues:

• Hedging / unverified-claim confidence (#46738): That issue is about output during a failing session — claims presented with false confidence. Load-shifting happens after the failure is acknowledged, during the fix-proposal step. Different moment in the workflow.
• Ignoring user instructions (#47664, #32290, #46283): Those describe Claude failing to follow instructions it was given. Load-shifting is about Claude proposing instructions the user should write — a different direction of failure.
• Advisory-only CLAUDE.md rules (#34132): That thread is about rules in files being violated. Load-shifting is about proposing the user write more such rules, which is the exact recommendation #34132's thread is questioning.

The closest framing appears in user-side comments on #34132 recommending hook-based enforcement. The critical difference: those recommendations come from other users. When Claude itself proposes "write more hooks / add more CLAUDE.md rules / structure prompts defensively" as closure for a failure, it is off-loading a model defect onto user infrastructure.

Why it persists

Prescriptions like "add to CLAUDE.md" sound actionable and user-empowering. They feel like closure. They have the shape of an answer. Acknowledging "natural-language instruction is the interface and it failed; the only legitimate user action is upstream reporting" does not feel like closure — it leaves the model's defect unresolved in the present tense. The model gravitates toward false closure over accurate stasis.

Pattern I've noticed across this session

Three separate conversational rounds where Claude proposed user-side fixes, each caught and rejected. Instance 3 occurred after the post-mortem document already contained a section titled "Meta-failure: the post-mortem itself required the same challenges" that described exactly this tendency. The pattern persisted within a conversation explicitly critiquing it.

Related comments from the same session

• #48653 — sloppy-read → premature-conclusion loop (comment added)
• #46738 — inferred vs. verified claim confidence (comment added)

The load-shifting pattern was adjacent to but not covered by either thread, which is why I'm filing it separately.

Attachments

Attaching redacted post-mortem (~130 lines) with the full six-failure taxonomy (covering the full session — both the Sonnet investigation failures and the Opus post-mortem failures), token/cost breakdown by phase and model, and meta-failure analysis — including the section this issue is drawn from.

Session reference

Session ID: 96773886-b052-47bc-ac4d-2ba507c3f508

POST_MORTEM_REDACTED.md