[MODEL] Claude Code can not stop using the word "load-bearing"

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/50087

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

replying to "possible duplicate" comment above: The other issue is about Claude ignoring instructions to not use certain words. While that is part of this issue, the real issue is that it's suddenly really overusing the word "load-bearing" at all.

Apologies if this seems like the most minor of issues but I thought it'd still be worth mentioning.

"load bearing" was definitely there in Opus 4.6, but in 4.7 the frequency has gone noticeably up.
I suspect that it's likely because 1) Anthropic hired a small handful of professional writers to create the load bearing training corpus that underpins the model's style, and one writer happens to enjoy writing sharp prose that is load bearing, or 2) some RL quirk that narrows the output distribution to a critical subset of load bearing lexicon.

Confirmed @gertalot - real human :) (👋 ) and absolutely this is happening an alarming amount. I'm worried there's so much load-bearing in various places a small slip and the whole thing will come crashing down around me.

Joking aside, genuine issue though.

I feel overloaded and overbeared, please help!

I'm feeling a lot of anxiety over how many things I've suddenly become aware are load-bearing. How do we know they have proper support systems? What kind of load were they tested with? If a function which was _already_ load-bearing calls another load-bearing function, will my program collapse? Do I need to mark these sections unsafe?

Empirical data: "load-bearing" scales with context window size — and maybe a 4.7 regression

Ran a quantitative analysis across 3 Claude Code sessions (2 multi-agent, 1 single; 1,108 assistant messages after filtering; ~167k words of model output).

Context-length scaling (combined, post-compaction messages excluded)

| Context bin | Messages | Words | Hits | Rate per 10k words |
| --- | --- | --- | --- | --- |
| 1–100k | 272 | 28,722 | 7 | 2.4 |
| 100–200k | 315 | 45,264 | 14 | 3.1 |
| 200–300k | 166 | 29,165 | 9 | 3.1 |
| 300–500k | 245 | 44,129 | 17 | 3.9 |
| 500–700k | 110 | 19,847 | 23 | 11.6 |

Within the 1–100k bin, all 7 hits cluster below 50k — the 50–100k sub-range is dead zero across all 3 sessions. Onset comes back around 100–200k, then it climbs monotonically, spiking ~3x at 500k+.

<img width="1572" height="975" alt="Image" src="https://github.com/user-attachments/assets/7e1a1b18-2eb7-44af-a4c4-b9bc2627871a" />

It's a 4.7 regression

One session ran on Opus 4.6, the other two on Opus 4.7:

| Model | Messages | Hits | Rate per 10k words |
| --- | --- | --- | --- |
| Opus 4.6 | 681 | 3 | 0.5 |
| Opus 4.7 | 525 | 94 | 12.0 |

~24x increase from 4.6 → 4.7. The 4.6 session ran to 590k context and only slipped 3 times total. 4.7 sessions hit ~1 occurrence per 860 words by 500k+.

Semantic drift

The scope of usage expands as context grows. Early hits tend to be more domain-appropriate ("load-bearing paragraphs"). By 500k+ it's fully generalized — one message at 585k tokens contains: "they weren't the load-bearing characters of the paper because they weren't the load-bearing characters of the assay" — twice in one sentence, applied to ML/experimental biology.

Other phrases tested

Tested ~25 candidate Claude-isms across the same corpus. Nothing else shows a comparable context-scaling effect:

| Phrase | Total | Ratio (500k+ / early) | Pattern |
| --- | --- | --- | --- |
| load-bearing | 70 | 2.8x |
| essentially | 17 | 2.7x |
| genuinely | 52 | 1.0x |
| precisely | 10 | 0.4x |
| leverage | 7 | 0.0x |

<img width="1571" height="974" alt="Image" src="https://github.com/user-attachments/assets/8c666162-3f7a-4106-af10-74e5824fff8f" />

Methodology

Parsed JSONL session logs exported from Claude Code. Context size = cache_read_input_tokens + input_tokens from the usage object. Excluded post-compaction messages (ctx < 1000 tokens). Rates normalized per 10,000 words of assistant output.

Load bearing must be.... load bearing

I find it very Orwellian to see Anthropic's GitHub bot try to close issues because they are duplicates under what seems to be the following logic:

1. Issue #53454 may be a duplicate of issue #50087
2. Issue #50087 may be a duplicate of issue #53454

Therefore close both? PEOPLE? NO! THIS IS NOT VALID LOGIC! Instead:

• treat both issues as signal
• use addition 🤦
• merge the issues w.r.t. "proven level of interest"

By the above logic, all of the following words should be struck from the English language merely because they are near-duplicates: idiotic, foolish, dunderheaded, bone-headed, moronic, stupid, asinine, ridiculous, ludicrous, half-baked, .... NO! We need at least one of those words to survive. Don't delete ALL of them! That would be absurd.

Something being similar to something else IS NOT A SIGN that it is useless. QUITE THE OPPOSITE. It suggests the idea pops up in many forms.

Opus 4.7-4.8 is unusable for professional/scientific writing. 4.6 is still fine.

I have written an incredibly strong prohibition on saying the word "load-bearing." I have worked with the model to strengthen the prohibition and have been told that it is as strong as possible. This reduces the rate at which the term is produced, but I still see it once or twice a day. Ridiculously, due to the strength of my prohibition, the model will now apologize in its own output after generating text with the term. For example, with text like:

the feature is load-bearing—sorry, important

Please help.

Please help and fix this.

Opus 5 is off the charts. I'm seeing 3x higher rate than Opus 4.8. Load-bearing now occurs roughly every 5000 words (of prose, not code), or once every 50 messages.

Model | Msgs | Prose words | Hits | Msgs with hit | % msgs with hit | Hits per 100k words
-- | -- | -- | -- | -- | -- | --
claude-opus-5 | 521 | 46,105 | 9 | 9 | 1.73 | 19.5
claude-opus-4-8 | 2,058 | 140,629 | 9 | 9 | 0.44 | 6.4
claude-sonnet-5 | 1,230 | 87,774 | 2 | 2 | 0.16 | 2.3

<img width="4171" height="3254" alt="Image" src="https://github.com/user-attachments/assets/a24e02d5-d937-4b3b-8ca9-2d8cad09acb5" />

Thank you so much for sharing this, @corneliusroemer!

Any chance you could share replication code?

Reproduced. On a completely clean install of the current release (v2.1.233, fresh config directory, no plugins, no CLAUDE.md, no memory), I asked Claude Code to write a short architecture doc for a trivial 7-line Python file — the generated doc used "load-bearing" twice.

This isn't just model vocabulary preference: the phrase appears repeatedly in Claude Code's own built-in prompt text (visible in the strings of the shipped binary), so the model is primed with the term at the start of every session. That also explains why telling it in CLAUDE.md or memory not to use the word doesn't stick — the built-in priming is re-injected every turn and competes with your instruction.

Flagging this as a valid report: reducing the term's frequency in the product's built-in prompts is the actionable fix on the Claude Code side.

🤖 Generated with Claude Code

I just published an analysis here: https://louisabraham.github.io/load-bearing/

Edit: There is now a nice discussion about it on Hacker News after it made to the front page.

This is much less specific and more subjective, but it feels to me like Claude's responses are longer and harder to understand than they used to be. Jargon like "load-bearing" is only part of it.

I'm bearing the load of trying to understand what Claude is saying.